Radio Frequency Interface Specification (SP-RFIv2.0-I03 ...westall/851/docsis/docsis.pdfSP-RFIv2.0-I03-021218 Data-Over-Cable Service Interface Specifications ii Document Status Sheet

Data-Over-Cable Service Interface Specifications

Radio Frequency Interface Specification

SP-RFIv2.0-I03-021218

ISSUEDSPECIFICATION

Notice

This document is a cooperative effort undertaken at the direction ofCable Television Laboratories, Inc. for the benefit of the cable industry ingeneral. Neither CableLabs nor any member company is responsible forany liability of any nature whatsoever resulting from or arising out of useor reliance upon this specification by any party. This document isfurnished on an “AS IS” basis and neither CableLabs nor its membersprovides any representation or warranty, express or implied, regardingits accuracy, completeness, or fitness for a particular purpose.

© Copyright 1999-2002 Cable Television Laboratories, Inc.All rights reserved.

SP-RFIv2.0-I03-021218 Data-Over-Cable Service Interface Specifications

ii

Document Status Sheet

Key to Document Status Codes

Work in Process An incomplete document, designed to guide discussion and generate feedback, that mayinclude several alternative requirements for consideration.

Draft A document in specification format considered largely complete, but lacking review by cable industry andvendors. Drafts are susceptible to substantial change during the review process.

Issued A stable document, which has undergone rigorous member and vendor review and is suitable for productdesign and development, cross-vendor interoperability, and for certification testing.

Closed A static document, reviewed, tested, validated, and closed to further engineering change requests to thespecification through CableLabs.

Document Control Number: SP-RFIv2.0-I03-021218

Reference: Radio Frequency Interface Specification

Revision History: I01 — First Issued Release, December 31, 2001

I02 — Second Issued Release, June 17, 2002

I03 — Third Issued Release, December 18, 2002

Date: December 18, 2002

Status Code: Work inProcess

Draft Issued Closed

Distribution Restrictions: CableLabsonly

CLReviewers

CLVendor

Public

Radio Frequency Interface Specification SP-RFIv2.0-I03-021218

Table of Contents

1 SCOPE AND PURPOSE.................................................................................................................................1

1.1 SCOPE ................................................................................................................................................................1

1.2 REQUIREMENTS .................................................................................................................................................2

1.3 BACKGROUND ...................................................................................................................................................2

1.3.1 Service Goals ..........................................................................................................................................2

1.3.2 Reference Architecture ...........................................................................................................................3

1.3.3 Categories of Interface Specification .....................................................................................................5

1.3.4 Statement of Compatibility .....................................................................................................................5

1.4 CONVENTIONS FOR THIS SPECIFICATION...........................................................................................................5

2 REFERENCES (NORMATIVE/INFORMATIVE) .....................................................................................7

3 GLOSSARY (INFORMATIVE) ..................................................................................................................11

4 FUNCTIONAL ASSUMPTIONS.................................................................................................................23

4.1 BROADBAND ACCESS NETWORK ....................................................................................................................23

4.2 EQUIPMENT ASSUMPTIONS..............................................................................................................................23

4.2.1 Frequency Plan.....................................................................................................................................23

4.2.2 Compatibility with Other Services........................................................................................................24

4.2.3 Fault Isolation Impact on Other Users.................................................................................................24

4.2.4 Cable System Terminal Devices ...........................................................................................................24

4.3 RF CHANNEL ASSUMPTIONS ...........................................................................................................................24

4.3.1 Transmission Downstream ...................................................................................................................24

4.3.2 Transmission Upstream........................................................................................................................25

4.4 TRANSMISSION LEVELS ...................................................................................................................................26

4.5 FREQUENCY INVERSION ..................................................................................................................................26

5 COMMUNICATION PROTOCOLS ..........................................................................................................27

5.1 PROTOCOL STACK ...........................................................................................................................................27

5.1.1 CM and CMTS as Hosts .......................................................................................................................27

5.1.2 Data Forwarding Through the CM and CMTS ....................................................................................28

5.2 THE MAC FORWARDER ..................................................................................................................................31

5.2.1 Rules for Data-Link-Layer Forwarding ...............................................................................................32

5.3 NETWORK LAYER............................................................................................................................................32

5.3.1 Requirements for IGMP Management..................................................................................................33

5.4 ABOVE THE NETWORK LAYER ........................................................................................................................35

5.5 DATA LINK LAYER..........................................................................................................................................35

5.5.1 LLC Sublayer ........................................................................................................................................35

5.5.2 Link-Layer Security Sublayer ...............................................................................................................36

5.5.3 MAC Sublayer.......................................................................................................................................36

5.6 PHYSICAL LAYER ............................................................................................................................................36

5.6.1 Downstream Transmission Convergence Sublayer ..............................................................................36

iii


5.6.2 PMD Sublayer...................................................................................................................................... 36

6 PHYSICAL MEDIA DEPENDENT SUBLAYER SPECIFICATION .................................................... 39

6.1 SCOPE ............................................................................................................................................................. 39

6.2 UPSTREAM ...................................................................................................................................................... 39

6.2.1 Overview .............................................................................................................................................. 39

6.2.2 Signal Processing Requirements ......................................................................................................... 40

6.2.3 Modulation Formats ............................................................................................................................ 44

6.2.4 R-S Encode........................................................................................................................................... 44

6.2.5 R-S Frame Structure ............................................................................................................................ 45

6.2.6 TDMA Byte Interleaver........................................................................................................................ 47

6.2.7 Scrambler (Randomizer)...................................................................................................................... 50

6.2.8 TCM Encoder....................................................................................................................................... 50

6.2.9 Preamble Prepend ............................................................................................................................... 53

6.2.10 Modulation Rates ............................................................................................................................... 54

6.2.11 S-CDMA Framer and Interleaver...................................................................................................... 54

6.2.12 S-CDMA Framer................................................................................................................................ 60

6.2.13 Symbol Mapping ................................................................................................................................ 64

6.2.14 S-CDMA Spreader ............................................................................................................................. 71

6.2.15 Transmit Pre-Equalizer ..................................................................................................................... 73

6.2.16 Spectral Shaping ................................................................................................................................ 75

6.2.17 Relative Processing Delays ............................................................................................................... 76

6.2.18 Transmit Power Requirements........................................................................................................... 76

6.2.19 Burst Profiles ..................................................................................................................................... 79

6.2.20 Burst Timing Convention ................................................................................................................... 84

6.2.21 Fidelity Requirements ........................................................................................................................ 86

6.2.22 Upstream Demodulator Input Power Characteristics....................................................................... 94

6.2.23 Upstream Electrical Output from the CM ......................................................................................... 94

6.3 DOWNSTREAM ................................................................................................................................................ 95

6.3.1 Downstream Protocol .......................................................................................................................... 95

6.3.2 Scalable Interleaving to Support Low Latency.................................................................................... 95

6.3.3 Downstream Frequency Plan .............................................................................................................. 96

6.3.4 CMTS Output Electrical ...................................................................................................................... 96

6.3.5 Downstream Electrical Input to CM.................................................................................................... 97

6.3.6 CM BER Performance ......................................................................................................................... 98

6.3.7 CMTS Timestamp Jitter ....................................................................................................................... 99

6.3.8 CMTS Clock Generation.................................................................................................................... 100

6.3.9 CMTS Downstream Symbol Clock Jitter for Synchronous Operation .............................................. 101

6.3.10 CMTS Downstream Symbol Clock Drift for Synchronous Operation ............................................. 102

7 DOWNSTREAM TRANSMISSION CONVERGENCE SUBLAYER ................................................. 103

7.1 INTRODUCTION ............................................................................................................................................. 103

7.2 MPEG PACKET FORMAT.............................................................................................................................. 103

iv


7.3 MPEG HEADER FOR DOCSIS DATA-OVER-CABLE .....................................................................................104

7.4 MPEG PAYLOAD FOR DOCSIS DATA-OVER-CABLE...................................................................................104

7.4.1 stuff_byte.............................................................................................................................................104

7.4.2 pointer_field........................................................................................................................................104

7.5 INTERACTION WITH THE MAC SUBLAYER....................................................................................................105

7.6 INTERACTION WITH THE PHYSICAL LAYER...................................................................................................106

7.7 MPEG HEADER SYNCHRONIZATION AND RECOVERY ..................................................................................106

8 MEDIA ACCESS CONTROL SPECIFICATION...................................................................................107

8.1 INTRODUCTION ..............................................................................................................................................107

8.1.1 Overview.............................................................................................................................................107

8.1.2 Definitions ..........................................................................................................................................107

8.1.3 Future Use ..........................................................................................................................................110

8.2 MAC FRAME FORMATS ................................................................................................................................110

8.2.1 Generic MAC Frame Format .............................................................................................................110

8.2.2 Packet-Based MAC Frames................................................................................................................114

8.2.3 ATM Cell MAC Frames ......................................................................................................................115

8.2.4 Reserved PDU MAC Frames..............................................................................................................115

8.2.5 MAC-Specific Headers .......................................................................................................................116

8.2.6 Extended MAC Headers .....................................................................................................................121

8.2.7 Fragmented MAC Frames ..................................................................................................................126

8.2.8 Error-Handling...................................................................................................................................128

8.3 MAC MANAGEMENT MESSAGES ..................................................................................................................129

8.3.1 MAC Management Message Header ..................................................................................................129

8.3.2 Time Synchronization (SYNC) ............................................................................................................132

8.3.3 Upstream Channel Descriptor (UCD)................................................................................................132

8.3.4 Upstream Bandwidth Allocation Map (MAP) ....................................................................................141

8.3.5 Ranging Request (RNG-REQ) ............................................................................................................143

8.3.6 Ranging Response (RNG-RSP)...........................................................................................................144

8.3.7 Registration Request (REG-REQ) ......................................................................................................149

8.3.8 Registration Response (REG-RSP).....................................................................................................150

8.3.9 Registration Acknowledge (REG-ACK)..............................................................................................153

8.3.10 Upstream Channel Change Request (UCC-REQ)............................................................................155

8.3.11 Upstream Channel Change Response (UCC-RSP) ..........................................................................155

8.3.12 Dynamic Service Addition — Request (DSA-REQ) ..........................................................................156

8.3.13 Dynamic Service Addition — Response (DSA-RSP) ........................................................................158

8.3.14 Dynamic Service Addition — Acknowledge (DSA-ACK) .................................................................160

8.3.15 Dynamic Service Change — Request (DSC-REQ) ...........................................................................161

8.3.16 Dynamic Service Change — Response (DSC-RSP)..........................................................................162

8.3.17 Dynamic Service Change — Acknowledge (DSC-ACK) ..................................................................164

8.3.18 Dynamic Service Deletion — Request (DSD-REQ)..........................................................................165

8.3.19 Dynamic Service Deletion – Response (DSD-RSP)..........................................................................166

8.3.20 Dynamic Channel Change – Request (DCC-REQ) ..........................................................................166

v


8.3.21 Dynamic Channel Change – Response (DCC-RSP)........................................................................ 173

8.3.22 Dynamic Channel Change – Acknowledge (DCC-ACK)................................................................. 175

8.3.23 Device Class Identification Request (DCI-REQ)............................................................................. 176

8.3.24 Device Class Identification Response (DCI-RSP) ........................................................................... 176

8.3.25 Upstream Transmitter Disable (UP-DIS) MAC Management Message ......................................... 177

8.3.26 Initial Ranging Request (INIT-RNG-REQ)...................................................................................... 179

8.3.27 Test Request (TST-REQ) .................................................................................................................. 180

9 MEDIA ACCESS CONTROL PROTOCOL OPERATION.................................................................. 183

9.1 UPSTREAM BANDWIDTH ALLOCATION......................................................................................................... 183

9.1.1 The Allocation MAP MAC Management Message ............................................................................ 184

9.1.2 Information Elements......................................................................................................................... 184

9.1.3 Requests ............................................................................................................................................. 187

9.1.4 Information Element Feature Usage Summary ................................................................................. 188

9.1.5 Map Transmission and Timing .......................................................................................................... 188

9.1.6 Protocol Example .............................................................................................................................. 189

9.1.7 MAP Generation Example - Two Logical Upstreams ....................................................................... 190

9.2 SUPPORT FOR MULTIPLE CHANNELS............................................................................................................ 191

9.3 TIMING AND SYNCHRONIZATION.................................................................................................................. 191

9.3.1 Global Timing Reference ................................................................................................................... 192

9.3.2 CM Channel Acquisition.................................................................................................................... 192

9.3.3 Ranging.............................................................................................................................................. 193

9.3.4 Timing Units and Relationships......................................................................................................... 194

9.4 UPSTREAM TRANSMISSION AND CONTENTION RESOLUTION ....................................................................... 195

9.4.1 Contention Resolution Overview ....................................................................................................... 196

9.4.2 Transmit Opportunities...................................................................................................................... 197

9.4.3 CM Bandwidth Utilization ................................................................................................................. 198

9.5 DATA LINK ENCRYPTION SUPPORT.............................................................................................................. 198

9.5.1 MAC Messages .................................................................................................................................. 198

9.5.2 Framing ............................................................................................................................................. 198

10 QUALITY OF SERVICE AND FRAGMENTATION.......................................................................... 199

10.1 THEORY OF OPERATION ............................................................................................................................. 199

10.1.1 Concepts........................................................................................................................................... 200

10.1.2 Object Model.................................................................................................................................... 204

10.1.3 Service Classes ................................................................................................................................ 205

10.1.4 Authorization ................................................................................................................................... 206

10.1.5 Types of Service Flows .................................................................................................................... 207

10.1.6 Service Flows and Classifiers.......................................................................................................... 209

10.1.7 General Operation ........................................................................................................................... 210

10.2 UPSTREAM SERVICE FLOW SCHEDULING SERVICES .................................................................................. 213

10.2.1 Unsolicited Grant Service................................................................................................................ 214

10.2.2 Real-Time Polling Service ............................................................................................................... 214

vi


10.2.3 Unsolicited Grant Service with Activity Detection...........................................................................215

10.2.4 Non-Real-Time Polling Service ........................................................................................................215

10.2.5 Best Effort Service ............................................................................................................................216

10.2.6 Other Services...................................................................................................................................216

10.2.7 Parameter Applicability for Upstream Service Scheduling..............................................................216

10.2.8 CM Transmit Behavior .....................................................................................................................217

10.3 FRAGMENTATION ........................................................................................................................................217

10.3.1 CM Fragmentation Support..............................................................................................................218

10.3.2 CMTS Fragmentation Support .........................................................................................................220

10.3.3 Fragmentation Example ...................................................................................................................221

10.4 PAYLOAD HEADER SUPPRESSION................................................................................................................225

10.4.1 Overview...........................................................................................................................................225

10.4.2 Example Applications .......................................................................................................................226

10.4.3 Operation..........................................................................................................................................226

10.4.4 Signaling ...........................................................................................................................................229

10.4.5 Payload Header Suppression Examples...........................................................................................230

11 CABLE MODEM - CMTS INTERACTION.........................................................................................233

11.1 CMTS INITIALIZATION................................................................................................................................233

11.2 CABLE MODEM INITIALIZATION..................................................................................................................233

11.2.1 Scanning and Synchronization to Downstream................................................................................235

11.2.2 Obtain Upstream Parameters...........................................................................................................236

11.2.3 Message Flows During Scanning and Upstream Parameter Acquisition ........................................238

11.2.4 Ranging and Automatic Adjustments................................................................................................239

11.2.5 Device Class Identification...............................................................................................................243

11.2.6 Establish IP Connectivity .................................................................................................................243

11.2.7 Establish Time of Day.......................................................................................................................244

11.2.8 Transfer Operational Parameters ....................................................................................................245

11.2.9 Registration ......................................................................................................................................245

11.2.10 Baseline Privacy Initialization .......................................................................................................250

11.2.11 Service IDs During CM Initialization.............................................................................................250

11.2.12 Multiple-Channel Support ..............................................................................................................251

11.3 STANDARD OPERATION...............................................................................................................................251

11.3.1 Periodic Signal Level Adjustment.....................................................................................................251

11.3.2 Changing Upstream Channel Descriptor Message Parameters ......................................................253

11.3.3 Changing Upstream Channels..........................................................................................................254

11.4 DYNAMIC SERVICE......................................................................................................................................257

11.4.1 Dynamic Service Flow State Transitions..........................................................................................258

11.4.2 Dynamic Service Addition ................................................................................................................267

11.4.3 Dynamic Service Change..................................................................................................................278

11.4.4 Dynamic Service Deletion ................................................................................................................289

11.4.5 Dynamically Changing Downstream and/or Upstream Channels ...................................................295

11.5 FAULT DETECTION AND RECOVERY ...........................................................................................................315

vii


11.5.1 Prevention of Unauthorized Transmissions..................................................................................... 316

12 SUPPORTING FUTURE NEW CABLE MODEM CAPABILITIES................................................. 317

12.1 DOWNLOADING CABLE MODEM OPERATING SOFTWARE .......................................................................... 317

ANNEX A WELL-KNOWN ADDRESSES................................................................................................. 319

A.1 MAC ADDRESSES........................................................................................................................................ 319

A.2 MAC SERVICE IDS...................................................................................................................................... 319

A.2.1 All CMs and No CM Service IDs....................................................................................................... 319

A.2.2 Well-Known Multicast Service IDs ................................................................................................... 319

A.2.3 Priority Request Service IDs ............................................................................................................. 320

A.3 MPEG PID .................................................................................................................................................. 320

ANNEX B PARAMETERS AND CONSTANTS........................................................................................ 321

ANNEX C COMMON RADIO FREQUENCY INTERFACE ENCODINGS......................................... 325

C.1 ENCODINGS FOR CONFIGURATION AND MAC-LAYER MESSAGING ............................................................ 325

C.1.1 Configuration File and Registration Settings ................................................................................... 325

C.1.2 Configuration-File-Specific Settings................................................................................................. 333

C.1.3 Registration-Request/Response-Specific Encodings ......................................................................... 337

C.1.4 Dynamic-Service-Message-Specific Encodings ................................................................................ 341

C.2 QUALITY-OF-SERVICE-RELATED ENCODINGS ............................................................................................. 342

C.2.1 Packet Classification Encodings....................................................................................................... 342

C.2.2 Service Flow Encodings .................................................................................................................... 350

C.3 ENCODINGS FOR OTHER INTERFACES .......................................................................................................... 367

C.3.1 Telephone Settings Option ................................................................................................................ 367

C.3.2 Baseline Privacy Configuration Settings Option .............................................................................. 367

C.4 CONFIRMATION CODE.................................................................................................................................. 367

C.4.1 Confirmation Codes for Dynamic Channel Change ......................................................................... 369

C.4.2 Confirmation Codes for Major Errors .............................................................................................. 369

ANNEX D CM CONFIGURATION INTERFACE SPECIFICATION................................................... 371

D.1 CM IP ADDRESSING .................................................................................................................................... 371

D.1.1 DHCP Fields Used by the CM.......................................................................................................... 371

D.2 CM CONFIGURATION................................................................................................................................... 372

D.2.1 CM Binary Configuration File Format............................................................................................. 372

D.2.2 Configuration File Settings............................................................................................................... 373

D.2.3 Configuration File Creation ............................................................................................................. 374

D.3 CONFIGURATION VERIFICATION .................................................................................................................. 376

D.3.1 CMTS MIC Calculation .................................................................................................................... 376

ANNEX E THE DATA-OVER-CABLE SPANNING TREE PROTOCOL ............................................ 379

E.1 BACKGROUND .............................................................................................................................................. 379

E.2 PUBLIC SPANNING TREE .............................................................................................................................. 379

viii


E.3 PUBLIC SPANNING TREE PROTOCOL DETAILS..............................................................................................380

E.4 SPANNING TREE PARAMETERS AND DEFAULTS ...........................................................................................381

E.4.1 Path Cost ............................................................................................................................................381

E.4.2 Bridge Priority ...................................................................................................................................382

ANNEX F EUROPEAN SPECIFICATION ADDITIONS.........................................................................383

F.1 SCOPE AND PURPOSE ....................................................................................................................................383

F.2 REFERENCES..................................................................................................................................................383

F.3 GLOSSARY.....................................................................................................................................................383

F.4 FUNCTIONAL ASSUMPTIONS..........................................................................................................................383

F.4.1 Broadband access network.................................................................................................................383

F.4.2 Equipment Assumptions .....................................................................................................................384

F.4.3 RF Channel Assumptions ...................................................................................................................384

F.4.4 Transmission Levels ...........................................................................................................................386

F.4.5 Frequency Inversion...........................................................................................................................386

F.5 COMMUNICATION PROTOCOLS......................................................................................................................387

F.6 PHYSICAL MEDIA DEPENDENT SUBLAYER SPECIFICATION ..........................................................................387

F.6.1 Scope ..................................................................................................................................................387

F.6.2 Upstream ............................................................................................................................................387

F.6.3 Downstream .......................................................................................................................................401

F.7 DOWNSTREAM TRANSMISSION CONVERGENCE SUBLAYER ...........................................................................407

F.7.1 Introduction........................................................................................................................................407

F.7.2 MPEG Packet format .........................................................................................................................408

F.7.3 MPEG Header for Euro-DOCSIS Data-Over-Cable.........................................................................408

F.7.4 MPEG Payload for Euro-DOCSIS Data-Over-Cable .......................................................................408

F.7.5 Interaction with the MAC sublayer ....................................................................................................409

F.7.6 Interaction with the Physical layer ....................................................................................................409

F.7.7 MPEG Header synchronization and recovery ...................................................................................409

F.8 MEDIA ACCESS CONTROL SPECIFICATION....................................................................................................409

F.8.1 Introduction........................................................................................................................................409

F.8.2 MAC Frame Formats .........................................................................................................................409

F.8.3 MAC Management Messages .............................................................................................................409

ANNEX G DOCSIS 2.0 AND 1.0/1.1 INTEROPERABILITY...................................................................411

G.1 GENERAL INTEROPERABILITY ISSUES ..........................................................................................................411

G.1.1 Provisioning.......................................................................................................................................411

G.1.2 Registration........................................................................................................................................412

G.1.3 Dynamic Service Establishment.........................................................................................................413

G.1.4 Fragmentation ...................................................................................................................................414

G.1.5 Multicast Support...............................................................................................................................414

G.1.6 Changing Upstream Channels...........................................................................................................414

G.2 HYBRID DEVICES..........................................................................................................................................414

G.3 DOCSIS 2.0 TDMA INTEROPERABILITY.....................................................................................................415

ix


G.3.1 Mixed-mode operation with TDMA .................................................................................................. 415

G.3.2 Interoperability & Performance ....................................................................................................... 416

G.4 DOCSIS 2.0 S-CDMA INTEROPERABILITY ................................................................................................ 416

G.4.1 Mixed mode operation with S-CDMA............................................................................................... 416

G.4.2 Interoperability & Performance ....................................................................................................... 416

ANNEX H THE DOCSIS MAC/PHY INTERFACE (DMPI) ................................................................... 417

H.1 SCOPE .......................................................................................................................................................... 417

H.2 CONVENTIONS.............................................................................................................................................. 417

H.2.1 Terminology ...................................................................................................................................... 417

H.2.2 Ordering of Bits and Bytes................................................................................................................ 417

H.2.3 Signal Naming Conventions.............................................................................................................. 417

H.2.4 Active Clock Edge ............................................................................................................................. 417

H.2.5 Timing Specifications........................................................................................................................ 418

H.3 OVERVIEW ................................................................................................................................................... 418

H.3.1 Downstream Data ............................................................................................................................. 421

H.3.2 Upstream Data.................................................................................................................................. 421

H.3.3 Upstream Control ............................................................................................................................. 421

H.3.4 SPI Bus.............................................................................................................................................. 421

H.4 SIGNALS....................................................................................................................................................... 422


H.4.2 Upstream Data.................................................................................................................................. 422


H.4.4 SPI Bus.............................................................................................................................................. 423

H.4.5 Parity................................................................................................................................................. 424

H.4.6 Interrupts........................................................................................................................................... 424

H.5 PROTOCOL ................................................................................................................................................... 425

H.5.1 Downstream Data (ITU-T Recommendations J.83 Annex A) ........................................................... 425

H.5.2 Downstream Data (ITU-T Recommendations J.83 Annex B) ........................................................... 426

H.5.3 Upstream Data.................................................................................................................................. 426


H.5.5 SPI Bus.............................................................................................................................................. 429

H.6 ELECTRICAL SPECIFICATIONS...................................................................................................................... 430

H.6.1 DC Specifications.............................................................................................................................. 430

H.7 TIMING SPECIFICATIONS.............................................................................................................................. 431


H.7.2 Upstream Data.................................................................................................................................. 431


H.7.4 SPI Bus.............................................................................................................................................. 432

H.8 DATA FORMAT AND USAGE ........................................................................................................................ 432


H.8.2 Upstream Data.................................................................................................................................. 432


x


H.8.4 SPI Bus...............................................................................................................................................440

APPENDIX I MAC SERVICE DEFINITION.............................................................................................441

I.1 MAC SERVICE OVERVIEW.............................................................................................................................441

I.1.1 MAC Service Parameters ....................................................................................................................442

I.2 MAC DATA SERVICE INTERFACE ..................................................................................................................443

I.2.1 MAC_DATA.request............................................................................................................................443

I.2.2 MAC_DATA.indicate...........................................................................................................................444

I.2.3 MAC_GRANT_SYNCHRONIZE.indicate ...........................................................................................444

I.2.4 MAC_CMTS_MASTER_CLOCK_SYNCHRONIZE.indicate ..............................................................445

I.3 MAC CONTROL SERVICE INTERFACE............................................................................................................445

I.3.1 MAC_REGISTRATION_RESPONSE.indicate ....................................................................................445

I.3.2 MAC_CREATE_SERVICE_FLOW.request ........................................................................................445

I.3.3 MAC_CREATE_SERVICE_FLOW.response ......................................................................................446

I.3.4 MAC_CREATE_SERVICE_FLOW.indicate .......................................................................................446

I.3.5 MAC_DELETE_SERVICE_FLOW.request ........................................................................................446

I.3.6 MAC_DELETE_SERVICE_FLOW.response ......................................................................................447

I.3.7 MAC_DELETE_SERVICE_FLOW.indicate .......................................................................................447

I.3.8 MAC_CHANGE_SERVICE_FLOW.request .......................................................................................447

I.3.9 MAC_CHANGE_SERVICE_FLOW.response.....................................................................................447

I.3.10 MAC_CHANGE_SERVICE_FLOW.indicate ....................................................................................448

I.4 MAC SERVICE USAGE SCENARIOS................................................................................................................448

I.4.1 Transmission of PDUs from Upper Layer Service to MAC DATA Service ........................................448

I.4.2 Reception of PDUs to Upper Layer Service from MAC DATA Service..............................................448

I.4.3 Sample Sequence of MAC Control and MAC Data Services ..............................................................449

APPENDIX II EXAMPLE PREAMBLE SEQUENCE ..............................................................................451

II.1 INTRODUCTION .............................................................................................................................................451

II.2 EXAMPLE PREAMBLE SEQUENCE..................................................................................................................451

APPENDIX III MULTIPLE UPSTREAM CHANNELS ...........................................................................453

III.1 SINGLE DOWNSTREAM AND SINGLE UPSTREAM PER CABLE SEGMENT .....................................................453

III.2 MULTIPLE DOWNSTREAMS AND MULTIPLE UPSTREAMS PER CABLE SEGMENT ........................................455

III.2.1 Topologies.........................................................................................................................................455

III.2.2 Normal Operation.............................................................................................................................457

III.2.3 Initial Ranging ..................................................................................................................................458

III.2.4 Dynamic Channel Change................................................................................................................458

APPENDIX IV DOCSIS TRANSMISSION AND CONTENTION RESOLUTION...............................459

IV.1 INTRODUCTION............................................................................................................................................459

IV.2 VARIABLE DEFINITIONS ..............................................................................................................................460

IV.3 STATE EXAMPLES .......................................................................................................................................460

IV.3.1 Idle — Waiting for a Packet to Transmit ..........................................................................................460

IV.3.2 Data Ack Pending — Waiting for Data Ack only .............................................................................461

xi


IV.3.3 Grant Pending — Waiting for a Grant ............................................................................................ 461

IV.3.4 Deferring — Determine Proper Transmission Timing & Transmit................................................. 461

IV.4 FUNCTION EXAMPLES ................................................................................................................................ 462

IV.4.1 CalcDefer() — Determine Defer Amount ........................................................................................ 462

IV.4.2 UtilizeGrant() — Determine Best Use of a Grant............................................................................ 462

IV.4.3 Retry() .............................................................................................................................................. 463

APPENDIX V IGMP EXAMPLE ................................................................................................................ 465

V.1 EVENTS ........................................................................................................................................................ 465

V.2 ACTIONS ...................................................................................................................................................... 466

APPENDIX VI UNSOLICITED GRANT SERVICES .............................................................................. 467

VI.1 UNSOLICITED GRANT SERVICE (UGS)....................................................................................................... 467

VI.1.1 Introduction...................................................................................................................................... 467

VI.1.2 Configuration Parameters ............................................................................................................... 467

VI.1.3 Operation ......................................................................................................................................... 467

VI.1.4 Jitter ................................................................................................................................................. 468

VI.1.5 Synchronization Issues ..................................................................................................................... 468

VI.2 UNSOLICITED GRANT SERVICE WITH ACTIVITY DETECTION (UGS-AD) .................................................. 469

VI.2.1 Introduction...................................................................................................................................... 469

VI.2.2 MAC Configuration Parameters ...................................................................................................... 469

VI.2.3 Operation ......................................................................................................................................... 469

VI.2.4 Example............................................................................................................................................ 470

VI.2.5 Talk Spurt Grant Burst..................................................................................................................... 471

VI.2.6 Admission Considerations................................................................................................................ 472

APPENDIX VII S-CDMA FRAMING ........................................................................................................ 473

VII.1 CODED SUBSYMBOL NUMBERING............................................................................................................. 473

VII.2 UNCODED SUBSYMBOL NUMBERING ........................................................................................................ 474

VII.3 FRAMER OUTPUT NUMBERING ................................................................................................................. 474

VII.4 COMMENTS ............................................................................................................................................... 474

APPENDIX VIII AMBIENT TEMPERATURE AND WIND LOADING EFFECTS ........................... 475

VIII.1 SYNCHRONIZATION TOLERANCES TO PLANT DELAY VARIATIONS ......................................................... 475

VIII.2 CHANGE IN PROPAGATION DELAY DUE TO TEMPERATURE CHANGES ................................................... 476

VIII.2.1 Fiber Delay Changes Due to Temperature ................................................................................... 476

VIII.2.2 Coaxial Cable Delay Changes Due to Temperature..................................................................... 477

VIII.2.3 Delay Change Due to Wind........................................................................................................... 477

VIII.3 REFERENCES ............................................................................................................................................ 477

APPENDIX IX ACKNOWLEDGMENTS .................................................................................................. 479

APPENDIX X REVISIONS .......................................................................................................................... 481

X.1 ECNS INCLUDED IN SP-RFIV2.0-I02-020617 ............................................................................................. 481

xii


X.2 ECNS INCLUDED IN SP-RFIV2.0-I03-021218..............................................................................................482

xiii


This page intentionally left blank.

xiv


Figures

FIGURE 1-1 TRANSPARENT IP TRAFFIC THROUGH THE DATA-OVER-CABLE SYSTEM ..................................2

FIGURE 1-2 DATA-OVER-CABLE REFERENCE ARCHITECTURE ......................................................................4

FIGURE 5-1 PROTOCOL STACK ON THE RF INTERFACE................................................................................27

FIGURE 5-2 DATA FORWARDING THROUGH THE CM AND CMTS...............................................................28

FIGURE 5-3 EXAMPLE CONDITION FOR NETWORK LOOPS ...........................................................................29

FIGURE 5-4 MAC FORWARDER ....................................................................................................................31

FIGURE 6-1 UPSTREAM SIGNAL-PROCESSING SEQUENCE..............................................................................41

FIGURE 6-2 TDMA UPSTREAM TRANSMISSION PROCESSING ......................................................................42

FIGURE 6-3 S-CDMA UPSTREAM TRANSMISSION PROCESSING ..................................................................43

FIGURE 6-4 EXAMPLE FRAME STRUCTURES WITH FLEXIBLE BURST LENGTH MODE..................................45

FIGURE 6-5 BYTE INTERLEAVER OPERATION...............................................................................................48

FIGURE 6-6 INTERLEAVER OPERATION FOR LAST INTERLEAVER BLOCK

(WITH SHORTENED LAST CODEWORD) .......................................................................................48

FIGURE 6-7 SCRAMBLER STRUCTURE...........................................................................................................50

FIGURE 6-8 CONVOLUTIONAL ENCODER ......................................................................................................51

FIGURE 6-9 REPETITIVE PATTERNS OF BYTE MAPPING TO SYMBOL MAP BITS FOR TCM.............................52

FIGURE 6-10 EXAMPLE BYTE TO BIT ASSIGNMENT FOR 64 QAM ..................................................................52

FIGURE 6-11 EXAMPLE OF RETURN TO ZERO BITS FOLLOWED BY “0” ...........................................................53

FIGURE 6-12 TIMESTAMP SNAPSHOT..............................................................................................................55

FIGURE 6-13 MINI-SLOT MAPPING WITH TWO CODES PER MINI-SLOT, 128 ACTIVE CODES.........................57

FIGURE 6-14 MINI-SLOT MAPPING WITH THREE CODES PER MINI-SLOT, 126 ACTIVE CODES......................58

FIGURE 6-15 S-CDMA AND SPREADER-OFF INTERVALS ...............................................................................60

FIGURE 6-16 SUBFRAME STRUCTURE .............................................................................................................61

FIGURE 6-17 SYMBOL NUMBERING WITHOUT TCM......................................................................................63

FIGURE 6-18 SYMBOL CONSTELLATIONS .......................................................................................................66

FIGURE 6-19 QPSK GRAY AND DIFFERENTIAL SYMBOL MAPPING...............................................................67

FIGURE 6-20 8QAM SYMBOL MAPPING ........................................................................................................67

FIGURE 6-21 16QAM SYMBOL MAPPING ......................................................................................................68



FIGURE 6-24 QPSK AND 8QAM TCM SYMBOL MAPPING............................................................................69

FIGURE 6-25 16QAM AND 32QAM TCM SYMBOL MAPPING.......................................................................70

FIGURE 6-26 64QAM AND 128QAM TCM SYMBOL MAPPING.....................................................................70

FIGURE 6-27 CODE HOPPING RANDOM NUMBER GENERATOR ......................................................................73

FIGURE 6-28 TRANSMIT PRE-EQUALIZER STRUCTURE...................................................................................73

FIGURE 6-29 NOMINAL TDMA BURST TIMING .............................................................................................85

FIGURE 6-30 WORST-CASE TDMA BURST TIMING .......................................................................................86

FIGURE 7-1 EXAMPLE OF INTERLEAVING MPEG PACKETS IN DOWNSTREAM ..........................................103

FIGURE 7-2 FORMAT OF AN MPEG PACKET ..............................................................................................103

FIGURE 7-3 PACKET FORMAT WHERE A MAC FRAME IMMEDIATELY FOLLOWS THE POINTER_FIELD.....105

FIGURE 7-4 PACKET FORMAT WITH MAC FRAME PRECEDED BY STUFFING BYTES .................................105

xv


FIGURE 7-5 PACKET FORMAT SHOWING MULTIPLE MAC FRAMES IN A SINGLE PACKET ....................... 105

FIGURE 7-6 PACKET FORMAT WHERE A MAC FRAME SPANS MULTIPLE PACKETS................................. 106

FIGURE 8-1 GENERIC MAC FRAME FORMAT ............................................................................................ 110

FIGURE 8-2 UPSTREAM MAC/PMD CONVERGENCE ................................................................................. 111

FIGURE 8-3 MAC HEADER FORMAT ......................................................................................................... 112

FIGURE 8-4 ETHERNET/802.3 PACKET PDU FORMAT ............................................................................... 114

FIGURE 8-5 RESERVED PDU FORMAT ....................................................................................................... 116

FIGURE 8-6 TIMING MAC HEADER ........................................................................................................... 117

FIGURE 8-7 MANAGEMENT MAC HEADER ............................................................................................... 118

FIGURE 8-8 REQUEST FRAME FORMAT...................................................................................................... 119

FIGURE 8-9 FRAGMENTATION MAC HEADER FORMAT ............................................................................ 120

FIGURE 8-10 CONCATENATION OF MULTIPLE MAC FRAMES ..................................................................... 120

FIGURE 8-11 CONCATENATION MAC HEADER FORMAT............................................................................. 121

FIGURE 8-12 EXTENDED MAC FORMAT ..................................................................................................... 122

FIGURE 8-13 FRAGMENTATION DETAILS ..................................................................................................... 126

FIGURE 8-14 MAC HEADER AND MAC MANAGEMENT MESSAGE HEADER FIELDS.................................. 129

FIGURE 8-15 FORMAT OF PACKET PDU FOLLOWING THE TIMING HEADER............................................... 132

FIGURE 8-16 UPSTREAM CHANNEL DESCRIPTOR ........................................................................................ 133

FIGURE 8-17 TOP-LEVEL ENCODING FOR BURST DESCRIPTORS ................................................................. 136

FIGURE 8-18 EXAMPLE OF UCD ENCODED TLV DATA.............................................................................. 140

FIGURE 8-19 MAP FORMAT ........................................................................................................................ 141

FIGURE 8-20 MAP INFORMATION ELEMENT STRUCTURE ........................................................................... 142

FIGURE 8-21 PACKET PDU FOLLOWING THE TIMING HEADER................................................................... 144

FIGURE 8-22 RANGING RESPONSE ............................................................................................................... 145

FIGURE 8-23 GENERALIZED DECISION FEEDBACK EQUALIZATION COEFFICIENTS ..................................... 147

FIGURE 8-24 EXAMPLE OF TLV DATA ........................................................................................................ 148

FIGURE 8-25 REGISTRATION REQUEST ........................................................................................................ 149

FIGURE 8-26 REGISTRATION RESPONSE FORMAT........................................................................................ 151

FIGURE 8-27 REGISTRATION ACKNOWLEDGMENT ...................................................................................... 154

FIGURE 8-28 UPSTREAM CHANNEL CHANGE REQUEST............................................................................... 155

FIGURE 8-29 UPSTREAM CHANNEL CHANGE RESPONSE ............................................................................. 156

FIGURE 8-30 DYNAMIC SERVICE ADDITION — REQUEST ........................................................................... 156

FIGURE 8-31 DYNAMIC SERVICE ADDITION — RESPONSE ......................................................................... 158

FIGURE 8-32 DYNAMIC SERVICE ADDITION — ACKNOWLEDGE................................................................. 160

FIGURE 8-33 DYNAMIC SERVICE CHANGE — REQUEST ............................................................................. 161

FIGURE 8-34 DYNAMIC SERVICE CHANGE — RESPONSE............................................................................ 162

FIGURE 8-35 DYNAMIC SERVICE CHANGE — ACKNOWLEDGE................................................................... 164

FIGURE 8-36 DYNAMIC SERVICE DELETION — REQUEST........................................................................... 165

FIGURE 8-37 DYNAMIC SERVICE DELETION — RESPONSE ......................................................................... 166

FIGURE 8-38 DYNAMIC CHANNEL CHANGE REQUEST ................................................................................ 166

FIGURE 8-39 DYNAMIC CHANNEL CHANGE RESPONSE............................................................................... 173

FIGURE 8-40 DYNAMIC CHANNEL CHANGE ACKNOWLEDGE...................................................................... 175

FIGURE 8-41 DEVICE CLASS IDENTIFICATION REQUEST ............................................................................. 176

xvi


FIGURE 8-42 DEVICE CLASS IDENTIFICATION RESPONSE ............................................................................177

FIGURE 8-43 UP-DIS MESSAGE FORMAT......................................................................................................178

FIGURE 8-44 PACKET PDU FOLLOWING THE TIMING HEADER ...................................................................179

FIGURE 8-45 TEST REQUEST.........................................................................................................................180

FIGURE 9-1 ALLOCATION MAP...................................................................................................................183

FIGURE 9-2 PROTOCOL EXAMPLE...............................................................................................................189

FIGURE 9-3 LOGICAL S-CDMA TDMA CHANNELS...................................................................................190

FIGURE 10-1 PROVISIONED AUTHORIZATION MODEL “ENVELOPES”...........................................................201

FIGURE 10-2 DYNAMIC AUTHORIZATION MODEL “ENVELOPES” ................................................................202

FIGURE 10-3 CLASSIFICATION WITHIN THE MAC LAYER ............................................................................203

FIGURE 10-4 THEORY OF OPERATION OBJECT MODEL ................................................................................205

FIGURE 10-5 REGISTRATION MESSAGE FLOW..............................................................................................210

FIGURE 10-6 DYNAMIC SERVICE ADDITION MESSAGE FLOW — CM INITIATED ........................................212

FIGURE 10-7 DYNAMIC SERVICE ADDITION MESSAGE FLOW — CMTS INITIATED ...................................213

FIGURE 10-8 CM FRAGMENTATION FLOWCHART ........................................................................................219

FIGURE 10-9 EXAMPLE OF FRAGMENTING A SINGLE PACKET .....................................................................223

FIGURE 10-10 FRAGMENTED CONCATENATED PACKET EXAMPLE ................................................................224

FIGURE 10-11 PAYLOAD HEADER SUPPRESSION OPERATION ........................................................................228

FIGURE 10-12 PAYLOAD HEADER SUPPRESSION WITH MASKING ..................................................................229

FIGURE 10-13 PAYLOAD HEADER SUPPRESSION SIGNALING EXAMPLE ........................................................230

FIGURE 10-14 UPSTREAM PAYLOAD HEADER SUPPRESSION EXAMPLE.........................................................231

FIGURE 10-15 DOWNSTREAM PAYLOAD HEADER SUPPRESSION EXAMPLE...................................................232

FIGURE 11-1 CM INITIALIZATION OVERVIEW..............................................................................................234

FIGURE 11-2 SDL NOTATION .......................................................................................................................235

FIGURE 11-3 OBTAINING UPSTREAM PARAMETERS .....................................................................................237

FIGURE 11-4 MESSAGE FLOWS DURING SCANNING AND UPSTREAM PARAMETER ACQUISITION ...............238

FIGURE 11-5 RANGING AND AUTOMATIC ADJUSTMENTS PROCEDURE........................................................239

FIGURE 11-6 INITIAL RANGING - CM...........................................................................................................240

FIGURE 11-7 UNICAST INITIAL RANGING - CM ...........................................................................................241

FIGURE 11-8 INITIAL RANGING - CMTS ......................................................................................................242

FIGURE 11-9 DEVICE CLASS IDENTIFICATION ..............................................................................................243

FIGURE 11-10 ESTABLISHING IP CONNECTIVITY ...........................................................................................244

FIGURE 11-11 ESTABLISHING TIME OF DAY ..................................................................................................244

FIGURE 11-12 REGISTRATION — CM.............................................................................................................246

FIGURE 11-13 WAIT FOR REGISTRATION RESPONSE — CM..........................................................................247

FIGURE 11-14 REGISTRATION — CMTS........................................................................................................249

FIGURE 11-15 REGISTRATION ACKNOWLEDGMENT— CMTS .......................................................................250

FIGURE 11-16 PERIODIC RANGING - CMTS...................................................................................................252

FIGURE 11-17 PERIODIC RANGING - CM VIEW..............................................................................................253

FIGURE 11-18 CHANGING UPSTREAM CHANNELS: CMTS VIEW...................................................................255

FIGURE 11-19 CHANGING UPSTREAM CHANNELS: CM VIEW PART 1...........................................................256

FIGURE 11-20 CHANGING UPSTREAM CHANNELS: CM VIEW PART 2...........................................................257

FIGURE 11-21 DYNAMIC SERVICE FLOW OVERVIEW.....................................................................................258

xvii


FIGURE 11-22 DYNAMIC SERVICE FLOW STATE TRANSITION DIAGRAM...................................................... 261

FIGURE 11-23 DSA—LOCALLY INITIATED TRANSACTION STATE TRANSITION DIAGRAM .......................... 262

FIGURE 11-24 DSA—REMOTELY INITIATED TRANSACTION STATE TRANSITION DIAGRAM........................ 263

FIGURE 11-25 DSC—LOCALLY INITIATED TRANSACTION STATE TRANSITION DIAGRAM .......................... 264

FIGURE 11-26 DSC—REMOTELY INITIATED TRANSACTION STATE TRANSITION DIAGRAM........................ 265

FIGURE 11-27 DSD—LOCALLY INITIATED TRANSACTION STATE TRANSITION DIAGRAM .......................... 266

FIGURE 11-28 DYNAMIC DELETION (DSD) - REMOTELY INITIATED TRANSACTION STATE

TRANSITION DIAGRAM ........................................................................................................... 267

FIGURE 11-29 DYNAMIC SERVICE ADDITION INITIATED FROM CM ............................................................. 268

FIGURE 11-30 DYNAMIC SERVICE ADDITION INITIATED FROM CMTS......................................................... 269

FIGURE 11-31 DSA—LOCALLY INITIATED TRANSACTION BEGIN STATE FLOW DIAGRAM ......................... 270

FIGURE 11-32 DSA—LOCALLY INITIATED TRANSACTION DSA-RSP PENDING STATE FLOW DIAGRAM ... 271

FIGURE 11-33 DSA—LOCALLY INITIATED TRANSACTION HOLDING STATE FLOW DIAGRAM .................... 272

FIGURE 11-34 DSA—LOCALLY INITIATED TRANSACTION RETRIES EXHAUSTED STATE FLOW DIAGRAM . 273

FIGURE 11-35 DSA—LOCALLY INITIATED TRANSACTION DELETING SERVICE FLOW STATE FLOW

DIAGRAM ................................................................................................................................ 274

FIGURE 11-36 DSA—REMOTELY INITIATED TRANSACTION BEGIN STATE FLOW DIAGRAM....................... 275

FIGURE 11-37 DSA—REMOTELY INITIATED TRANSACTION DSA-ACK PENDING STATE FLOW DIAGRAM 276

FIGURE 11-38 DSA—REMOTELY INITIATED TRANSACTION HOLDING DOWN STATE FLOW DIAGRAM ...... 277

FIGURE 11-39 DSA—REMOTELY INITIATED TRANSACTION DELETING SERVICE STATE FLOW DIAGRAM.. 278

FIGURE 11-40 CM-INITIATED DSC ............................................................................................................... 280

FIGURE 11-41 CMTS-INITIATED DSC........................................................................................................... 280

FIGURE 11-42 DSC—LOCALLY INITIATED TRANSACTION BEGIN STATE FLOW DIAGRAM ......................... 281

FIGURE 11-43 DSC—LOCALLY INITIATED TRANSACTION DSC-RSP PENDING STATE FLOW DIAGRAM.... 282

FIGURE 11-44 DSC—LOCALLY INITIATED TRANSACTION HOLDING DOWN STATE FLOW DIAGRAM ......... 283

FIGURE 11-45 DSC—LOCALLY INITIATED TRANSACTION RETRIES EXHAUSTED STATE FLOW DIAGRAM . 284

FIGURE 11-46 DSC—LOCALLY INITIATED TRANSACTION DELETING SERVICE FLOW STATE FLOW

DIAGRAM ................................................................................................................................ 285

FIGURE 11-47 DSC—REMOTELY INITIATED TRANSACTION BEGIN STATE FLOW DIAGRAM....................... 286

FIGURE 11-48 DSC—REMOTELY INITIATED TRANSACTION DSC-ACK PENDING STATE FLOW DIAGRAM 287

FIGURE 11-49 DSC—REMOTELY INITIATED TRANSACTION HOLDING DOWN STATE FLOW DIAGRAM ...... 288

FIGURE 11-50 DSC—REMOTELY INITIATED TRANSACTION DELETING SERVICE FLOW STATE FLOW

DIAGRAM ................................................................................................................................ 289

FIGURE 11-51 DYNAMIC SERVICE DELETION INITIATED FROM CM ............................................................. 290

FIGURE 11-52 DYNAMIC SERVICE DELETION INITIATED FROM CMTS......................................................... 290

FIGURE 11-53 DSD—LOCALLY INITIATED TRANSACTION BEGIN STATE FLOW DIAGRAM ......................... 291

FIGURE 11-54 DSD—LOCALLY INITIATED TRANSACTION DSD-RSP PENDING STATE FLOW DIAGRAM ... 292

FIGURE 11-55 DSD—LOCALLY INITIATED TRANSACTION HOLDING DOWN STATE FLOW DIAGRAM......... 293

FIGURE 11-56 DSD—REMOTELY INITIATED TRANSACTION BEGIN STATE FLOW DIAGRAM....................... 294

FIGURE 11-57 DSD—REMOTELY INITIATED TRANSACTION HOLDING DOWN STATE FLOW DIAGRAM ...... 295

FIGURE 11-58 DCC EXAMPLE OPERATIONAL FLOW..................................................................................... 304

FIGURE 11-59 DYNAMICALLY CHANGING CHANNELS: CMTS VIEW PART 1............................................... 306



xviii


FIGURE 11-62 DYNAMICALLY CHANGING CHANNELS: CMTS VIEW PART 4................................................309

FIGURE 11-63 DYNAMICALLY CHANGING CHANNELS: CM VIEW PART 1 ....................................................310




FIGURE D-1 BINARY CONFIGURATION FILE FORMAT .................................................................................373

FIGURE D-2 CREATE TLV ENTRIES FOR PARAMETERS REQUIRED BY THE CM.........................................375

FIGURE D-3 ADD CM MIC .........................................................................................................................375

FIGURE D-4 ADD CMTS MIC.....................................................................................................................375

FIGURE D-5 ADD END OF DATA MARKER ..................................................................................................376

FIGURE E-1 SPANNING TREE TOPOLOGY....................................................................................................379

FIGURE E-2 SPANNING TREE ACROSS CMTSES.........................................................................................380

FIGURE F-1 FORMAT OF PACKET PDU FOLLOWING THE TIMING HEADER................................................410

FIGURE H-1 DMPI APPLICATION ................................................................................................................420

FIGURE H-2 DOWNSTREAM DATA SIGNAL PROTOCOL FOR ITU-T RECOMMENDATIONS J.83ANNEX A OPERATION .............................................................................................................425

FIGURE H-3 DOWNSTREAM DATA SIGNAL PROTOCOL FOR ITU-T RECOMMENDATIONS J.83ANNEX B OPERATION..............................................................................................................426

FIGURE H-4 UPSTREAM DATA PROTOCOL ..................................................................................................426

FIGURE H-5 COUNTER SYNCHRONIZATION .................................................................................................427

FIGURE H-6 UPSTREAM CONTROL MESSAGE TRANSFER............................................................................428

FIGURE H-7 SPI BUS TRANSACTION ...........................................................................................................429

FIGURE III-1 SINGLE DOWNSTREAM AND SINGLE UPSTREAM CHANNELS PER CM ....................................454

FIGURE III-2 MULTIPLE DOWNSTREAM AND MULTIPLE UPSTREAM CHANNELS PER CM...........................456

FIGURE IV-1 TRANSMISSION & DEFERENCE STATE TRANSITION DIAGRAM ...............................................459

FIGURE V-1 IGMP SUPPORT – CM PASSIVE MODE.....................................................................................465

FIGURE VI-1 EXAMPLE JITTER WITH MULTIPLE GRANTS PER SID..............................................................468

FIGURE VI-2 VAD START-UP AND STOP .....................................................................................................470

xix



xx


Tables

TABLE 4-1 ASSUMED DOWNSTREAM RF CHANNEL TRANSMISSION CHARACTERISTICS (SEE NOTE 1)......25

TABLE 4-2 ASSUMED UPSTREAM RF CHANNEL TRANSMISSION CHARACTERISTICS (SEE NOTE 1)............26

TABLE 6-1 BURST SIZE................................................................................................................................46

TABLE 6-2 INTERLEAVER OPERATING PARAMETERS ..................................................................................47

TABLE 6-3 I/Q MAPPING .............................................................................................................................64

TABLE 6-4 DEFINITION OF DIFFERENTIAL QUADRANT CODING .................................................................65

TABLE 6-5 MAXIMUM CHANNEL WIDTH ....................................................................................................75

TABLE 6-6 CONSTELLATION GAINS AND POWER LIMITS............................................................................77

TABLE 6-7 BURST PROFILE ATTRIBUTES ....................................................................................................80

TABLE 6-8 USER UNIQUE BURST PARAMETERS..........................................................................................81

TABLE 6-9 SPURIOUS EMISSIONS ................................................................................................................88

TABLE 6-10 ADJACENT CHANNEL SPURIOUS EMISSIONS RELATIVE TO THE TRANSMITTED BURST

POWER LEVEL ...........................................................................................................................89

TABLE 6-11 SPURIOUS EMISSIONS IN 5 TO 42 MHZ RELATIVE TO THE TRANSMITTED BURST

POWER LEVEL ...........................................................................................................................89

TABLE 6-12 FILTER AMPLITUDE DISTORTION...............................................................................................92

TABLE 6-13 MAXIMUM RANGE OF COMMANDED NOMINAL RECEIVE POWER IN EACH CARRIER...............94

TABLE 6-14 ELECTRICAL OUTPUT FROM CM ...............................................................................................95

TABLE 6-15 INTERLEAVER CHARACTERISTICS..............................................................................................95

TABLE 6-16 CMTS OUTPUT..........................................................................................................................97

TABLE 6-17 ELECTRICAL INPUT TO CM .......................................................................................................98

TABLE 6-18 DOWNSTREAM SYMBOL RATES AND EXAMPLE PARAMETERS FOR SYNCHRONIZATION WITH THE

CMTS MASTER CLOCK...........................................................................................................101

TABLE 7-1 MPEG HEADER FORMAT FOR DOCSIS DATA-OVER-CABLE PACKETS.................................104

TABLE 8-1 GENERIC MAC HEADER FORMAT...........................................................................................113

TABLE 8-2 FC FIELD FORMAT ..................................................................................................................113

TABLE 8-3 PACKET PDU FORMAT ............................................................................................................115

TABLE 8-4 RESERVED PDU FORMAT........................................................................................................116

TABLE 8-5 MAC-SPECIFIC HEADERS AND FRAMES .................................................................................116

TABLE 8-6 TIMING MAC HEADER FORMAT .............................................................................................118

TABLE 8-7 MAC MANAGEMENT FORMAT ................................................................................................118

TABLE 8-8 REQUEST FRAME (REQ) FORMAT...........................................................................................119

TABLE 8-9 FRAGMENTATION MAC FRAME (FRAG) FORMAT .................................................................120

TABLE 8-10 CONCATENATED MAC FRAME FORMAT.................................................................................121

TABLE 8-11 EXAMPLE EXTENDED HEADER FORMAT .................................................................................122

TABLE 8-12 EH ELEMENT FORMAT ............................................................................................................122

TABLE 8-13 EXTENDED HEADER TYPES .....................................................................................................123

TABLE 8-14 FRAGMENTATION EXTENDED HEADER FORMAT.....................................................................124

TABLE 8-15 PAYLOAD HEADER SUPPRESSION EHDR SUB-ELEMENT FORMAT.........................................125

TABLE 8-16 UNSOLICITED GRANT SYNCHRONIZATION EHDR SUB-ELEMENT FORMAT ...........................126

TABLE 8-17 MAC MANAGEMENT MESSAGE TYPES...................................................................................131

TABLE 8-18 CHANNEL TLV PARAMETERS .................................................................................................134

xxi


TABLE 8-19 UPSTREAM PHYSICAL-LAYER BURST ATTRIBUTES................................................................ 137

TABLE 8-20 ALLOCATION MAP INFORMATION ELEMENTS (IE)................................................................ 143

TABLE 8-21 RANGING RESPONSE MESSAGE ENCODINGS ....................................................................... 147

TABLE 8-22 CHANNEL TLV PARAMETERS................................................................................................. 181

TABLE 9-1 IE FEATURE COMPATIBILITY SUMMARY................................................................................ 188

TABLE 9-2 EXAMPLE RELATING MINI-SLOTS TO TIME TICKS................................................................. 194

TABLE 9-3 EXAMPLE OF MINI-SLOT CAPACITY IN S-CDMA MODE........................................................ 195

TABLE 9-4 TRANSMIT OPPORTUNITY ....................................................................................................... 197

TABLE 10-1 TFTP FILE CONTENTS ............................................................................................................ 211

TABLE 10-2 REGISTRATION REQUEST CONTENTS...................................................................................... 211

TABLE 10-3 REGISTRATION RESPONSE CONTENTS .................................................................................... 212

TABLE 10-4 PARAMETER APPLICABILITY FOR UPSTREAM SERVICE SCHEDULING .................................... 217

TABLE 10-5 PAYLOAD HEADER SUPPRESSION DEFINITIONS...................................................................... 225

TABLE 11-1 FACTORS AFFECTING DCC PERFORMANCE............................................................................. 300

TABLE 11-2 RECOVERY PROCESS ON LOSS OF SPECIFIC MAC MESSAGES ............................................... 316

TABLE C-1 SAMPLE DOCSIS 1.0 CLASS OF SERVICE ENCODING ............................................................ 328

TABLE C-2 VALUES USED IN REG-REQ AND REG-RSP MESSAGES ...................................................... 352

TABLE C-3 VALUES USED IN REG-REQ, REG-RSP, AND DYNAMIC SERVICE MESSAGES .................... 352

TABLE E-1 CM PATH COST ...................................................................................................................... 381

TABLE F-1 ASSUMED DOWNSTREAM RF CHANNEL TRANSMISSION CHARACTERISTICS FOR ANALOGUE

TV AND SOUND SIGNALS ........................................................................................................ 385

TABLE F-2 ASSUMED UPSTREAM RF CHANNEL TRANSMISSION CHARACTERISTICS ................................. 386

TABLE F-3 CONSTELLATION GAINS AND POWER LIMITS ......................................................................... 391

TABLE F-4 BURST PROFILE ATTRIBUTES ................................................................................................. 394

TABLE F-5 USER UNIQUE BURST PARAMETERS....................................................................................... 395

TABLE F-6 SPURIOUS EMISSIONS............................................................................................................. 397

TABLE F-7 ADJACENT CHANNEL SPURIOUS EMISSIONS RELATIVE TO THE TRANSMITTED BURST

POWER LEVEL......................................................................................................................... 398

TABLE F-8 SPURIOUS EMISSIONS IN 5 TO 65 MHZ RELATIVE TO THE TRANSMITTED BURST

POWER LEVEL......................................................................................................................... 398

TABLE F-9 MAXIMUM RANGE OF COMMANDED NOMINAL RECEIVE POWER IN EACH CARRIER............ 401

TABLE F-10 ELECTRICAL OUTPUT FROM CM ............................................................................................ 401

TABLE F-11 INTERLEAVER CHARACTERISTICS ........................................................................................... 402

TABLE F-12 CMTS OUTPUT ....................................................................................................................... 403

TABLE F-13 ELECTRICAL INPUT TO CM..................................................................................................... 404

TABLE F-14 256QAM CM BER PERFORMANCE........................................................................................ 405

TABLE F-15 DOWNSTREAM SYMBOL RATES AND EXAMPLE PARAMETERS FOR SYNCHRONIZATION WITH THE

CMTS MASTER CLOCK ......................................................................................................... 407

TABLE F-16 MPEG HEADER FORMAT FOR EURO-DOCSIS DATA-OVER-CABLE PACKETS ...................... 408

TABLE G-1 REGISTRATION BEHAVIOR FOR A DOCSIS 2.0 CM............................................................... 413

TABLE G-2 HYBRID MODE CONTROLS ..................................................................................................... 415

TABLE H-1 TIMING PARAMETERS ............................................................................................................. 418

TABLE H-2 DOWNSTREAM DATA INTERFACE SIGNALS ............................................................................ 422

TABLE H-3 UPSTREAM DATA INTERFACE SIGNALS .................................................................................. 422

xxii


TABLE H-4 UPSTREAM CONTROL INTERFACE SIGNALS.............................................................................423

TABLE H-5 SPI BUS SIGNALS ....................................................................................................................423

TABLE H-6 TIMESTAMP COUNTER INITIALIZATION OPTIONS ....................................................................427

TABLE H-7 DC CHARACTERISTICS ............................................................................................................430

TABLE H-8 DS DATA INTERFACE TIMING .................................................................................................431

TABLE H-9 US DATA INTERFACE TIMING .................................................................................................431

TABLE H-10 UPSTREAM CONTROL INTERFACE TIMING ..............................................................................431

TABLE H-11 SPI BUS TIMING ......................................................................................................................432

TABLE H-12 UPSTREAM DATA BLOCK FORMAT .........................................................................................432

TABLE H-13 UPSTREAM DATA BLOCK TYPES.............................................................................................433

TABLE H-14 FIRST_DATA DATA FORMAT ...............................................................................................433

TABLE H-15 MIDDLE_DATA DATA FORMAT...........................................................................................434

TABLE H-16 LAST_DATA DATA FORMAT ................................................................................................434

TABLE H-17 PHY_STATUS DATA FORMAT ..............................................................................................434

TABLE H-18 NO_BURST DATA FORMAT...................................................................................................435

TABLE H-19 CHANNEL DATA FORMAT ....................................................................................................435

TABLE H-20 UPSTREAM CONTROL MESSAGE FORMAT ...............................................................................439

TABLE H-21 UPSTREAM MESSAGE TYPES ...................................................................................................439

TABLE H-22 UPSTREAM CONTROL INTERVAL DESCRIPTION PAYLOAD FORMAT....................................439

TABLE H-23 UCD CHANGE PAYLOAD FORMAT ......................................................................................440

TABLE H-24 SPI BUS TRANSACTION FORMAT ............................................................................................440

TABLE III-1 MAC MESSAGES WITH CHANNEL IDS ....................................................................................457

TABLE VI-1 EXAMPLE REQUEST TO GRANT RESPONSE TIME ....................................................................471

TABLE VI-2 EXAMPLE EXTRA GRANTS FOR NEW TALK SPURTS ...............................................................472

TABLE VIII-1 ALLOWABLE PLANT TIMING DRIFT ..........................................................................................475

TABLE X-1 INCORPORATED ECN TABLE...................................................................................................481

TABLE X-2 INCORPORATED ECN TABLE...................................................................................................482

xxiii



xxiv


Radio Frequency Interface Specification

1 Scope and Purpose

1.1 Scope

This document defines the second generation of radio-frequency interface specifications for high-speed data-over-cable systems. They were developed by Cable Television Laboratories (CableLabs) for the benefit of thecable industry, including contributions by operators and vendors from North America, Europe, and other regions.

There are differences in the cable spectrum planning practices adopted for different networks in the world.Therefore two options for physical layer technology are included, which have equal priority and are not requiredto be inter-operable. One technology option is based on the downstream multi-programme television distributionthat is deployed in North America using 6 MHz channelling, and supports upstream transmission in the 5-42MHz region. The other technology option is based on the corresponding European multi-programme televisiondistribution and supports upstream in the 5-65 MHz region. Both options have the same status, notwithstandingthat the document structure does not reflect this equal priority. The first of these options is defined in Sections 4,6, 7, and Annex G and Section C.1.1.1, whereas the second is defined by replacing the content of those sectionswith the content of Annex F. Correspondingly, [ITU-T J.83-B], [NCTA], and [SMS] apply only to the firstoption, and [EN 300 429] only to the second. Compliance with this document requires compliance with one orother of these implementations, not with both. It is not required that equipment built to one option shall inter-operate with equipment built to the other.

These optional physical-layer technologies allow operators some flexibility within any frequency planning, EMCand safety requirements that are mandated for their area of operation. For example, the 6 MHz downstream-based option defined by Sections 4, 6, and 7 might be deployable within an 8 MHz channel plan. Compliancewith frequency planning and EMC requirements is not covered by this specification and remains the operators’responsibility. In this respect, [FCC15], [FCC76], and [EIA-S542] are relevant to North America and [EN50081-1], [EN 50082-1], [EN 50083-2], [EN 50083-7], and [EN 50083-10] are relevant to the EuropeanCommunity.

The option of Sections 4, 6 and 7 together with Annex G and Section C.1.1.1 is required to be backwardscompatible with an earlier version of that technology [DOCSIS9], whereas the option of Annex F was notincluded in [DOCSIS9] and therefore is not required to be backwards compatible with [DOCSIS9].

Any reference in this document to the transmission of television in the forward channel that is not consistent with[EN 300 429] is outside the normative scope as only [EN 300 429] is used for digital multi-program TVdistribution by cable in European applications.

Requirements for safety are outside the scope of the present document. Safety standards for Europeanapplications are published by CENELEC.

Note 1: Examples of such CENELEC product safety standards are [EN 60950] and [EN 50083-1].

Note 2: For CENELEC safety categories of interfaces, see [EG 201 212].

1


1.2 Requirements

Throughout this document, the words that are used to define the significance of particular requirements arecapitalized. These words are:

This document defines many features and parameters, and a valid range for each parameter is usually specified.Equipment (CM and CMTS) requirements are always explicitly stated. Equipment must comply with allmandatory (MUST and MUST NOT) requirements to be considered compliant with this specification. Support ofnon-mandatory features and parameter values is optional.

1.3 Background

1.3.1 Service Goals

As cable operators have widely deployed high-speed data services on cable television systems, the demand forupstream bandwidth has increased, particularly with the popularity of more symmetric data applications. To thisend, CableLabs’ member companies have decided to add advanced modulation techniques to the DOCSISspecification, for the purpose of increasing channel capacity and improving noise immunity.

The intended service will allow transparent bi-directional transfer of Internet Protocol (IP) traffic, between thecable system head-end and customer locations, over an all-coaxial or hybrid-fiber/coax (HFC) cable network.This is shown in simplified form in Figure 1-1.

Figure 1-1 Transparent IP Traffic Through the Data-Over-Cable System

MUST This word or the adjective “REQUIRED” means that the item is an absoluterequirement of this specification.

MUST NOT This phrase means that the item is an absolute prohibition of this specification.

SHOULD This word or the adjective “RECOMMENDED” means that there may exist validreasons in particular circumstances to ignore this item, but the full implications shouldbe understood and the case carefully weighed before choosing a different course.

SHOULD NOT This phrase means that there may exist valid reasons in particular circumstances whenthe listed behavior is acceptable or even useful, but the full implications should beunderstood and the case carefully weighed before implementing any behaviordescribed with this label.

MAY This word or the adjective “OPTIONAL” means that this item is truly optional. Onevendor may choose to include the item because a particular marketplace requires it orbecause it enhances the product, for example; another vendor may omit the same item.

Wide-AreaNetwork

CableNetwork

Transparent IP Traffic Through the System

Cable Modem(CM)

CMTSNetwork Side

Interface

CableModem

TerminationSystemCMTS CM Customer Premises

Equipment Interface

CustomerPremises

Equipment

2


The transmission path over the cable system is realized at the head-end by a Cable Modem Termination System(CMTS), and at each customer location by a Cable Modem (CM). At the head-end (or hub), the interface to thedata-over-cable system is called the Cable Modem Termination System - Network-Side Interface (CMTS-NSI)and is specified in [DOCSIS3]. At the customer locations, the interface is called the cable-modem-to-customer-premises-equipment interface (CMCI) and is specified in [DOCSIS4]. The intent is for operators to transparentlytransfer IP traffic between these interfaces, including but not limited to datagrams, DHCP, ICMP, and IP Groupaddressing (broadcast and multicast).

1.3.2 Reference Architecture

The reference architecture for the data-over-cable services and interfaces is shown in Figure 1-2.

Note: This architecture illustrates the North American frequency plans only and is not normative for European applications.Refer to Section 1.1 for applicability.

3


Fig

ure

1-2

Dat

a-O

ver-

Cab

leR

efer

ence

Arc

hit

ectu

re

PS

TN

Backb

on

eN

etw

ork

Telc

oR

etu

rnA

ccess

Conce

n-

trato

r(T

RA

C)

Generic

Headend

Sw

itch

or

Back

bone

Tra

nsp

ort

Adapte

r

Loca

lS

erv

er

Faci

lity

Rem

ote

Serv

er

Faci

lity

Cable

Modem

Term

inatio

nS

yste

m Mo

d

De

mo

d

Da

taO

ver

Ca

ble

Sys

tem

OS

SIn

terf

ace

,DO

CS

-OS

SI

Secu

rity

&A

ccess

Contr

olle

r

Ba

selin

eP

riva

cyIn

terf

ace

(BP

I)

Ca

ble

Mod

em

Te

rmin

atio

nS

yste

mN

etw

ork

Sid

eIn

terf

ace

,C

MT

S-N

SI

Upst

rea

msp

litte

ra

nd

filte

rb

an

k

Tx

Rx

Ca

ble

Mo

de

mT

erm

ina

tion

Sys

tem

Up

stre

am

RF

Inte

rfa

ce

50

–8

60M

Hz

5–

42

MH

z

Ca

ble

Mo

dem

Te

rmin

atio

nS

yste

mD

ow

nst

ream

RF

Inte

rfa

ce

Vid

eo

1

Vid

eo

2

Da

ta.

Da

ta . . .

Dis

trib

utio

nN

etw

ork

O/E

Node

O/E

Node

O/E

Node

Fib

er

Te

lco

retu

rn

Cab

leM

od

em

Te

lco

Re

turn

Inte

rfa

ce,C

MT

RI

Co

ax

Cable

Modem

Cust

om

er

Pre

mis

eE

quip

ment

Ca

ble

Mo

dem

toR

FIn

terf

ace

,

Ca

ble

Mo

dem

toC

PE

Inte

rfa

ce,

CM

CI

WA

N

WA

N

Co

pp

er

Pairs,

DS

1or

DS

3

Ne

two

rkT

erm

ina

tion

Dis

trib

uti

on

Hu

bo

rH

ea

de

nd

Op

era

tio

ns

Su

pp

ort

Sys

tem

.

Com biner

4


1.3.3 Categories of Interface Specification

The basic reference architecture of Figure 1-2 involves five interface categories.

Data Interfaces - These are the CMCI [DOCSIS4] and CMTS-NSI [DOCSIS3], corresponding respectively tothe cable-modem-to-customer-premises-equipment (CPE) interface (for example, between the customer’scomputer and the cable modem), and the cable modem termination system network-side interface between thecable modem termination system and the data network.

Operations Support Systems Interfaces - These are network element management layer interfaces between thenetwork elements and the high-level OSSs (operations support systems) which support the basic businessprocesses, and are documented in [DOCSIS5].

RF Interfaces - The RF interfaces defined in this document are the following:

• Between the cable modem and the cable network

• Between the CMTS and the cable network, in the downstream direction (toward the customer)

• Between the CMTS and the cable network, in the upstream direction (traffic from the customer)

Security Interfaces - Baseline data-over-cable security is defined in [DOCSIS8].

1.3.3.1 Data-Over-Cable Service Interface Documents

A list of the documents in the Data-Over-Cable Service Interface Specifications family is provided below. Forupdates, please refer to http://www.cablemodem.com/.

1.3.4 Statement of Compatibility

This document specifies an interface, commonly referred to as DOCSIS 2.0, which is the second generation ofthe interface specified in [DOCSIS9] and [DOCSIS11], commonly referred to as DOCSIS 1.x. DOCSIS 2.0 mustbe backward- and forward-compatible with equipment built to the previous specifications. DOCSIS 2.0-compliant CMs MUST interoperate seamlessly with DOCSIS 1.x CMTSes, albeit in the 1.x mode, as the casemay be. DOCSIS 2.0-compliant CMTSes MUST seamlessly support DOCSIS 1.x CMs.

Refer to Annex G for further interoperability information.

1.4 Conventions for this Specification

In this specification the following convention applies any time a bit field is displayed in a figure. The bit fieldshould be interpreted by reading the figure from left to right, then from top to bottom, with the MSB being thefirst bit so read and the LSB being the last bit so read.

Designation Title

SP-CMCI Cable Modem to Customer Premises Equipment Interface Specification

SP-CMTS-NSI Cable Modem Termination System Network Side Interface Specification

SP-CMTRI Cable Modem Telco Return Interface Specification

SP-OSSI Operations Support System Interface Specification

SP-RFI Radio Frequency Interface Specification

SP-BPI+ Baseline Privacy Plus Interface Specification

5



6


2 References (normative/informative)

[CableLabs1] Digital Transmission Characterization of Cable Television Systems, Cable TelevisionLaboratories, Inc., November, 1994.

[DIX] Ethernet Protocol Version 2.0, Digital, Intel, Xerox, 1982.

[DOCSIS3] Data-Over-Cable Service Interface Specifications, Cable Modem Termination System - NetworkSide Interface Specification, SP-CMTS-NSI-I01-960702.

[DOCSIS4] Data-Over-Cable Service Interface Specifications, Cable Modem to Customer Premise EquipmentInterface Specification, SP-CMCI-I08-020830.

[DOCSIS5] Data-Over-Cable Service Interface Specifications, Operations Support System InterfaceSpecification, SP-OSSIv2.0-I03-021218.

[DOCSIS6] Data-Over-Cable Service Interface Specifications, Cable Modem Telephony Return InterfaceSpecification, SP-CMTRI-I01-970804.

[DOCSIS8] Data-Over-Cable Service Interface Specifications, Baseline Privacy Plus Interface Specification,SP-BPI+-I09-020830.

[DOCSIS9] Data-Over-Cable Service Interface Specifications, Radio Frequency Interface Specification, SP-RFI-C01-011119.

[DOCSIS10] Data-Over-Cable Service Interface Specifications, Baseline Privacy Interface Specification, SP-BPI-C01-011119.

[DOCSIS11] Data-Over-Cable Service Interface Specifications, Radio Frequency Interface Specification v1.1,SP-RFIv1.1-I09-020830.

[EIA-S542] EIA Standard 542 (1997), “Cable Television Channel Identification Plan”, May 1997.

[EG 201 212] ETSI EG 201 212: “Electrical safety; Classification of interfaces for equipment to be connectedto telecommunication networks”. Also available from CENELEC as ROBT-002.

[EN 300 429] ETSI EN 300 429 V1.2.1: “Digital Video Broadcasting (DVB); Framing structure, channelcoding and modulation for cable systems”, April 1998.

[EN 50081-1] CENELEC EN 50081-1 Electromagnetic compatibility generic emission standard Part 1:Residential, commercial and light industry.

[EN 50082-1] CENELEC EN 50082-1 Electromagnetic compatibility generic immunity standard Part 1:Residential, commercial and light industry.

[EN 50083-1] CENELEC EN 50083-1:1993: “Cabled distribution systems for television, sound andinteractive multimedia signals, Part 1: Safety requirements”.

[EN 50083-2] CENELEC EN 50083-2: 1995 “Cabled distribution systems for television, sound and interactivemultimedia signals, Part 2: Electromagnetic compatibility for equipment”.

[EN 50083-7] CENELEC EN 50083-7: “Cable networks for television signals, sound signals and interactiveservices, Part 7: System performance”.

7


[EN 50083-10] CENELEC EN 50083-10: “Cable networks for television signals, sound signals and interactiveservices, Part 10: System performance of return paths”.

[EN 60950] CENELEC EN 60950: “Safety of information technology equipment”.

[FCC15] Code of Federal Regulations, Title 47, Part 15, October 2000.

[FCC76] Code of Federal Regulations, Title 47, Part 76, October 2000.

[ID-IGMP] Fenner W., et al., IGMP-based Multicast Forwarding (“IGMP Proxying”), IETF Internet Draft,http://www.ietf.org/internet-drafts/draft-ietf-magma-igmp-proxy-00.txt

[IEEE802] IEEE Std 802-1990, Local and Metropolitan Area Networks: Overview and Architecture.

[IEEE802.1Q] IEEE Standard 802.1Q. Virtual Bridged Local Area Networks. December 8, 1998.

[IMA] Internet Assigned Numbers Authority, Internet Multicast Addresses,http://www.iana.org/assignments/multicast-addresses

[ISO-169-24] ISO-169-24 F connector, female, indoor

[ISO8025] ISO 8025 (December 1987) – Information processing systems - Open Systems Interconnection -Specification of the Basic Encoding Rules for Abstract Syntax Notation One (ASN.1).

[ISO8802-2] ISO/IEC 8802-2: 1994 (IEEE Std 802.2: 1994) - Information technology - Telecommunicationsand information exchange between systems - Local and metropolitan area networks - Specific requirements -Part 2: Logical link control

[ISO8802-3] ISO/IEC 8802-3: 1996 (IEEE Std 802.3: 1996) - Information technology - Telecommunicationsand information exchange between systems - Local and metropolitan area networks - Part 3: Carrier sensemultiple access with collision detection (CSMA/CD) access method and physical sublayer specifications.

[ISO/IEC10038] ISO/IEC 10038 (ANSI/IEEE Std 802.1D): 1993, Information technology -Telecommunications and information exchange between systems - Local area networks - Media access control(MAC) bridges.

[ISO/IEC10039] ISO/IEC 10039:1991 Information technology – Open Systems Interconnection –Local areanetworks –Medium Access Control (MAC) service definition.

[ITU-T H.222.0] ITU-T Recommendation H.222.0 (2000) and ISO/IEC 13818-1:2000, Informationtechnology - generic coding of moving pictures and associated audio information systems.

[ITU-T J.83-B] Annex B to ITU-T Recommendation J.83 (4/97), Digital multi-programme systems fortelevision sound and data services for cable distribution.

[ITU-T X.25] ITU-T Recommendation X.25 (10/96), Interface between data terminal equipment and datacircuit-terminating equipment for terminals operating in the packet mode and connected to public data networksby dedicated circuit.

[ITU-T Z.100] ITU-T Recommendation Z.100 (11/99) - CCITT Specification and description language(SDL).

[NCTA] NCTA Recommended Practices for measurement on Cable Television Systems - National CableTelevision Association, Washington DC, 2nd Edition, revised October, 1993.

8


[PKT-MGCP] PacketCable Specifications, Network-Based Call Signaling Protocol Specification, PKT-SP-EC-MGCP-I03-010620.

[PKT-DQOS] PacketCable Specifications, Dynamic Quality of Service Specification, PKT-SP-DQOS-I02-000818.

[RFC-791] Postel, J., Internet Protocol, IETF RFC-791 (MIL STD 1777), September, 1981.

[RFC-826] Plummer, D., Ethernet Address Resolution Protocol: Or converting network protocol addresses to48-bit Ethernet address for transmission on Ethernet hardware, November, 1982.

[RFC-868] Harrenstien, K., and Postel, J., Time Protocol, IETF RFC-868, May 1983.

[RFC-1042] Postel, J., and Reynolds, J., A Standard for the Transmission of IP Datagrams over IEEE 802Networks, IETF RFC-1042, February, 1988.

[RFC-1058] Hedrick, C., Routing Information Protocol, IETF RFC-1058, June, 1988.

[RFC-1123] Braden, R., Requirements for Internet Hosts – Application and Support, IETF RFC-1123, October1989.

[RFC-1157] Schoffstall, M., Fedor, M., Davin, J. and Case, J., A Simple Network Management Protocol(SNMP), IETF RFC-1157, May, 1990.

[RFC-1350] Sollings, K., The TFTP Protocol (Revision 2), IETF RFC-1350, July, 1992.

[RFC-1493] Definitions of Managed Objects for Bridges. E. Decker, P. Langille, A. Rijsinghani, & K.McCloghrie. July 1993. (Obsoletes RFC1286)

[RFC-1633] Braden, R., Clark, D., and Shenker, S., Integrated Services in the Internet Architecture: AnOverview, IETF RFC-1633, June, 1994.

[RFC-1812] Baker, F., Requirements for IP Version 4 Routers, IETF RFC-1812. June, 1995.

[RFC-2104] Krawczyk, H., Bellare, M., and Canetti, R., HMAC: Keyed-Hashing for Message Authentication,IETF RFC-2104, February, 1997.

[RFC-2131] Droms, R., Dynamic Host Configuration Protocol, IETF RFC-2131, March, 1997.

[RFC-2132] Alexander, S., and Droms, R., DHCP Options and BOOTP Vendor Extensions, IETF RFC-2132,March, 1997.

[RFC-2210] Wroclawski, J., The Use of RSVP with the IETF Integrated Services, IETF RFC-2210,September, 1997.

[RFC-2211] Wroclawski, J., Specification of the Controlled-Load Network Element Service, IETF RFC-2211,September, 1997.

[RFC-2212] Shenker, S., Partridge, C., and Guerin, R., Specification of Guaranteed Quality of Service, IETFRFC-2212, September, 1997.

[RFC-2236] Fenner, W., Internet Group Management Protocol, Version 2, IETF RFC-2236, November 1997.

9


[RFC-2349] Malkin, G. and Harkin, A., TFTP Timeout Interval and Transfer Size Options, IETF RFC-2349,May 1998.

[RFC-2669] St. Johns, M., DOCSIS Cable Device MIB Cable Device Management Information Base forDOCSIS Compliant Cable Modems and Cable Modem Termination Systems, IETF RFC-2669, August 1999.

[RFC-2786] St. Johns, M., Diffie-Helman [sic] USM Key Management Information Base and TextualConvention, IETF RFC-2786, March, 2000.

[RFC-3046] Patrick, M., DHCP Relay Agent Information Option, IETF RFC-3046, January, 2001.

[SHA] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.

[SMS] The Spectrum Management Application (SMA) and the Common Spectrum Management Interface(csmi), Time Warner Cable, December 24, 1995.

10


3 Glossary (informative)

Active Service Flow An admitted Service Flow from the CM to the CMTS which is available for packettransmission.

Address Resolution Protocol (ARP) A protocol of the IETF for converting network addresses to 48-bitEthernet addresses.

Admitted Service Flow A Service Flow, either provisioned or dynamically signaled, which is authorized andfor which resources have been reserved but is not active.

Allocation A group of contiguous mini-slots in a MAP which constitute a single transmit opportunity.

American National Standards Institute (ANSI) A US standards body.

ANSI See American National Standards Institute.

ARP See Address Resolution Protocol.

Asynchronous Transfer Mode (ATM) A protocol for the transmission of a variety of digital signals usinguniform 53-byte cells.

ATM See Asynchronous Transfer Mode.

A-TDMA DOCSIS 2.0 TDMA mode (as distinguished from DOCSIS 1.x TDMA).

Authorization Module The authorization module is an abstract module that the CMTS can contact toauthorize Service Flows and Classifiers. The authorization module tells the CMTS whether the requesting CM isauthorized for the resources it is requesting.

Availability In cable television systems, availability is the long-term ratio of the actual RF channel operationtime to scheduled RF channel operation time (expressed as a percent value) and is based on a bit error rate (BER)assumption.

Bandwidth Allocation Map The MAC Management Message that the CMTS uses to allocate transmissionopportunities to CMs.

BPDU See Bridge Protocol Data Unit.

Bridge Protocol Data Unit (BDU) Spanning tree protocol messages as defined in [ISO/IEC10038].

Broadcast Addresses A predefined destination address that denotes the set of all data network service accesspoints.

Burst A single continuous RF signal from the upstream transmitter, from transmitter on to transmitter off.

Burst Error Second Any Errored Second containing at least 100 errors.

Cable Modem (CM) A modulator-demodulator at subscriber locations intended for use in conveying datacommunications on a cable television system.

11


Cable Modem Termination System (CMTS) Cable modem termination system, located at the cabletelevision system head-end or distribution hub, which provides complementary functionality to the cablemodems to enable data connectivity to a wide-area network.

Cable Modem Termination System - Network Side Interface (CMTS-NSI) The interface, defined in[DOCSIS3], between a CMTS and the equipment on its network side.

Cable Modem to CPE Interface (CMCI) The interface, defined in [DOCSIS4], between a CM and CPE.

Carrier Hum Modulation The peak-to-peak magnitude of the amplitude distortion relative to the RF carriersignal level due to the fundamental and low-order harmonics of the power-supply frequency.

Carrier-to-Noise Ratio (C/N or CNR) The ratio of signal power to noise power in the defined measurementbandwidth. For digital modulation, CNR = Es/N0, the energy-per-symbol to noise-density ratio; the signal poweris measured in the occupied bandwidth, and the noise power is normalized to the modulation-rate bandwidth.For video, the measurement bandwidth is 4 MHz.

CCCM CPE Controlled Cable Modem. Refer to the DOCSIS Cable Modem to Customer Premise EquipmentInterface (CMCI) specification.

Channel The frequency spectrum occupied by a signal. Usually specified by center frequency and bandwidthparameters.

Chip Each of the 128 bits comprising the S-CDMA spreading codes.

Chip Duration The time to transmit one chip of the S-CDMA spreading code. The inverse of the chip rate.

Chip Rate The rate at which individual chips of the S-CDMA spreading codes are transmitted. (1280 to 5120kHz)

Classifier A set of criteria used for packet matching according to TCP, UDP, IP, LLC, and/or 802.1P/Q packetfields. A classifier maps each packet to a Service Flow. A Downstream Classifier is used by the CMTS to assignpackets to downstream service flows. An Upstream Classifier is used by the CM to assign packets to upstreamservice flows.

CM See Cable Modem.

CMCI See Cable Modem to CPE Interface.

CMTS See Cable Modem Termination System.

CMTS-NSI See Cable Modem Termination System - Network Side Interface.

Code Hopping Matrix A shifted version of the reference code matrix (see below) that is used when codehopping is employed to vary the codes used by each CM. The Code Hopping Matrix is either 128 rows by 128columns (when all 128 codes are active) or is 127 rows by 128 columns (when less than 128 codes are active inthe S-CDMA spreader-on frame). When less than 128 codes are active, Code 0 (all ones) is deleted from thematrix, but all remaining codes are still cycled through even if less than 127 codes are active in a frame.

Composite Second Order Beat (CSO) The peak of the average level of distortion products due to second-order non-linearities in cable system equipment.

Composite Triple Beat (CTB) The peak of the average level of distortion components due to third-order non-linearities in cable system equipment.

12


CPE See Customer Premises Equipment.

Cross-Modulation A form of television signal distortion where modulation from one or more televisionchannels is imposed on another channel or channels.

Customer See End User.

Customer Premises Equipment (CPE) Equipment at the end user’s premises; MAY be provided by the enduser or the service provider.

Data Link Layer Layer 2 in the Open System Interconnection (OSI) architecture; the layer that providesservices to transfer data over the transmission link between open systems.

DCC Dynamic Channel Change.

DHCP See Dynamic Host Configuration Protocol.

Distribution Hub A location in a cable television network which performs the functions of a head-end forcustomers in its immediate area, and which receives some or all of its television program material from a MasterHead-end in the same metropolitan or regional area.

DOCSIS Data-Over-Cable Service Interface Specifications.

DOCSIS 1.x Abbreviation for “DOCSIS 1.0 or 1.1”.

Downstream In cable television, the direction of transmission from the head-end to the subscriber.

Drop Cable Coaxial cable that connects to a residence or service location from a directional coupler (tap) onthe nearest coaxial feeder cable.

Dynamic Host Configuration Protocol (DHCP) An Internet protocol used for assigning network-layer (IP)addresses.

Dynamic Range The ratio between the greatest signal power that can be transmitted over a multichannelanalog transmission system without exceeding distortion or other performance limits, and the least signal powerthat can be utilized without exceeding noise, error rate or other performance limits.

ECN See Engineering Change Notice.

ECO See Engineering Change Order.

ECR See Engineering Change Request.

Electronic Industries Association (EIA) A voluntary body of manufacturers which, among other activities,prepares and publishes standards.

End User A human being, organization, or telecommunications system that accesses the network in order tocommunicate via the services provided by the network.

Engineering Change Notice The final step in the procedure to change specifications.

Engineering Change Order The second step in the procedure to change specifications. DOCSIS posts ECOto web site EC table and ECO page (with indication of ECO Comment Deadline). DOCSIS issues ECOannouncement to DOCSIS-announce and working group mail lists (with indication of ECO Comment Deadline).

13


Engineering Change Request The first step in the procedure to change specifications. DOCSIS issues ECRnumber, posts to web site EC table and ECR page. DOCSIS sends ECR to subject area working group mail list(and author).

Errored Second Any 1-sec interval containing at least one bit error.

Extended Subsplit A frequency division scheme that allows bidirectional traffic on a single coaxial cable.Reverse path signals come to the head-end from 5 to 42 MHz. Forward path signals go from the head-end from50 or 54 MHz to the upper frequency limit.

FDDI See Fiber Distributed Data Interface.

Feeder Cable Coaxial cables that run along streets within the served area and connect between the individualtaps which serve the customer drops.

Fiber Distributed Data Interface (FDDI) A fiber-based LAN standard.

Fiber Node A point of interface between a fiber trunk and the coaxial distribution.

Forward Channel The direction of RF signal flow away from the head-end toward the end user; equivalent toDownstream.

Frame See MAC frame, S-CDMA frame, and MPEG frame.

Group Delay The difference in transmission time between the highest and lowest of several frequenciesthrough a device, circuit or system.

Guard Band Minimum time allocated between bursts in the upstream referenced from the symbol center ofthe last symbol of a burst to the symbol center of the first symbol of the following burst. The guard band shouldbe at least the duration of five symbols plus the maximum system timing error.

Guard Time The term guard time is similar to the guard band, except that it is measured from the end of thelast symbol of one burst to the beginning of the first symbol of the preamble of an immediately following burst.Thus, the guard time is equal to the guard band – 1.1

Harmonic Related Carrier (HRC) A method of spacing television channels on a cable television system inexact 6-MHz increments, with all carrier frequencies harmonically related to a common reference.

Head-end The central location on the cable network that is responsible for injecting broadcast video and othersignals in the downstream direction. See also Master Head-End, Distribution Hub.

Header Protocol control information located at the beginning of a protocol data unit.

HFC See Hybrid Fiber/Coax (HFC) System.

High Frequency (HF) Used in this document to refer to the entire subsplit (5-30 MHz) and extended subsplit(5-42 MHz) band used in reverse channel communications over the cable television network.

High Return A frequency division scheme that allows bi-directional traffic on a single coaxial cable. Reversechannel signals propagate to the head-end above the downstream passband.

1. “Guard Time” entry revised, “Guard Band” entry added per RFI2-N-02085 by RKV on 10/28/02.

14


Hum Modulation Undesired modulation of the television visual carrier by the fundamental or low-orderharmonics of the power supply frequency, or other low-frequency disturbances.

Hybrid Fiber/Coax (HFC) System A broadband bidirectional shared-media transmission system using fibertrunks between the head-end and the fiber nodes, and coaxial distribution from the fiber nodes to the customerlocations.

ICMP See Internet Control Message Protocol.

IE See Information Element.

IEEE See Institute of Electrical and Electronic Engineers.

IETF See Internet Engineering Task Force.

IGMP See Internet Group Management Protocol.

Incremental Related Carriers (IRC) A method of spacing NTSC television channels on a cable televisionsystem in which all channels except 5 and 6 correspond to the standard channel plan, used to reduce compositetriple beat distortions.

Institute of Electrical and Electronic Engineers (IEEE) A voluntary organization which, among otherthings, sponsors standards committees and is accredited by the American National Standards Institute.

International Electrotechnical Commission (IEC) An international standards body.

International Organization for Standardization (ISO) An international standards body, commonly knownas the International Standards Organization.

Internet Control Message Protocol (ICMP) An Internet network-layer protocol.

Internet Engineering Task Force (IETF) A body responsible, among other things, for developing standardsused in the Internet.

Internet Group Management Protocol (IGMP) A network-layer protocol for managing multicast groups onthe Internet

Impulse Noise Noise characterized by non-overlapping transient disturbances.

Information Element The fields that make up a MAP and define individual grants, deferred grants, etc.

Internet Protocol (IP) An Internet network-layer protocol.

Interval Usage Code A field in MAPs and UCDs to link burst profiles to grants.

IP See Internet Protocol.

IUC See Interval Usage Code.

Latency The time, expressed in quantity of symbols, taken for a signal element to pass through a device.

Layer A subdivision of the Open System Interconnection (OSI) architecture, constituted by subsystems of thesame rank

15


Link Layer See Data Link Layer.

LLC See Logical Link Control (LLC) procedure.

Local Area Network (LAN) A non-public data network in which serial transmission is used for direct datacommunication among data stations located on the user’s premises.

Logical Link Control (LLC) procedure In a local area network (LAN) or a Metropolitan Area Network(MAN), that part of the protocol that governs the assembling of data link layer frames and their exchangebetween data stations, independent of how the transmission medium is shared.

Logical (Upstream) Channel A MAC entity identified by a unique channel ID and for which bandwidth isallocated by an associated MAP message. A physical upstream channel may support multiple logical upstreamchannels. The associated UCD and MAP messages completely describe the logical channel.

MAC See Media Access Control (MAC) procedure.

MAC Frame MAC header plus optional PDU.

MAC Service Access Point An attachment to a MAC-sublayer domain. Refer to Sections 5.2 and 8.1.2.2.

MAP See Bandwidth Allocation Map.

Master Head-End A head-end which collects television program material from various sources by satellite,microwave, fiber and other means, and distributes this material to Distribution Hubs in the same metropolitan orregional area. A Master Head-End MAY also perform the functions of a Distribution Hub for customers in itsown immediate area.

Mean Time to Repair (MTTR) In cable television systems, the MTTR is the average elapsed time from themoment a loss of RF channel operation is detected up to the moment the RF channel operation is fully restored.

Media Access Control (MAC) address The “built-in” hardware address of a device connected to a sharedmedium.

Media Access Control (MAC) procedure In a subnetwork, that part of the protocol that governs access to thetransmission medium independent of the physical characteristics of the medium, but taking into account thetopological aspects of the subnetworks, in order to enable the exchange of data between nodes. MAC proceduresinclude framing, error protection, and acquiring the right to use the underlying transmission medium.

Media Access Control (MAC) sublayer The part of the data link layer that supports topology-dependentfunctions and uses the services of the Physical Layer to provide services to the logical link control (LLC)sublayer.

Micro-reflections Echoes in the forward transmission path due to departures from ideal amplitude and phasecharacteristics.

Mid Split A frequency division scheme that allows bi-directional traffic on a single coaxial cable. Reversechannel signals propagate to the head-end from 5 to 108 MHz. Forward path signals go from the head-end from162 MHz to the upper frequency limit. The diplex crossover band is located from 108 to 162 MHz.

Mini-Slot A “mini-slot” is an integer multiple of 6.25-microsecond increments. The relationship betweenmini-slots, bytes and time ticks is described in Section 9.3.4.

16


Modulation Rate The signaling rate of the upstream modulator (1280 to 5120 kHz). In S-CDMA, the chiprate. In TDMA, the channel symbol rate.

Moving Picture Experts Group (MPEG) A voluntary body which develops standards for digital compressedmoving pictures and associated audio.

MPEG See Moving Picture Experts Group.

MSAP See MAC Service Access Point.

Multipoint Access User access in which more than one terminal equipment is supported by a single networktermination.

Multipoint Connection A connection among more than two data network terminations.

National Cable Television Association (NCTA) A voluntary association of cable television operators which,among other things, provides guidance on measurements and objectives for cable television systems in the USA.

National Television Systems Committee (NTSC) Committee which defined the analog color televisionbroadcast standard used today in North America.

Network Layer Layer 3 in the Open Systems Interconnection (OSI) architecture; the layer that providesservices to establish a path between open systems.

Network Management The functions related to the management of data link layer and physical layerresources and their stations across the data network supported by the hybrid fiber/coax system.

Number Of Allocated Codes The total number of codes which a single CM uses in a single S-CDMA frame.This number is determined by the size of the grants in minislots and the mapping of these minislots to S-CDMAframes (note that a CM may receive multiple grants which are mapped to a single S-CDMA frame). The numberof allocated codes can be in the range of the number of Codes per Mini-slot to the number of active codes, andmay vary from frame to frame, but is constant within an S-CDMA frame.

Open Systems Interconnection (OSI) A framework of ISO standards for communication between differentsystems made by different vendors, in which the communications process is organized into seven differentcategories that are placed in a layered sequence based on their relationship to the user. Each layer uses the layerimmediately below it and provides a service to the layer above. Layers 7 through 4 deal with end-to-endcommunication between the message source and destination, and layers 3 through 1 deal with network functions.

Organizationally Unique Identifier (OUI) A 3-octet IEEE assigned identifier that can be used to generateUniversal LAN MAC addresses and Protocol Identifiers per ANSI/IEEE Std 802 for use in Local andMetropolitan Area Network applications.

OSI See Open Systems Interconnection.

OUI See Organization Unique Identifier.

Packet Identifier (PID) A unique integer value used to identify elementary streams of a program in a single-or multi-program MPEG-2 stream.

Partial Grant A grant that is smaller than the corresponding bandwidth request from the CM.

Payload Header Suppression The suppression of the header in a payload packet. (e.g., the suppression of theEthernet header in forwarded packets)

17


Payload Unit Start Indicator (PUSI) A flag in an MPEG header. A value of 1 indicates the presence of apointer field as the first byte of the payload.

PHS See Payload Header Suppression.

PHY See Physical (PHY) Layer.

Physical (PHY) Layer Layer 1 in the Open System Interconnection (OSI) architecture; the layer that providesservices to transmit bits or groups of bits over a transmission link between open systems and which entailselectrical, mechanical and handshaking procedures.

Physical Media Dependent (PMD) Sublayer A sublayer of the Physical Layer which is concerned withtransmitting bits or groups of bits over particular types of transmission link between open systems and whichentails electrical, mechanical and handshaking procedures.

PID See Packet Identifier.

PMD See Physical Media Dependent (PMD) Sublayer.

Primary Service Flow All CMs have a Primary Upstream Service Flow and a Primary Downstream ServiceFlow. They ensure that the CM is always manageable and they provide a default path for forwarded packets thatare not classified to any other Service Flow

Program-Specific Information (PSI) In MPEG-2, normative data necessary for the demultiplexing ofTransport Streams and the successful regeneration of programs.

Program Stream In MPEG-2, a multiplex of variable-length digital video and audio packets from one or moreprogram sources having a common time-base.

Protocol A set of rules and formats that determines the communication behavior of layer entities in theperformance of the layer functions.

Provisioned Service Flow A Service Flow that has been provisioned as part of the Registration process, buthas not yet been activated or admitted. It may still require an authorization exchange with a policy module orexternal policy server prior to admission.

PSI See Program-Specific Information.

QAM See Quadrature Amplitude Modulation.

QoS Parameter Set The set of Service Flow Encodings that describe the Quality of Service attributes of aService Flow or a Service Class. (Refer to Section C.2.2.5)

QPSK See Quadrature Phase-Shift Keying.

Quadrature Amplitude Modulation (QAM) A method of modulating digital signals onto a radio-frequencycarrier signal involving both amplitude and phase coding.

Quadrature Phase-Shift Keying (QPSK) A method of modulating digital signals onto a radio-frequencycarrier signal using four phase states to code two digital bits.

Radio Frequency (RF) In cable television systems, this refers to electromagnetic signals in the range 5 to1000 MHz.

18


Reference Code Matrix A 128-by-128 element matrix formed by stacking successive spreading codes on topof each other, i.e., the bottom row of the reference code matrix is Code 0 (all ones) and the top row is Code 127.The code elements are placed in the matrix from right to left, i.e., the right-most column of the code matrix is thefirst element of each code, and the left-most column is the last element of each code.

Request For Comments (RFC) A technical policy document of the IETF; these documents can be accessedon the World Wide Web at http://www.rfc-editor.org/.

Return Loss The parameter describing the attenuation of a guided wave signal (e.g., via a coaxial cable)returned to a source by a device or medium resulting from reflections of the signal generated by the source.

Reverse Channel The direction of signal flow towards the head-end, away from the subscriber; equivalent toUpstream.

RFC See Request for Comments.

Routing Information Protocol (RIP) A protocol of the IETF for exchanging routing information about IPnetworks and subnets.

SAID See Security Association Identifier.

S-CDMA Frame A two dimensional representation of mini-slots, where the dimensions are codes and time.An S-CDMA frame is composed of p active codes in the code dimension and K spreading intervals in the timedimension. Within the S-CDMA frame, the number of mini-slots is determined by the number of codes per mini-slot (c) and p, the number of active codes in the S-CDMA frame. Each S-CDMA frame thus contains s mini-slots, where s=p/c, and each mini-slot contains c*K information (QAM) symbols.

S-CDMA Subframe A subframe is a vertically-smaller subset of an S-CDMA frame over which interleavingis performed, where the vertical dimension is R' codes, where R' ≤ p (the number of active codes). A subframe isgenerally used to constrain the interleaving region to be of a similar size to the Reed-Solomon codeword in orderto provide protection from impulse noise.

Security Association Identifier A Baseline Privacy security identifier between a CMTS and a CM.

Service Access Point (SAP) The point at which services are provided by one layer, or sublayer to the layerimmediately above it.

Service Class A set of queuing and scheduling attributes that is named and that is configured at the CMTS. AService Class is identified by a Service Class Name. A Service Class has an associated QoS Parameter Set.

Service Class Name An ASCII string by which a Service Class may be referenced in modem configurationfiles and protocol exchanges.

Service Data Unit (SDU) Information that is delivered as a unit between peer service access points

Service Flow A MAC-layer transport service which:

• Provides unidirectional transport of packets from the upper layer service entity to the RF;

• Shapes, polices, and prioritizes traffic according to QoS traffic parameters defined for the Flow.

Service Flow Identifier (SFID) An identifier assigned to a service flow by the CMTS. [32 bits]

19


Service Flow Reference A message parameter in Configuration Files and Dynamic Service MAC messagesused to associate Classifiers and other objects in the message with the Service Flow Encodings of a requestedService Flow.

Service Identifier (SID) A Service Flow Identifier assigned by the CMTS (in addition to a Service FlowIdentifier) to an Active or Admitted Upstream Service Flow. [14 bits]

SID See Service Identifier.

Simple Network Management Protocol (SNMP) A network management protocol of the IETF.

SMS See Spectrum Management System.

SNAP See Subnetwork Access Protocol.

SNMP See Simple Network Management Protocol.

Spectrum Management System (SMS) A system, defined in [SMS], for managing the RF cable spectrum.

Spread Symbol Or Spreading Interval At the output of the spreader, a group of 128 chips which comprise asingle S-CDMA spreading code, and are the result of spreading a single information (QAM) symbol. One spreadsymbol = one spreading interval = 128 chips = one information (QAM) symbol.

Spreader-Off S-CDMA Burst A transmission from a single CM in a spreader-off frame on an S-CDMAchannel defined by the time in which the CM’s transmitter turns on to the time it turns off. There will generallybe several spreader off bursts in a spreader-off frame.

Spreader-Off S-CDMA Frame TDMA mini-slots on an S-CDMA channel in which the spreader is turnedoff. These are differentiated from TDMA bursts on a TDMA channel in that, for example, the number of mini-slots per spreader-off SCDMA burst frame is constrained to be the same as the number of mini-slots in aspreader-on SCDMA frame (s). This number of mini-slots will be less than the number of TDMA mini-slots in aTDMA channel over the same time interval if the number of active codes is significantly less than 128.

Spreading Interval Time to transmit a single complete S-CDMA spreading code, equal to the time to transmit128 chips. Also, time to transmit a single information (QAM) symbol on an S-CDMA channel. See also SpreadSymbol.

Sub-Channel A logical channel sharing same upstream spectrum (RF center frequency and RF channel) withother logical channels.

Sublayer A subdivision of a layer in the Open System Interconnection (OSI) reference model.

Subnetwork Subnetworks are physically formed by connecting adjacent nodes with transmission links.

Subnetwork Access Protocol (SNAP) An extension of the LLC header to accommodate the use of 802-typenetworks as IP networks.

Subscriber See End User.

Subsplit A frequency-division scheme that allows bi-directional traffic on a single cable. Reverse path signalscome to the head-end from 5 to 30 (up to 42 on Extended Subsplit systems) MHz. Forward path signals go fromthe head-end from 50 or 54 MHz to the upper frequency limit of the cable network.

20


Subsystem An element in a hierarchical division of an Open System that interacts directly with elements in thenext higher division or the next lower division of that open system.

System Clock Period The period of the 10.24 MHz system clock, nominally 97.65625 ns.

Systems Management Functions in the application layer related to the management of various open systemsInterconnection (OSI) resources and their status across all layers of the OSI architecture.

TFTP See Trivial File-Transfer Protocol.

Tick 6.25-microsecond time intervals that are the reference for upstream mini-slot definition and upstreamtransmission times.

Tilt Maximum difference in transmission gain of a cable television system over a given bandwidth (typicallythe entire forward operating frequency range).

TLV See Type/Length/Value.

Transit Delay The time difference between the instant at which the first bit of a PDU crosses one designatedboundary, and the instant at which the last bit of the same PDU crosses a second designated boundary.

Transmission Control Protocol (TCP) A transport-layer Internet protocol which ensures successful end-to-end delivery of data packets without error.

Transmission Convergence Sublayer A sublayer of the Physical Layer that provides an interface between theData Link Layer and the PMD Sublayer.

Transmission Link The physical unit of a subnetwork that provides the transmission connection betweenadjacent nodes.

Transmission Medium The material on which information signals may be carried; e.g., optical fiber, coaxialcable, and twisted-wire pairs.

Transmission System The interface and transmission medium through which peer physical layer entitiestransfer bits.

Transmit On/Off Ratio In multiple-access systems, the ratio between the signal powers sent to line whentransmitting and when not transmitting.

Transport Stream In MPEG-2, a packet-based method of multiplexing one or more digital video and audiostreams having one or more independent time bases into a single stream.

Trivial File-Transfer Protocol (TFTP) An Internet protocol for transferring files without the requirement foruser names and passwords that is typically used for automatic downloads of data and software.

Trunk Cable Cables that carry the signal from the head-end to groups of subscribers. The cables can be eithercoaxial or fiber depending on the design of the system.

Type/Length/Value (TLV) An encoding of three fields, in which the first field indicates the type of element,the second the length of the element, and the third field the value.

21


UCC Upstream Channel Change

Upstream The direction from the subscriber location toward the head-end.

Upstream Channel Descriptor (UCD) The MAC Management Message used to communicate thecharacteristics of the upstream physical layer to the cable modems.

22


4 Functional Assumptions

This section describes the characteristics of cable television plant to be assumed for the purpose of operating adata-over-cable system. It is not a description of CMTS or CM parameters. The data-over-cable system MUSTbe interoperable within the environment described in this section.

This section applies to the first technology option referred to in Section 1 (1.1 Scope). For the second option,refer to Annex European Specification AdditionsF.

Whenever any reference in this section to frequency plans or compatibility with other services conflicts with anylegal requirement for the area of operation, the latter shall take precedence. Any reference to NTSC analoguesignals in 6 MHz channels does not imply that such signals are physically present.

4.1 Broadband Access Network

A coaxial-based broadband access network is assumed. This may take the form of either an all-coax or hybrid-fiber/coax (HFC) network. The generic term “cable network” is used here to cover all cases.

A cable network uses a shared-medium, tree-and-branch architecture with analog transmission. The keyfunctional characteristics assumed in this document are the following:

• Two-way transmission.

• A maximum optical/electrical spacing between the CMTS and the most distant CM of 100 miles in eachdirection, although typical maximum separation may be 10-15 miles.

• A maximum differential optical/electrical spacing between the CMTS and the closest and most distantmodems of 100 miles in each direction, although this would typically be limited to 15 miles.1

At a propagation velocity in fiber of approximately 1.5 ns/ft, 100 miles of fiber in each direction results in around-trip delay of approximately 1.6 ms. For further information, Appendix Ambient Temperature and WindLoading EffectsVIII,“Ambient Temperature and Wind Loading Effects” on page 4752

4.2 Equipment Assumptions

4.2.1 Frequency Plan

In the downstream direction, the cable system is assumed to have a passband with a lower edge between 50 and54 MHz and an upper edge that is implementation-dependent but is typically in the range of 300 to 864 MHz.Within that passband, NTSC analog television signals in 6-MHz channels are assumed to be present on thestandard, HRC or IRC frequency plans of [EIA-S542], as well as other narrowband and wideband digital signals.

In the upstream direction, the cable system may have a subsplit (5-30 MHz) or extended subsplit (5-40 or 5-42MHz) passband. NTSC analog television signals in 6-MHz channels may be present, as well as other signals.

1. Phrase “in each direction” added to second and third bulleted items per RFI2-N-02104 by RKV on 10/28/02.2. Section 4.1, last paragraph added per RFI2-N-02104 by RKV on 10/28/02.

23


4.2.2 Compatibility with Other Services

The CM and CMTS MUST coexist with the other services on the cable network. In particular,

a) They MUST be interoperable in the cable spectrum assigned for CMTS-CM interoperation while thebalance of the cable spectrum is occupied by any combination of television and other signals; and

b) They MUST NOT cause harmful interference to any other services that are assigned to the cable network inspectrum outside of that allocated to the CMTS.

The latter is understood as

• No measurable degradation (highest level of compatibility),

• No degradation below the perceptible level of impairments for all services (standard or medium level of com-patibility), or

• No degradation below the minimal standards accepted by the industry (for example, FCC for analog videoservices) or other service provider (minimal level of compatibility).

4.2.3 Fault Isolation Impact on Other Users

As the data-over-cable system is a shared-media, point-to-multipoint system, fault-isolation procedures shouldtake into account the potential harmful impact of faults and fault-isolation procedures on numerous users of thedata-over-cable and other services.

For the interpretation of harmful impact, see Section 4.2.2 above.

4.2.4 Cable System Terminal Devices

The CM MUST meet and SHOULD exceed all applicable regulations for Cable System Termination Devices andCable Ready Consumer Equipment as defined in FCC Part 15 [FCC15] and Part 76 [FCC76]. None of thesespecific requirements may be used to relax any of the specifications contained elsewhere within this document.

4.3 RF Channel Assumptions

The data-over-cable system, configured with at least one set of defined physical-layer parameters(e.g., modulation, forward error correction, modulation rate, etc.) from the range of configuration settingsdescribed in this specification, MUST be interoperable on cable networks having characteristics defined in thissection in such a manner that the forward error correction provides for equivalent operation in a cable systemboth with and without the impaired channel characteristics described below.

4.3.1 Transmission Downstream

The RF channel transmission characteristics of the cable network in the downstream direction are described inTable 4-1. These numbers assume total average power of a digital signal in a 6-MHz channel bandwidth forcarrier levels unless indicated otherwise. For impairment levels, the numbers in Table 4-1 assume average powerin a bandwidth in which the impairment levels are measured in a standard manner for cable TV system. Foranalog signal levels, the numbers in Table 4-1 assume peak envelope power in a 6-MHz channel bandwidth. Allconditions are present concurrently. No combination of the following parameters will exceed any stated interfacelimit defined elsewhere in this specification.

24


Table 4-1 Assumed Downstream RF Channel Transmission Characteristics (see note 1)

Notes to Table 4-1:

1. Transmission is from the head-end combiner to the CM input at the customer location.

2. Measurement methods defined in [NCTA] or [CableLabs1].

3. Measured relative to a QAM signal that is equal to the nominal video level in the plant.

4.3.2 Transmission Upstream

The RF channel transmission characteristics of the cable network in the upstream direction are described inTable 4-2. All conditions are present concurrently. No combination of the following parameters will exceed anystated interface limit defined elsewhere in this specification.

Parameter Value

Frequency range Cable system normal downstream operating range isfrom 50 MHz to as high as 860 MHz. However, thevalues in this table apply only at frequencies >= 88 MHz.

RF channel spacing (design bandwidth) 6 MHz

Transit delay from head-end to most distant customer <= 0.800 msec (typically much less)

Carrier-to-noise ratio in a 6-MHz band Not less than 35 dB (see note 2,3)

Carrier-to-Composite triple beat distortion ratio Not less than 41 dB (see note 2,3)

Carrier-to-Composite second order distortion ratio Not less than 41 dB (see note 2,3)

Carrier-to-Cross-modulation ratio Not less than 41 dB (see note 2,3)

Carrier-to-any other discrete interference (ingress) Not less than 41 dB (see note 2,3)

Amplitude ripple 3 dB within the design bandwidth (see note 2)

Group delay ripple in the spectrum occupied by the CMTS 75 ns within the design bandwidth (see note 2)

Micro-reflections bound for dominant echo -20 dBc @ <= 1.5 µsec, -30 dBc @ > 1.5 µsec-10 dBc @ <= 0.5 µsec, -15 dBc @ <= 1.0 µsec (seenote 2)

Carrier hum modulation Not greater than -26 dBc (5%) (see note 2)

Burst noise Not longer than 25 µsec at a 10 Hz average rate (seenote 2)

Maximum analog video carrier level at the CM input 17 dBmV

Maximum number of analog carriers 121

25


Table 4-2 Assumed Upstream RF Channel Transmission Characteristics (see note 1)

Notes to Table 4-2:

1. Transmission is from the CM output at the customer location to the head-end.

2. Ingress avoidance or tolerance techniques may be used to ensure operation in the presence of time-varying discreteingress signals that could be as high as 10 dBc. The ratios are guaranteed only within the digital carrier channels.

3. Amplitude and frequency characteristics sufficiently strong to partially or wholly mask the data carrier.

4. Impulse noise levels more prevalent at lower frequencies (< 15 MHz).

4.3.2.1 Availability

Typical cable network availability is considerably greater than 99%.

4.4 Transmission Levels

The nominal power level of the downstream CMTS signal(s) within a 6-MHz channel is targeted to be in therange -10 dBc to -6 dBc relative to analog video carrier level and will normally not exceed analog video carrierlevel. The nominal power level of the upstream CM signal(s) will be as low as possible to achieve the requiredmargin above noise and interference. Uniform power loading per unit bandwidth is commonly followed insetting upstream signal levels, with specific levels established by the cable network operator to achieve therequired carrier-to-noise and carrier-to-interference ratios.

4.5 Frequency Inversion

There will be no frequency inversion in the transmission path in either the downstream or upstream directions,i.e., a positive change in frequency at the input to the cable network will result in a positive change in frequencyat the output.

Parameter Value

Frequency range 5 to 42 MHz edge to edge

Transit delay from the most distant CM to the nearest CMor CMTS

<= 0.800 msec (typically much less)

Carrier-to-interference plus ingress (the sum of noise,distortion, common-path distortion and cross-modulationand the sum of discrete and broadband ingress signals,impulse noise excluded) ratio

Not less than 25 dB (Note 2)

Carrier hum modulation Not greater than -23 dBc (7.0%)

Burst noise Not longer than 10 µsec at a 1 kHz averagerate for most cases (Notes 3 and 4)

Amplitude ripple 5-42 MHz: 0.5 dB/MHz

Group delay ripple 5-42 MHz: 200 ns/MHz

Micro-reflections – single echo -10 dBc @ <= 0.5 µsec-20 dBc @ <= 1.0 µsec-30 dBc @ > 1.0 µsec

Seasonal and diurnal reverse gain (loss) variation Not greater than 14 dB min to max

26


5 Communication Protocols

This section provides a high-level overview of the communication protocols that must be used in the data-over-cable system. Detailed specifications for the physical media dependent, downstream transmission, and mediaaccess control sublayers are provided in Section 6, Section 7, and Section 8, respectively.

5.1 Protocol Stack

The CM and CMTS operate as forwarding agents and also as end-systems (hosts). The protocol stacks used inthese modes differ as shown below.

The principal function of the cable modem system is to transmit Internet Protocol (IP) packets transparentlybetween the head-end and the subscriber location. Certain management functions also ride on IP, so that theprotocol stack on the cable network is as shown in Figure 5-1 (this does not restrict the generality of IPtransparency between the head-end and the customer). These management functions include, for example,supporting spectrum management functions and the downloading of software.

5.1.1 CM and CMTS as Hosts

CMs and CMTSes operate as IP and LLC hosts in terms of IEEE Standard 802 [IEEE802] for communicationover the cable network. The protocol stack at the CM and CMTS RF interfaces is shown in Figure 5-1.

Figure 5-1 Protocol Stack on the RF Interface

PMD

TransmissionConvergence

(Downstream Only)

MAC

LinkSecurity

LLC/DIX

IP, ICMP

UDP

SNMP TFTP DHCP

ARP

27


The CM and CMTS MUST function as IP hosts. As such, the CM and CMTS MUST support IP and ARP overDIX link-layer framing (see [DIX]). The CMTS MUST NOT transmit frames that are smaller than the DIX 64byte minimum on a downstream channel.1 However, the CM MAY transmit frames that are smaller than the DIX64 byte minimum on an upstream channel.

The CM and CMTS MAY also support IP and ARP over SNAP framing [RFC-1042].

The CM and CMTS also MUST function as LLC hosts. As such, the CM and CMTS MUST respondappropriately to TEST and XID requests per [ISO8802-2].

5.1.2 Data Forwarding Through the CM and CMTS

5.1.2.1 General

Data forwarding through the CMTS MAY be transparent bridging,2 or MAY employ network-layer forwarding(routing, IP switching) as shown in Figure 5-2.

Data forwarding through the CM is link-layer transparent bridging, as shown in Figure 5-2. Forwarding rules aresimilar to [ISO/IEC10038] with the modifications described in Section 5.1.2.2 and Section 5.1.2.3. This allowsthe support of multiple network layers.

Figure 5-2 Data Forwarding Through the CM and CMTS

Forwarding of IP traffic MUST be supported. Other network layer protocols MAY be supported. The ability torestrict the network layer to a single protocol such as IP MUST be supported.

The 802.1d spanning tree protocol of [ISO/IEC10038] with the modifications described in Annex E MAY besupported by CMs intended for residential use. CMs intended for commercial use MUST support this version ofspanning tree. CMs and CMTSes MUST include the ability to filter (and disregard) 802.1d BPDUs.

1. Except as a result of Payload Header Suppression. Refer to Section 10.4.2. With the exception that for packet PDUs less than 64 bytes to be forwarded from the upstream RFI, a CMTS

MUST pad out the packet PDU and recompute the CRC.

IP

802.2/DIX LLCForwarding

CMTS Stack CM Stack

802.2/DIX LLC

Cable MAC

Cable NetworkTransmission

Link Security

CMTS-NSIInterfaceto/fromNetwork

Equipment

CMCI Interfaceto/from

CustomerPremises

Equipment

TransparentBridging

802.3/DIXMAC

802.310Base-T

802.2/DIXLLC

Cable MAC

CablePMD

Link Security

PHY Layer

DS TCLayer

DS TCLayer

DataLink

Layer

IP

CablePMD

UpstrmCablePMD

UpstrmCablePMD

28


This specification assumes that CMs intended for residential use will not be connected in a configuration whichwould create network loops such as that shown in Figure 5-3.

Figure 5-3 Example Condition for Network Loops

Although provisions exist in this specification for frames to be passed from a higher-layer entity to be forwardedby the cable modem, these frames MUST be treated identically to frames arriving at the CPE port. In particular,all of the forwarding rules defined in Section 5.1.2.3 MUST apply to these frames.1

5.1.2.2 CMTS Forwarding Rules

At the CMTS, if link-layer forwarding is used, then it MUST conform to the following general 802.1dguidelines:

• Link-layer frames MUST NOT be duplicated.

• Stale frames (those that cannot be delivered in a timely fashion) MUST be discarded.

• Link-layer frames, on a given Service Flow (refer to Section 8.1.2.3), MUST be delivered in the order theyare received.

The address-learning and -aging mechanisms used are vendor-dependent.

If network-layer forwarding is used, then the CMTS should conform to IETF Router Requirements [RFC-1812]with respect to its CMTS-RFI and CMTS-NSI interfaces.

Conceptually, the CMTS forwards data packets at two abstract interfaces: between the CMTS-RFI and theCMTS-NSI, and between the upstream and downstream channels. The CMTS MAY use any combination oflink-layer (bridging) and network-layer (routing) semantics at each of these interfaces. The methods used at thetwo interfaces need not be the same.

Forwarding between the upstream and downstream channels within a MAC layer differs from traditional LANforwarding in that:

• A single channel is simplex, and cannot be considered a complete interface for most protocol (e.g., 802.1dspanning tree, Routing Information Protocol per [RFC-1058]) purposes.

• Upstream channels are essentially point-to-point, whereas downstream channels are shared-media.

• Policy decisions may override full connectivity.

1. Section 5.1.2.1, last paragraph added per RFI2-N-02171 by RKV on 10/29/02.

CMTS

CM #1 CM #2

CPE

LocalISO8802Network

Cable Network

29


For these reasons, an abstract entity called the MAC Forwarder exists within the CMTS to provide connectivitybetween stations within a MAC domain (see Section 5.2).

5.1.2.3 CM Forwarding Rules

Data forwarding through the CM is link-layer bridging with the following specific rules.

5.1.2.3.1 CPE MAC Address Acquisition

• The CM MUST acquire Ethernet MAC addresses of connected CPE devices, either from the provisioningprocess or from learning, until the CM acquires its maximum number of CPE MAC addresses (a device-dependent value). Once the CM acquires its maximum number of CPE MAC addresses, then newly discov-ered CPE MAC addresses MUST NOT replace previously acquired addresses. The CM must support acquisi-tion of at least one CPE MAC address.

• The CM MUST allow configuration of CPE addresses during the provisioning process (up to its maximumnumber of CPE addresses) to support configurations in which learning is not practical nor desired.

• Addresses provided during the CM provisioning MUST take precedence over learned addresses.

• CPE addresses MUST NOT be aged out.

• In order to allow modification of user MAC addresses or movement of the CM, addresses are not retained innon-volatile storage. On a CM reset (e.g., power cycle), all provisioned and learned addresses MUST be dis-carded.

5.1.2.3.2 Forwarding

CM forwarding in both directions MUST conform to the following general 802.1d guidelines:

• Link-layer frames MUST NOT be duplicated.

• Stale frames (those that cannot be delivered in a timely fashion) MUST be discarded.

• Link-layer frames MUST be delivered in the order that they are received on a given Service Flow (refer toSection 8.1.2.3). In the upstream direction, the CM may perform one or more frame/packet processingfunctions on frames received from the CMCI prior to classifying them to a Service Flow. In the downstreamdirection, the CM may perform one or more frame/packet processing functions on frames received from theHFC prior to transmitting them on the CMCI. Example processing functions include: DOCSIS protocolfiltering as specified in [DOCSIS5] section 7.3, a policy-based filtering service as described in Section10.1.6.1 and Appendix I, and priority-based queuing to support 802.1P/Q services.1

Cable-Network-to-CMCI forwarding MUST follow the following specific rules:

• Frames addressed to unknown destinations MUST NOT be forwarded from the cable port to the CPE ports.

• Broadcast frames MUST be forwarded to the CPE ports, unless they are from source addresses which areprovisioned or learned as supported CPE devices, in which case they MUST NOT be forwarded.

• The forwarding of multicast is controlled by administratively set parameters for the policy-filter service andby a specific multicast tracking algorithm (refer to Section 5.3.1). Multicast frames MUST NOT beforwarded unless both mechanisms are in a permissive state.

1. This bulleted item updated per RFI2-N-02161 by RKV on 10/29/02.

30


CMCI-to-Cable-Network forwarding MUST follow the following specific rules:

• Frames addressed to unknown destinations MUST be forwarded from all CPE ports to the cable port.

• Broadcast frames MUST be forwarded to the cable port.

• Multicast frames MUST be forwarded to the cable port in accordance with filtering configuration settingsspecified by the cable operator’s operations and business support systems.

• Frames from source addresses other than those provisioned or learned as supported CPE devices MUST NOTbe forwarded.

• Other (non-supported) CPE source addresses MUST be learned from all CPE ports and this information usedto filter local traffic as in a traditional learning bridge.

• Frames addressed to destination addresses that are learned from all CPE ports MUST be filtered as localtraffic.1

5.2 The MAC Forwarder

The MAC Forwarder is a MAC sublayer that resides on the CMTS just below the MAC service access point(MSAP) interface, as shown in Figure 5-4. It is responsible for delivering upstream frames to

• One or more downstream channels

• The MSAP interface

In Figure 5-4, the LLC sublayer and link security sublayers of the upstream and downstream channels on thecable network terminate at the MAC Forwarder.

The MSAP interface user may be the NSI-RFI Forwarding process or the CMTS’s host protocol stack.

Figure 5-4 MAC Forwarder

Delivery of frames may be based on data-link-layer (bridging) semantics, network-layer (routing) semantics, orsome combination. Higher-layer semantics may also be employed (e.g., filters on UDP port numbers). TheCMTS MUST provide IP connectivity between hosts attached to cable modems, and must do so in a way thatmeets the expectations of Ethernet-attached customer equipment. For example, the CMTS must either forward

1. Section 5.1.2.3.2 updated per RFI2-N-02171 by RKV on 10/29/02.

MAC Forwarder

Host IP Stack,incl. LLC

and 802.2/DIX

MAC ServiceAccess Point

(MSAP) Interface

CMTS-NSI

Upstream andDownstream Channels

RFI-NSI ForwardingProcess

CMTS

Link SecurityMAC

31


ARP packets or it must facilitate a proxy ARP service. The CMTS MAC Forwarder MAY provide service fornon-IP protocols.

Note that there is no requirement that all upstream and downstream channels be aggregated under one MSAP asshown above. The vendor could just as well choose to implement multiple MSAPs, each with a single upstreamand downstream channel.

5.2.1 Rules for Data-Link-Layer Forwarding

The requirements in this section apply if the MAC Forwarder is implemented using only data-link-layersemantics.

Delivery of frames is dependent on the Destination Address within the frame. The means of learning the locationof each address is vendor-dependent, and MAY include:

• Transparent-bridging-like source-address learning and aging

• Gleaning from MAC Registration Request messages

• Administrative means

If the destination address of a frame is unicast, and that address is associated with a particular downstreamchannel, then the frame MUST be forwarded to that channel.1

If the destination address of a frame is unicast, and that address is known to reside on the other (upper) side of theMSAP interface, then the frame MUST be delivered to the MSAP interface.

If the destination address is broadcast, multicast,2 or unknown, the frame MUST be delivered to both the MSAPand to all downstream channels (with the exception of the 5.3.1.2 multicast forwarding rules).

Delivery rules are similar to those for transparent bridging:

• Frames MUST NOT be duplicated.

• Frames that cannot be delivered in a timely fashion MUST be discarded.

• The Frame Check Sequence SHOULD be preserved rather than regenerated.

• Frames, on a given Service Flow (refer to Section 8.1.2.3), MUST be delivered in the order they are received.

5.3 Network Layer

As stated above, the purpose of the data-over-cable system is to transport IP traffic transparently through thesystem.

The Network Layer protocol is the Internet Protocol (IP) version 4, as defined in [RFC-791], and migrating to IPversion 6.

This document imposes no requirements for reassembly of IP packets.

1. Vendors may implement extensions, similar to static addresses in 802.1d/ISO 10038 bridging, that causesuch frames to be filtered or handled in some other manner.

2. All multicasts, including 802.1d/ISO 10038 Spanning Tree Bridge BPDUs, MUST be forwarded.

32


5.3.1 Requirements for IGMP Management

There are two basic modes of IGMP capability that are applicable to a DOCSIS 2.0 device (CMTS and CM). Thefirst mode is a passive operation in which the device selectively forwards IGMP based upon the known state ofmulticast session activity on the subscriber side (an example of this is described in Appendix V). In passivemode, the device derives its IGMP timers based on the rules specified in section 3.3.1.1 of [DOCSIS11]. Thesecond mode is an active operation in which the device terminates and initiates IGMP based upon the knownstate of multicast session activity on the subscriber side. One example of the latter, active, mode is commonlyreferred to as an IGMP-Proxy implementation side (as described in [ID-IGMP]). A more complete example of anactive IGMP device is that of a Multicast Router.

Active and Passive IGMP devices MUST support IGMPv2 [RFC-2236].

5.3.1.1 IGMP Timer Requirements

The following IGMP timer requirements apply only when the device (CMTS / CM) is operating in passive IGMPmode:

• The device MUST NOT require any specific configuration for the associated multicast timer values andMUST be capable of adhering to the timers specified in this section.

• The device MAY provide configuration control that overrides the default values of these timers.

• The device MUST derive the Membership Query Interval by looking at the inter-arrival times of the Member-ship Query messages. Formally: If n < 2, MQI = 125 else MQI = MAX (125, MQn- MQn-1), where MQI isthe Membership Query Interval in seconds, n is the number of Membership Queries seen, and MQn is theepoch time at which the nth Membership Query was seen to the nearest second.

• The Query Response Interval is carried in the Membership Query packet. The Query Response IntervalMUST be assumed to be 10 seconds if not otherwise set (or set to 0) in the Membership Query packet.

5.3.1.2 CMTS Rules

• If link-layer forwarding of multicast packets is used, the CMTS MUST forward all Membership Queries onall downstream channels using the appropriate 802.3 multicast group (e.g., 01:00:5E:xx:xx:xx wherexx:xx:xx are the low order 23 bits of the multicast address expressed in hex notation. Refer to [IMA].).

• The CMTS MUST forward the first copy of Solicited and Unsolicited Membership Reports for any givengroup received on its upstream RF interface to all of its downstream RF interfaces. However, if membershipis managed on a per downstream RF interface basis, Membership Reports and IGMP v2 Leave messagesMAY be forwarded only on the downstream interface to which the reporting CPE’s CM is connected.

• The CMTS SHOULD suppress the transmission of additional Membership Reports (for any given group)downstream for at least the Query Response Interval. If the CMTS uses data-link-layer forwarding, it MUSTalso forward the Membership Report out all appropriate Network Side Interfaces.

• The CMTS SHOULD suppress the downstream transmission of traffic to any IP multicast group that does nothave subscribers on that downstream RF interface (subject to any administrative controls).

• If the CMTS performs network-layer forwarding of multicast packets, it MUST support Active IGMP mode.

• If link-layer forwarding of multicast packets is used, the CMTS SHOULD support Passive IGMP mode andMAY support Active IGMP mode.

33


5.3.1.3 CM Rules

The CM MUST support IGMP with the cable-specific rules specified in this section.

The CM MUST implement the passive IGMP mode. Additionally, the CM MAY implement the active IGMPmode. If it implements the active IGMP mode, the CM MUST support a capability to switch between modes.

5.3.1.3.1 Multicast Forwarding Requirements

The following requirements apply to both passive and active modes of IGMP operations:

• The CM MUST NOT forward Membership Queries from its CPE interface to its RF interface.

• The CM MUST NOT forward Membership Reports or IGMP v2 Leaves received on its RF interface to itsCPE interface.

• The CM MUST NOT forward multicast traffic from its RF interface to its CPE interface unless a device on itsCPE interface is a member of that IP multicast group.

• The CM MUST forward multicast traffic from its CPE interface to its RF interface unless administratively(via configuration or other mechanism) prohibited.

• As a result of receiving a Membership Report on its CPE interface, the CM MUST begin forwarding trafficfor the appropriate IP multicast group. The CM MUST stop forwarding multicast traffic from the RF to theCPE side whenever the CM has not received a Membership Report from the CPE side for more than theMembership Interval, which is (2 * MQI) + QRI, where MQI is the Membership Query Interval and QRI isthe Query Response Interval.

• The CM MAY stop forwarding traffic from the RF to the CPE side for a particular multicast group prior to theexpiration of the Membership Interval (see above) if it can determine (for example, via an IGMP LEAVEmessage and the appropriate protocol exchange) that there are no CPE devices subscribed to that particulargroup.

The following requirements apply only when the CM is operating in passive IGMP mode:

• The CM MUST forward traffic for the ALL-HOSTS multicast group from its RF interface to its CPE inter-face unless administratively prohibited. The CPE MUST always be considered a member of this group. Inparticular, the CM MUST forward ALL-HOSTS Group Queries that pass permit filters on its RF interface toits CPE interface.

• Upon receiving a Membership Report on its CPE interface, the CM MUST start a random timer between 0and 3 seconds. During this time period, the CM MUST discard any additional Membership Reports receivedin its CPE interface for the associated multicast group. If the CM receives a Membership Report on its HFCinterface for the associated multicast group, the CM MUST discard the Membership Report received on itsCPE interface. If the random timer expires without the reception of a Membership Report on the CMs HFCinterface, the CM MUST transmit the Membership Report received on its CPE interface.

The following requirements apply only when the CM is operating in active IGMP mode:

• The CM MUST implement the Host portion of the IGMP v2 protocol [RFC-2236] on its RF interface forCPEs with active groups and MUST NOT act as a Querier on its RF interface.

• The CM MUST act as an IGMPv2 Querier on its CPE interface.

• If the CM has received a Membership Report on its downstream RF interface for groups active on the CMsCPE interface within the Query Response Interval, it MUST suppress transmission on its upstream RF inter-face of such Membership Reports.

34


• The CM MUST suppress all subsequent Membership Reports for this group until such time as the CMreceives a Membership Query (General or Specific to this Group) on its RF interface or a IGMPv2 Leave isreceived for this group from the CPE interface.

• The CM MUST treat Unsolicited Membership Reports (IGMP JOINs) from its CPE interface as a response toa Membership Query received on its RF interface. Upon receipt of this unsolicited JOIN from its CPE inter-face, the CM MUST start a random timer according to the Host State Diagram, specified in [RFC-2236], andMUST use a Query Response Interval of 3 seconds. As specified above, if the CM receives a MembershipReport on its RF interface for this group during this random time period, it MUST suppress transmission ofthis Join on its upstream RF interface.

Note: Nothing in this section would prohibit the CM from being specifically configured to not forward certain multicast traffic asa matter of network policy.

5.4 Above the Network Layer

The subscribers will be able to use the transparent IP capability as a bearer for higher-layer services. Use of theseservices will be transparent to the CM.

In addition to the transport of user data, there are several network management and operation capabilities whichdepend upon the Network Layer. These include:

• SNMP (Simple Network Management Protocol, [RFC-1157]), MUST be supported for network management.

• TFTP (Trivial File Transfer Protocol, [RFC-1350]), a file transfer protocol, MUST be supported for down-loading operational software and configuration information, as modified by TFTP Timeout Interval andTransfer Size Options [RFC-2349].

• DHCP (Dynamic Host Configuration Protocol, [RFC-2131]), a framework for passing configuration informa-tion to hosts on a TCP/IP network, MUST be supported.

• Time of Day Protocol, [RFC-868], MUST be supported to obtain the time of day.

DHCP, TFTP, and ToD client messages generated by the CM MUST only be sent via the RF Interface. DHCP,TFTP and ToD client messages include DHCPDISCOVER, DHCPREQUEST, DHCPDECLINE,DHCPRELEASE, DHCPINFORM, TFTP-RRQ, TFTP-ACK, and ToD request.

The CM’s DHCP, TFTP, and ToD client MUST ignore DHCP, TFTP, and ToD server messages received on theCMCI port. DHCP, TFTP, and ToD server messages include: DHCPOFFER, DHCPACK, DHCPNAK, TFTP-DATA, and ToD time message.

5.5 Data Link Layer

The Data Link Layer is divided into sublayers in accordance with [IEEE802], with the addition of Link-Layersecurity in accordance with [DOCSIS8]. The sublayers, from the top, are:

• Logical Link Control (LLC) sublayer (Class 1 only)

• Link-Layer Security sublayer

• Media Access Control (MAC) sublayer

5.5.1 LLC Sublayer

The LLC sublayer MUST be provided in accordance with [ISO/IEC10039]. Address resolution MUST be usedas defined in [RFC-826]. The MAC-to-LLC service definition is specified in [ISO/IEC10039].

35


5.5.2 Link-Layer Security Sublayer

Link-layer security MUST be provided in accordance with [DOCSIS8].

5.5.3 MAC Sublayer

The MAC sublayer defines a single transmitter for each downstream channel - the CMTS. All CMs listen to allframes transmitted on the downstream channel upon which they are registered and accept those where thedestinations match the CM itself or CPEs reached via the CMCI port. CMs can communicate with other CMsonly through the CMTS.

The upstream channel is characterized by many transmitters (CMs) and one receiver (the CMTS). Time in theupstream channel is slotted, providing for Time Division Multiple Access at regulated time ticks. The CMTSprovides the time reference and controls the allowed usage for each interval. Intervals may be granted fortransmissions by particular CMs, or for contention by all CMs. CMs may contend to request transmission time.To a limited extent, CMs may also contend to transmit actual data. In both cases, collisions can occur and retriesare used.

Section 8 describes the MAC-sublayer messages from the CMTS which direct the behavior of the CMs on theupstream channel, as well as messaging from the CMs to the CMTS.

5.5.3.1 MAC Service Definition

The MAC sublayer service definition is in I.

5.6 Physical Layer

The Physical (PHY) layer is comprised of two sublayers:

• Transmission Convergence sublayer (present in the downstream direction only)

• Physical Media Dependent (PMD) sublayer

5.6.1 Downstream Transmission Convergence Sublayer

The Downstream Transmission Convergence sublayer exists in the downstream direction only. It provides anopportunity for additional services over the physical-layer bitstream. These additional services might include, forexample, digital video. Definition of any such additional services is beyond the scope of this document.

This sublayer is defined as a continuous series of 188-byte MPEG [ITU-T H.222.0] packets, each consisting of a4-byte header followed by 184 bytes of payload. The header identifies the payload as belonging to the data-over-cable MAC. Other values of the header may indicate other payloads. The mixture of payloads is arbitrary andcontrolled by the CMTS.

The Downstream Transmission Convergence sublayer is defined in Section 7 of this document.

5.6.2 PMD Sublayer

The Physical Media Dependent sublayer is defined in Section 6, “Physical Media Dependent SublayerSpecification,” on page 39.

36


5.6.2.1 Interface Points

Three RF interface points are defined at the PMD sublayer:

a) Downstream output on the CMTS

b) Upstream input on the CMTS

c) Cable in/out at the cable modem

Separate downstream output and upstream input interfaces on the CMTS are required for compatibility withtypical downstream and upstream signal combining and splitting arrangements in head-ends.

37



38


6 Physical Media Dependent Sublayer Specification

6.1 Scope

This specification defines the electrical characteristics and signal processing operations for a cable modem (CM)and cable modem termination system (CMTS). It is the intent of this specification to define an interoperable CMand CMTS such that any implementation of a CM can work with any CMTS. It is not the intent of thisspecification to imply any specific implementation.

This section applies to the first technology option referred to in Section 1 (1.1 Scope). For the second option,refer to Annex F.

Whenever any reference in this section to spurious emissions conflicts with any legal requirement for the area ofoperation, the latter shall take precedence.

6.2 Upstream

6.2.1 Overview

The upstream Physical Media Dependent (PMD) sublayer uses a FDMA/TDMA (herein called TDMA mode) orFDMA/TDMA/S-CDMA (herein called S-CDMA mode) burst type format, which provides six modulation ratesand multiple modulation formats. The use of TDMA or S-CDMA mode is configured by the CMTS via MACmessaging.

FDMA (frequency division multiple access) indicates that multiple RF channels are assigned in the upstreamband. A CM transmits on a single RF channel unless reconfigured to change channels. TDMA (time divisionmultiple access) indicates that upstream transmissions have a burst nature. A given RF channel is shared bymultiple CMs via the dynamic assignment of time slots. S-CDMA (synchronous code division multiple access)indicates that multiple CMs can transmit simultaneously on the same RF channel and during the same TDMAtime slot, while being separated by different orthogonal codes.

In this document, the following naming conventions are used. For TDMA, the term “modulation rate” refers tothe RF channel symbol rate (160 to 5120 ksps). For S-CDMA, the term “chip rate,” which is the modulation rate(1280 to 5120 kHz) of a single bit of the S-CDMA spreading code, may be used interchangeably with“modulation rate”. The “modulation interval” is the symbol period (TDMA mode) or chip period (S-CDMAmode) and is the reciprocal of the modulation rate. At the output of the spreader, a group of 128 chips whichcomprise a single S-CDMA spreading code, and are the result of spreading a single information (QAMconstellation) symbol is referred to as a “spread symbol”. The period of a spread symbol (128 chips) is called a“spreading interval.” A “burst” is a physical RF entity that contains a single preamble plus data, and (in theabsence of preceding and following bursts) exhibits RF energy ramp-up and ramp-down.

In some cases logical zeros are used to pad data blocks; this indicates data with zero-valued binary bits, whichresult in non-zero transmitted RF energy. In other cases a numerical zero is used; this denotes, for example,symbols which result in zero transmitted RF energy (after ramp-up and ramp-down are taken into account).

The modulation format includes pulse shaping for spectral efficiency, is carrier-frequency agile, and hasselectable output power level.

Each burst supports a flexible modulation order, modulation rate, preamble, randomization of the payload, andprogrammable FEC encoding.

39


All of the upstream transmission parameters associated with burst transmission outputs from the CM areconfigurable by the CMTS via MAC messaging. Many of the parameters are programmable on a burst-by-burstbasis.

The PMD sublayer can support a near-continuous mode of transmission, wherein ramp-down of one burst MAYoverlap the ramp-up of the following burst, so that the transmitted envelope is never zero. In TDMA mode, thesystem timing of the TDMA transmissions from the various CMs MUST provide that the center of the lastsymbol of one burst and the center of the first symbol of the preamble of an immediately following burst areseparated by at least the duration of five symbols. The guard band MUST be greater than or equal to the durationof five symbols plus the maximum timing error. Timing error is contributed by both the CM and CMTS. CMtiming performance is specified in Section 6.2.19. Maximum timing error and guard band may vary with CMTSsfrom different vendors. The term guard time is similar to the guard band, except that it is measured from the endof the last symbol of one burst to the beginning of the first symbol of the preamble of an immediately followingburst. Thus, the guard time is equal to the guard band – 1.1

The PMD sublayer also supports a synchronous mode of transmission when using S-CDMA, wherein rampdownof one burst MAY completely overlap the ramp-up of the following burst, so that the transmitted envelope isnever zero. There is no guard time for transmission on S-CDMA channels. The system timing of the S-CDMAtransmissions from the various CMs MUST provide adequate timing accuracy so that different CMs do notappreciably interfere with each other. S-CDMA utilizes precise synchronization so that multiple CMs cantransmit simultaneously.2

The upstream modulator is part of the cable modem which interfaces with the cable network. The modulatorcontains the electrical-level modulation function and the digital signal-processing function; the latter providesthe FEC, preamble prepend, symbol mapping, and other processing steps.

At the Demodulator, similar to the Modulator, there are two basic functional components: the demodulationfunction and the signal processing function. The Demodulator resides in the CMTS and there is onedemodulation function (not necessarily an actual physical demodulator) for each carrier frequency in use. Thedemodulation function receives all bursts on a given frequency.

The demodulation function of the Demodulator accepts a varying-level signal centered around a commandedpower level and performs symbol timing and carrier recovery and tracking, burst acquisition, and demodulation.Additionally, the demodulation function provides an estimate of burst timing relative to a reference edge, anestimate of received signal power, may provide an estimate of signal-to-noise ratio, and may engage adaptiveequalization to mitigate the effects of a) echoes in the cable plant, b) narrowband ingress and c) group delay. Thesignal-processing function of the Demodulator performs the inverse processing of the signal-processing functionof the Modulator. This includes accepting the demodulated burst data stream and decoding, etc. The signal-processing function also provides the edge-timing reference and gating-enable signal to the demodulators toactivate the burst acquisition for each assigned burst slot. The signal-processing function may also provide anindication of successful decoding, decoding error, or fail-to-decode for each codeword and the number ofcorrected Reed-Solomon symbols in each codeword. For every upstream burst, the CMTS has a prior knowledgeof the exact burst length in modulation intervals (see Sections 6.2.19, 6.2.5.1, and A.2).

6.2.2 Signal Processing Requirements

The signal processing order for each burst packet type MUST be compatible with the sequence shown in Figure6-1. For TDMA mode, the signal processing order for each burst packet type MUST follow the order of steps in

1. Last five sentences of this paragraph updated per RFI2-N-02085 by RKV on 10/28/02.2. This paragraph updated per RFI2-N-02173 by RKV on 10/30/02.

40


Figure 6-2. For S-CDMA mode, the signal processing order for each burst packet type MUST follow the order ofsteps in Figure 6-3.

The blocks used only in S-CDMA consist of a TCM encoder, S-CDMA framer, and S-CDMA spreader. TheTCM encoder provides trellis modulation encoding of data symbols and is described in Section 6.2.8. The S-CDMA framer maps mini-slots into code resources and provides interleaving of data symbols and is described inSection 6.2.11. The S-CDMA spreader spreads S-CDMA framed symbols for transmission and is described inSection 6.2.14, “S-CDMA Spreader,” on page 71.

Figure 6-1 Upstream signal-processing sequence

RSEncoder

ByteInterleaver

(TDMA only)Scrambler

TCM Encoder(S-CDMA only)

PreamblePrepend

SymbolMapper

Framer(S-CDMA only)

Spreader(S-CDMA only)

Transm itEqualizer

Filter Modulator

Burstdata in

RF out

41


Figure 6-2 TDMA Upstream Transmission Processing

Packet Stream Input

Block the Data

⇓

Separate Packet into Information Blocks (=databytes in one codeword)

R-S Encode

⇓

R-S (Reed-Solomon) Encode each InformationBlock, using shortened codeword for last block ifneeded. R-S FEC can be turned off.

Byte Interleave

⇓

R-S Byte Interleave. R-S Byte interleaver can beturned off.

Scramble

⇓

Scramble (see Figure 6-7)

Preamble Prepend

⇓

Prepend Preamble Symbols

Symbol Map

⇓

Map the Data Stream into Modulator Symbols

Transmit Equalize

⇓

Pre-Equalize the Symbol Stream

Filter

⇓

Filter Symbol Stream for Spectral Shaping

Modulate

⇓

Modulate at Precise Times (QPSK; 8 QAM; 16QAM; 32 QAM; 64 QAM)

⇓

Output RF Waveform Bursts

42


Figure 6-3 S-CDMA Upstream Transmission Processing

Packet Stream Input

Block the Data

⇓

Separate Packet into Information Blocks (=databytes in one codeword)

R-S Encode

⇓

R-S (Reed-Solomon) Encode each InformationBlock, using shortened codeword for last block ifneeded. R-S FEC can be turned off.

Scramble

⇓

Scramble (see Figure 6-7)

TCM Encode

⇓

TCM (Trellis Coded Modulation) Encode thebytes. TCM can be turned off.

Preamble Prepend

⇓

Prepend Preamble Symbols

S-CDMA Framer

⇓

Frame and Interleave the Data into Mini-Slots.

Symbol Map

⇓

Map the Data Stream into Modulator Symbols

S-CDMA Spreader

⇓

Spread the Symbols. For spreader-off bursts on S-CDMA channels, spreader can be turned off.

Transmit Equalize ⇓

Pre-Equalize the Signal Stream

Filter

⇓

Filter Signal for Spectral Shaping

Modulate

⇓

Modulate at Precise Times (QPSK; 8 QAM; 16QAM; 32 QAM; 64 QAM; 128 QAM/TCM only)

⇓

Output RF Waveform Bursts

43


6.2.3 Modulation Formats

The upstream modulator MUST provide QPSK and 16QAM differential encoded modulations for TDMA.

The upstream modulator MUST provide QPSK, 8QAM, 16QAM, 32QAM, and 64QAM modulations for TDMAand S-CDMA channels.

The upstream modulator MUST provide QPSK, 8QAM, 16QAM, 32QAM, 64QAM and 128QAM TCMencoded modulations for S-CDMA channels.

The upstream demodulator MAY support QPSK and 16QAM differential modulation for TDMA.

The upstream demodulator MUST support QPSK, 16QAM, and 64QAM modulations for TDMA and S-CDMAchannels.

The upstream demodulator MAY support 8QAM and 32QAM modulation for TDMA and S-CDMA channels.

The upstream demodulator MAY support QPSK, 8QAM, 16QAM, 32QAM, 64QAM, and 128QAM TCMencoded modulations for S-CDMA channels.

6.2.4 R-S Encode

6.2.4.1 R-S Encode Modes

The upstream modulator MUST be able to provide the following selections: Reed-Solomon codes over GF(256)with T = 1 to 16 or no R-S coding.

The following Reed-Solomon generator polynomial MUST be supported:

g(x) = (x+α0) (x+α1)...(x+α2T-1) where the primitive element alpha is 0x02 hex

The following Reed-Solomon primitive polynomial MUST be supported:

p(x) = x8 + x4 + x3+ x2 + 1

The upstream modulator MUST provide codewords from a minimum size of 18 bytes (16 information bytes [k]plus two parity bytes for T = 1 error correction) to a maximum size of 255 bytes (k-bytes plus parity-bytes). Theminimum uncoded word size MUST be one byte.

In Shortened Last Codeword mode, the CM MUST provide the last codeword of a burst shortened from theassigned length of k data bytes per codeword as described in Section 6.2.5.1.3.

The value of T MUST be configured in response to the Upstream Channel Descriptor from the CMTS.

6.2.4.2 R-S Bit-to-Symbol Ordering

The input to the Reed-Solomon Encoder is logically a serial bit stream from the MAC layer of the CM, and thefirst bit of the stream MUST be mapped into the MSB of the first Reed-Solomon symbol into the encoder. TheMSB of the first symbol out of the encoder MUST be mapped into the first bit of the serial bit stream fed to theScrambler.

Note: The MAC byte-to-serial upstream convention calls for the byte LSB to be mapped into the first bit of the serial bit streamper Section 8.2.1.3.

44


6.2.5 R-S Frame Structure

Figure 6-4 shows two examples of the R-S frame structure: one where the packet length equals the number ofinformation bytes in a codeword, and another where the packet length is longer than the number of informationbytes in one codeword, but less than in two codewords. Example 1 illustrates the fixed codeword-length mode,and Example 2 illustrates the shortened last codeword mode. These modes are defined in Section 6.2.5.1.

Figure 6-4 Example Frame Structures with Flexible Burst Length Mode

6.2.5.1 R-S Codeword Length

When R-S FEC is enabled, the CM operates in either fix-length codeword mode or in shortened-last codewordmode. The minimum number of information bytes in a codeword in either mode is 16. Shortened-last codewordmode only provides a benefit when the number of bytes in a codeword is greater than the minimum of 16 bytes.

The intent of the following sections is to define rules and conventions such that CMs request the proper numberof mini-slots and the CMTS PHY knows what to expect regarding the R-S FEC framing in both fixed codewordlength and shortened last codeword modes. Shortened last codeword mode MUST NOT be used for InitialMaintenance (broadcast or unicast).

6.2.5.1.1 Burst Size

For an allocation of mini-slots (in both contention and non-contention regions), the requirements of Sections6.2.5.1.2 and 6.2.5.1.3 apply to a burst transmitted in that allocation. Regardless of the size of the allocation, thesize of the burst MUST be as specified in Table 6-1 below.

Preamble Packet DataFECParity

GuardTime

Empty up toNext Mini-Slot

Boundary

Example 2. Packet length = k + remaining information bytes in 2nd codeword = k + k’≤ k + k’’ ≤ 2k

Preamble Two Codewords GuardTime

FECParity

First k Bytesof Packet

Last k’ Bytesof Packet

FECParity

k’’-k’ bytes ofzero-fill

mini-slotboundary

Example 1. Packet length = number of information bytes in codeword = k

One Codeword

45


Table 6-1 Burst Size

6.2.5.1.2 Fixed Codeword Length

With the fixed-length codewords, after all the data are encoded, zero-fill will occur in this codeword if necessaryto reach the assigned k data bytes per codeword. Additionally, zero-fill MUST continue up to the point when noadditional fixed-length codewords can be inserted before the end of the burst specified in Table 6-1 above,accounting for preamble, FEC parity, return-to-zero bits and guard-time symbols (if any).

6.2.5.1.3 Shortened Last Codeword

As shown in Table 6-4, let k’ = the number of information bytes that remain after partitioning the informationbytes of the burst into full-length (k burst data bytes) codewords. The value of k’ is less than k. Given operationin a shortened last codeword mode, let k” = the number of burst data bytes plus zero-fill bytes in the shortenedlast codeword. In shortened codeword mode, the CM MUST encode the data bytes of the burst (including MACHeader) using the assigned codeword size (k information bytes per codeword) until 1) all the data are encoded, or2) a remainder of data bytes is left over which is less than k. Shortened last codewords MUST NOT have lessthan 16 information bytes, and this is to be considered when CMs make requests of mini-slots. In shortened lastcodeword mode, the CM MUST zero-fill data if necessary up to the Burst Size specified in Table 6-1 aboveaccounting for preamble, FEC parity, return-to-zero bits and guard-time symbols (if any). Therefore, in manycases, only k” - k’ zero-fill bytes are necessary with 16 <= k” <= k and k’ <= k”.

More generally, the CM MUST zero-fill data until the point when no additional fixed-length codewords can beinserted before the end of the burst specified in Table 6-1 above, accounting for preamble, FEC parity, return-to-zero bits and guard-time symbols (if any), and then, if possible, a shortened last codeword of zero-fill MUST beinserted to fit into the last mini-slot.

If, after zero-fill of additional codewords with k information bytes, there are less than 16 bytes remaining beforethe end of the burst specified in Table 6-1 above, accounting for preamble, FEC parity, return-to-zero bits andguard-time symbols (if any), then the CM shall not create this last shortened codeword.

6.2.5.2 R-S FEC Disabled

When T = 0 (no FEC parity bytes), the RS encoder SHOULD zero-fill in full bytes to the end of the burstspecified in Section 6.2.5.1.1 above, accounting for preamble, return-to-zero bits, and guard-time symbols (ifany).1

IUC Burst Size

1, 3 Minimum number of mini-slots required for message transmission including burst overhead. Burst overheadincludes pre-amble, R-S parity bytes, TCM return-to-zero bits, and guard time if applicable.

2 Number of mini-slots specified in the Well-Known Multicast SID (refer to Annex A).

4-6, 9-11 Number of mini-slots allocated.

1. Sections 6.2.5.1, 6.2.5.1.1, 6.2.5.1.2, 6.2.5.1.3, and 6.2.5.2 updated and/or added per RFI2-N-02135by RKV on 10/29/02.

46


6.2.6 TDMA Byte Interleaver

R-S codeword interleaving in a byte (R-S symbol) format MUST be performed after R-S encoding on a TDMAchannel. The byte interleaver changes the order of the bytes at the R-S encoder output, i.e., it performs anoperation of byte permutation. At the receiver side, the original order of bytes is restored prior to the R-Sdecoding. Therefore, if some consecutive bytes were corrupted by burst noise, they are spread between variousR-S codewords, averaging the number of erroneous bytes in each codeword. The interleaver is a blockinterleaver type, i.e., the permutation is achieved by filling a table row-wise (one row per R-S codeword), andreading it column-wise. The total memory size allocated for the table is 2048 bytes.

The byte interleaver is disabled when the R-S encoder is turned off (T = 0).

6.2.6.1 Byte Interleaver Parameters

The interleaver operating parameters described in Table 6-2 determine the operation of the interleaver for everyburst.

The CMTS and CM MUST use the interleaver parameters within the allowed values in 6-2 with the followingadditional restrictions:

1. Nr and Ir MUST be chosen such that Nr×Ir<= 2048 (in other words, for a given Nr, the maximal value of Ir isIr,max=floor(2048/Nr)).

2. Nr MUST be identical to the R-S codeword length (i.e. k+2T)

3. Br is effective only when Ir=0. This mode is called dynamic mode.

4. When Ir=1, interleaving is disabled.

Nr, Ir, and Br are specified in the burst profile, and Nf is implied in the MAP message.

6.2.6.2 Interleaver Operating Modes

The interleaver MUST support both an operating mode in which the block size is fixed, as well as, a dynamicmode in which the interleaver depth is determined based on the burst size.

6.2.6.2.1 Fixed Mode

The RS encoded data bytes of the packet are first divided into interleaver blocks of Nr×Ir bytes (i.e., blocks of IrRS codewords each). The size of the last interleaver block may be smaller when the packet length is not aninteger multiple of Nr×Ir. Each interleaver block is interleaved separately.

Table 6-2 Interleaver Operating Parameters

Parameter Definition Allowed Values

Nr Interleaver Width (RS Codeword Length, k+2*T) 18 to 255

Ir Interleaver Depth 0 - Dynamic Mode

1 - No Interleaving

2 to floor(2048/Nr) for

Fixed Mode

Br Interleaver Block Size 2*Nr to 2048

Nf Packet Size (in bytes, including FEC) ≥18 bytes

47


Each interleaver block is filled into a table with Ir rows and Nr columns. The data is written row by row (from leftto right). Therefore, each row corresponds to one RS codeword. The bytes are read column by column (from topto bottom). The interleaver operation is demonstrated in Figure 6-5.

Figure 6-5 Byte Interleaver Operation

The last interleaver block might have fewer rows than Ir. If the shortened last codeword mode is applied, then thelast row might have fewer elements than Nr. In these cases, the interleaver table is read column by column,skipping the empty elements of the table. The interleaver operation for the last interleaver block is demonstratedin Figure 6-6.

Figure 6-6 Interleaver operation for last interleaver block (with shortened last codeword)

Write

Read

C1(1) C1(2)

C2(1) C2(2)

CIr(1) CIr(2)

Input sequence: C1(1),...C1(Nr),C2(1),....C2(Nr),C3(1).....CIr(Nr)

Output sequence: C1(1),C2(1)...CIr(1),C1(2),....CIr(2),C1(3).....CIr(Nr)

C1(Nr)

C2(Nr)

CIr(Nr)

Write

Read

Input sequence: C1(1),...C1(Nr),C2(1),....C2(Nr),C3(1).....CI'(1)......CI'(N')

Output sequence:

C1(1),C2(1)...CI'(1),C1(2)...CI'(2)...C1(N')...CI'(N'),C1(N'+1)....CI'-1(N'+1),C1(N'+2)...Ci'-1(N'+2)...C1(Nr)...CI'-1(Nr)

C1(1) C1(2) C1(Nr)

C2(1) C2(2) C2(Nr)

CI'(1) CI'(N')CI'(2)

C1(N')

Ci'-1(Nr)Ci'-1(N')

48


6.2.6.2.2 Dynamic Mode

In the fixed mode, the interleaving depth of the last interleaving block of a packet (I' in Figure 6-6) may be assmall as one, resulting in low burst noise robustness for this block. In the dynamic mode, the depths of theinterleaver blocks are chosen such that all blocks have approximately the same depth to achieve nearly optimalburst noise robustness (for the given block size).

The RS encoded data bytes of the packet are first divided into Ns0 interleaver blocks. The size of the ith

interleaver block is Nr*Ir(i) bytes (i.e. a block of Ir

(i) RS codewords). The size of the last interleaver block may besmaller in the shortened last codeword mode. Each interleaver block is interleaved separately (see the equationsfor Ns

0 and Ir(i) in Section 6.2.6.2.2.1).

The ith interleaver block is filled into a table with Ir(i) rows and Nr columns. The data is written row-wise (from

left to right). Therefore, each row corresponds to one RS codeword. The bytes are read column-wise (from top tobottom). The interleaver operation is demonstrated in 6-5(except that there are Ir

(i) rows instead of Ir).

If the shortened last codeword mode is applied, then the last row might have fewer elements than Nr. In this case,the interleaver table is read column by column, skipping the empty elements of the table. The interleaveroperation for the last interleaver block is demonstrated in Figure 6-6 (except that there are Ir

(Ns0)rows instead ofI').

6.2.6.2.2.1 Dynamic Mode Calculations

0sN and )(i

rI are determined by the following equations:

Total number of interleaver rows: )/(0rftot NNceilI = .

Maximal number of rows per segment: )/(max, rrr NBfloorI = .

Number of segments: )/( max,00

rtots IIceilN =

Interleaver depth of first block: )/( 001stotr NIfloorI =

No. of blocks with depth of 1rI : 010 )1( totrs IINM −+⋅=

Then for segment i, )(irI is calculated as follows ( 0...1 sNi = ):

+=+

==

01

1)(

,...,1,1

,...,1,

sr

rir

NMiI

MiII

49


6.2.7 Scrambler (Randomizer)

The upstream modulator MUST implement a scrambler (shown in Figure 6-7) where the 15-bit seed valueMUST be arbitrarily programmable.

At the beginning of each burst, the register is cleared and the seed value is loaded. The seed value MUST be usedto calculate the scrambler bit which is combined in an XOR with the first bit of data of each burst (which is theMSB of the first symbol following the last symbol of the preamble).

The scrambler seed value MUST be configured in response to the Upstream Channel Descriptor from the CMTS.

The polynomial MUST be x15 + x14 + 1.

Figure 6-7 Scrambler Structure

6.2.8 TCM Encoder

RS symbol interleaving is commonly included between the TCM and RS blocks to preserve coding gain in thepresence of bursty errors produced at the output of the TCM decoder. This interleaver was not included in theoriginal baseline S-CDMA proposal to reduce memory requirements at the expense of coding gain.

In S-CDMA mode the CM MUST support trellis coded modulation for transmission of m = 1, 2, 3, 4, 5, and 6bits per symbol with QPSK0, 8QAM, 16QAM, 32QAM, 64QAM, and 128QAM constellations, respectively.Support of TCM in the CMTS is optional.

Figure 6-8 shows the employed 8-state TCM encoder. The encoding operation causes a mapping of m input bitsinto m+1 output bits for input into the symbol mapping block. The systematic convolutional encoder adds thecoded bit x1 = s0 to the input bits im, … i3,i2,i1. For m = 1, only input bit i1 is used (i2 = 0), and encoding isreduced to rate-1/2 coding.

DELAYELEMENT

1

RANDOMIZERDATAINPUT

RANDOMIZERDATA

OUTPUT

SEEDLOAD / FRAME RESET

DELAYELEMENT

2

DELAYELEMENT

3

XOR

DELAYELEMENT

N-2

DELAYELEMENT

N-1

XOR

DELAYELEMENT

N

N = 15

SEEDLSB

SEEDMSB

50


Figure 6-8 Convolutional encoder

The initial state of the TCM encoder MUST be the zero state. The zero state MUST be reached again with thelast encoded symbol.

To return to the zero state from all possible Trellis paths, if m = 1 (QPSK) three tail symbols (nt = 3) MUST begenerated with input bit i1 set to i1 = s1. By inspection of Figure 6-8, after three symbols the state bits s2, s1, ands0 = x1 will be zero. Tail symbols are extra symbols, which carry no information.

If m = 2, to return to the zero state from all possible Trellis paths, two tail symbols (nt=2) MUST be generated.The input bits i2i1 MUST be set such that the zero state is reached after two symbols. If the first symbol is set toi2 = 0, i1 = s1, and the second (final) symbol to i2 = s2, i1 = s1 after these two symbols the state bits s2, s1, and s0 =x1 will be zero.

If m ≥ 3, the uncoded bits im,...,i3 MUST be used for information encoding, when this is possible. Otherwise,uncoded bits MUST be set to zero. The number of tail symbols carrying no information depends on the endingconditions and can vary between zero and two (0 ≤ nt ≤ 2).

6.2.8.1 Byte to TCM Symbol Mapping

The mapping of bytes to TCM symbols is done such that each byte is mapped entirely to the uncoded bitsi m ,...,i 3 , or entirely to the convolutional encoder input bits i 2 i 1 . The decision is made sequentially for eachbyte using the rule that the byte assignment should lead to the shortest packet of symbols including tail symbols,if the current byte were the last byte to be encoded. This rule results in the repetitive patterns of byte assignmentsto label bits shown in Figure 6-9 for m=1 to 6. In the figure bit i m is at the top and bit i 1 is at the bottom.1

The MSB (im) MUST be the first bit in the serial data fed into the uncoded input bits (i.e. im to i3). The MSB (i2)MUST be the first bit in the serial data fed into the coded input bits.

Figure 6-10 illustrates the byte assignments for Trellis-coded 64QAM modulation by two examples. Notice thatbytes are assigned in a repetitive pattern of five bytes. In the first example, Nf is divisible by five. In this case twotail symbols are appended. In the second example, Nf is not divisible by five and no tail symbols are required.The bits needed for returning to the zero state are available in symbols still carrying information.

1. This paragraph updated per RFI2-N-02135 by RKV on 10/29/02.

D D D

xm+1

:

x4

x3

x2

im

:

i3

i2

i1

s2 s1 s0=x1

S-CDMAFraming

symbollabels

51


Figure 6-9 Repetitive patterns of byte mapping to symbol map bits for TCM

Figure 6-10 Example byte to bit assignment for 64 QAM

The CM MUST place the return-to-zero bits right after the last coded data sub-symbol, that is, the last coded sub-symbol corresponding to the parity bytes of the last shortened or fixed codeword including any zero-filledcodeword in the grant. The rest of the coded bits MUST be filled with zeros.1

m = 6 (128QAM)1 2

3

1 2 4

3 5

12

1 32

1 2

1

m = 5 (64QAM)

m = 4 (32QAM)

m = 3 (16QAM)

m = 2 (8QAM)

m = 1 (QPSK)

0

zero fillbits

bits to returnto zero state

redundantcode bits

x6

x5

x4

x3

x2

x1

np preamblesymbols

ni TCMsymbols

msb1

msb3

msb2

msb4

msb8

msb6

msbNf-2

0

0

0

0msbNf

msbNf-1

msb5

nt = 2tail symbols

ni TCM symbols, notail symbols (nt = 0)

0

0

msb1

msb3

msb2

msb4

msb8

msb6

msbNf-2

0msbNf

msbNf-1

msb5

zeroinitialstate

zerofinalstate

0

0

0

.........

.........

.........

.........

.........

.........

.........

.........

...............

..

..

..

52


Figure 6-11 illustrates the placing of return-to-zero bits for 64QAM when the last transmitted byte is #1. The firsttwo pairs of x2 and x3 are the return to zero bits, and the last empty coded pair is zero filled.

Figure 6-11 Example of return to zero bits followed by “0”

6.2.9 Preamble Prepend

The upstream PMD sublayer MUST support a variable-length preamble field that is prepended to the data afterthey have been randomized, Reed-Solomon encoded, and TCM encoded.

The first bit of the Preamble Pattern is the first bit into the symbol mapper (see Section 6.2.13). The first bit ofthe Preamble Pattern is designated by the Preamble Value Offset as described in Table 8-19, Section 8.3.3. Thepreamble is interleaved by the framer in S-CDMA mode.

The preamble sequence MUST be programmable. For DOCSIS 2.0 bursts (bursts encoded using a Type 5 burstdescriptor per Section 8.3.3), the preamble MUST use the QPSK0 or QPSK1 constellation (per Figure 6-18 andFigure 6-19) with preamble length 0, 2, 4, 6, ..., or 1536 bits (maximum 768 QPSK symbols). For DOCSIS 1.xcompatible bursts (Type 4 burst descriptor) that use QPSK modulation, the preamble and data MUST use theQPSK0 constellation with preamble length 0, 2, 4, 6, ..., or 1024 bits (maximum 512 QPSK symbols). ForDOCSIS 1.x compatible bursts (Type 4 burst descriptor) that use 16QAM modulation, the preamble and dataMUST use the 16QAM constellation with preamble length 0, 4, 8, 12, ..., or 1024 bits (maximum 256 16QAMsymbols).

The preamble length and value MUST be configured in response to the Upstream Channel Descriptor messagetransmitted by the CMTS.

1. Section 6.2.8.1, second-to-last paragraph updated per RFI2-N-02111 by RKV on 10/29/02.

Uncoded bitsu

Zero fill bits0

Bits to return to zero stater

i5 u u u x6

i4 u u u x5

i3 u u 0 x4

i2 0 r 0 x3

i1 r r 0 x2

x1

53


6.2.10 Modulation Rates

In TDMA mode, the CM upstream modulator MUST provide all modulations at 160, 320, 640, 1280, 2560 and5120 ksym/sec.

In S-CDMA mode, the CM upstream modulator MUST provide all modulations at 1280, 2560 and 5120 ksym/sec.

In TDMA mode, the CMTS upstream demodulator MUST be able to support demodulation at 160, 320, 640,1280, 2560 and 5120 ksym/sec. In S-CDMA mode, the CMTS upstream demodulator MUST be able to supportdemodulation at 1280, 2560 and 5120 ksym/sec.

This variety of modulation rates, and flexibility in setting upstream carrier frequencies, permits operators toposition carriers in gaps in the pattern of narrowband ingress, as discussed in Annex G.

The modulation rate for each upstream channel is defined in an Upstream Channel Descriptor (UCD) MACmessage. All CMs using that upstream channel MUST use the defined modulation rate for upstreamtransmissions.

6.2.11 S-CDMA Framer and Interleaver

6.2.11.1 S-CDMA Framing Considerations

The S-CDMA mode of the PHY layer accepts data presented to it for transmission from the MAC layer. Thisdata is presented as bursts of n mini-slots. These bursts are mapped within the PHY layer to a combination ofspreading codes and time slots, in order to exploit the multi-dimensional spreading of information by theS-CDMA mode.

There are various adjustable parameters in the upstream channel parameters and upstream burst attributes thatallow controlling the mini-slot to physical layer mapping, as well as tuning the channel to accommodate a varietyof channel conditions, noise characteristics, capacities, reliability levels, and latency requirements.

When operating in S-CDMA mode, data is transmitted in two dimensions: codes and time. For this reason, datato be transmitted must be grouped into two-dimensional rectangular frames prior to transmission.

At the physical layer, data is sent over an array of up to 128 spreading codes. There is a programmable number ofspreading intervals per frame, as shown in Figure 6-13 below. A spreading interval is the time required totransmit one symbol per code across all 128 codes in S-CDMA mode. Note that the specific codes which areused and the details of the spreading operation are described in detail in Section 6.2.14, “S-CDMA Spreader,” onpage 71.

A burst from a particular CM may be transmitted on two or more codes in one or more frames. A frame maycontain bursts transmitted simultaneously from multiple CMs (each on a separate subset of the codes) as definedby the MAP message.

6.2.11.2 Mini-slot Numbering

In normal operation, the MAC will request the PHY to transmit a burst of length n mini-slots, starting at mini-slot m, as defined by the MAP. All CMs and the CMTS MUST have a common protocol of how mini-slots arenumbered, and how they are mapped onto the physical layer framing structure. This common protocol isobtained from information in the SYNC and Upstream Channel Descriptor (UCD) messages. (These messages

54


are described in Section 8.3.2, “Time Synchronization (SYNC),” on page 132, and Section 8.3.3, “UpstreamChannel Descriptor (UCD),” on page 132.)

Mini-slots are mapped onto frames starting at the first active code (usually code number 0), are numberedsequentially through the remainder of the frame (code number 127), and then wrap to the next sequential frame.Mini-slots are mapped onto a group of consecutive codes.

The CMTS and the CMs require a common protocol for mini-slot numbering. For operation on a TDMAchannel, this is achieved solely through recovery of the timestamp. Since the time duration of an S-CDMA frameis not necessarily a power-of-2 multiple of the 10.24 MHz reference, the timestamp rollover (at 232 counts) is notnecessarily at an S-CDMA frame boundary. Therefore, an additional synchronization step is required.

The CMTS MUST identify frame boundaries relative to the timestamp counter on a periodic basis. This is calledthe timestamp snapshot and must be sent in the UCD for each upstream S-CDMA channel.

The CMTS MUST maintain a frame counter and a mini-slot counter, and MUST sample these values along withthe timestamp, on a frame boundary, as shown below. The CMTS MUST obtain a new sample prior to sendingeach UCD message.

Figure 6-12 Timestamp Snapshot

Each CM MUST maintain a timestamp counter, mini-slot counter, and frame counter functionally identical to theCMTS.

From the UCD message, the CM receives the CMTS timestamp snapshot and parameters from which it cancalculate the number of time counts per S-CDMA frame. Using modulo arithmetic, the CM can then calculateaccurate values for timestamp, mini-slot, and frame counters at any point into the future.

Mini-slot m

Mini-slot m+62 Mini-slot m+125

code 0

code 1

code 2

code 3

code 126

code 127

frame f frame f+1

.........

frame f+2

K spreading intervals K spreading intervals K spreading intervals

Mini-slot m+188


t

t1 t2 t3 t4timestamp counts

timestamp countframe

numberminislot number

32 bits 8 bits32 bits

Mini-slot m+63

t3

timestamp snapshot

Includedin UCD

55


The CM can then update its local mini-slot and frame counters at an appropriate timestamp counter value. At thispoint, the CM representation of mini-slots and frames are aligned with those in the CMTS.

The CMTS and CM MUST implement a 32-bit timestamp counter, a 32-bit mini-slot counter, and an 8-bit framecounter, as follows:

• The mini-slot counter MUST contain the value of the first mini-slot of the frame when it is sampled. It MAYbe incremented by the number of mini-slots per frame, once per frame interval. The mini-slot counter will useall 32 bits and mini-slot numbers will therefore range from 0 to 232-1.

• The only specified function for the frame counter is to reset the code hopping sequence at the frame 0 (mod-ulo-256) boundary, as defined in Section 6.2.14.1, “Code Hopping,” on page 72.

The frame structure above relates to the entire upstream and not necessarily to the transmission from a singleCM. The codes are resources which are allocated to CMs over each S-CDMA frame. The assignment of codes toCMs is performed by the framer as it assigns a burst of symbols a particular order in the two-dimensional matrixof codes and time. This symbol sequencing is described in detail in Section 6.2.12.

6.2.11.2.1 Mini-slot Numbering Parameters in UCD

There are three parameters specified in the UCD that define mini-slot mapping: spreading intervals per frame,codes per mini-slot, and number of active codes.

Spreading intervals per frame The number of spreading intervals per frame, K, (along with the signalingrate), 1/Ts, define the time duration of an S-CDMA frame, Tfr.

Tfr = K * 128 * Ts

Note that the code length in the above equation is always 128, regardless of how many codes are currently active.

The valid range of the spreading intervals per frame parameter is 1 to 32.

Codes per mini-slot In conjunction with the spreading intervals per frame parameter, the codes per mini-slot(Cms) parameter defines the total number of symbols per mini-slot and therefore the mini-slot capacity. The mini-slot capacity, Sms, is given in symbols by the following expression:

Sms = K * Cms

The lower limit on mini-slot capacity is 16 symbols (refer to Annex B). However, the mini-slot must also belarge enough to allow the transmission of the largest-sized data PDU (including physical layer overhead) in 255mini-slots (see Section 8.3.3). The upper limit on mini-slot capacity is not specifically constrained, but in generalis governed by channel efficiency and MAC performance issues. The valid range of the codes per mini-slotparameter is 2 to 32.

Number of active codes The number of active codes parameter allows the number of codes used to carry datato be less than or equal to 128. When the number of active codes is less than 128, low numbered codes startingwith code 0 are not used, as shown in Figure 6-14.

There are several reasons why it may be desirable to reduce the number of active codes:

• Code 0 does not have the same spreading properties as the other codes and therefore under certain colorednoise conditions will degrade performance.

• In extremely noisy plant conditions, a reduction in the number of active codes (along with the correspondingincrease in power per code for the remaining codes), can allow reliable operation at reduced capacities.Reduction in active codes from 128 to 64 results in a 3 dB improvement in SNR.

56


• The number of mini-slots per S-CDMA frame MUST be an integer. Therefore the codes per mini-slot andnumber of active codes parameters MUST be chosen to result in an integral number of mini-slots per frame.

The valid range of the number of active codes parameter is 64 to 128.

A CMTS MUST support 126 and 128 active codes.

A CM MUST support any non-prime number of active codes in the range of 64 to 128, inclusive.

Note: When the number of active codes is 64 or greater, the S-CDMA frame must consist of more than 1 mini-slot, since thenumber of codes per mini-slot must be in the range 2 to 32. This implies that the number of active codes must be non-prime.The prime numbers between 64 and 128 are 67, 71, 73, 79, 83, 89, 97, 101, 103, 107, 109, 113, and 127.

6.2.11.2.2 Mini-slot Numbering Examples

A typical mini-slot numbering example is shown in Figure 6-13. In this example, there are two codes per mini-slot defined. The number of codes per mini-slot is an adjustable parameter (via the UCD) to allow flexibility indetermining the effective capacity of each mini-slot.

Figure 6-13 Mini-slot Mapping with Two Codes per Mini-slot, 128 Active Codes

A second example, using three codes per mini-slot, is shown in Figure 6-14. Since it is required that there be anintegral number of mini-slots per frame, the number of active codes has been restricted to 126 codes. In thisexample, a trade-off has been made to increase mapping flexibility at the expense of a small reduction in channelcapacity (2/128).

Mini-slot m

Mini-slot m+1

Mini-slot m+63

Mini-slot m+64

Mini-slot m+127

Mini-slot m+128code 0

code 1

code 2

code 3

code 126

code 127

frame f frame f+1

.........

frame f+2


Mini-slot m+191


57


Figure 6-14 Mini-slot Mapping with Three Codes per Mini-slot, 126 Active Codes

There is no implication that physical layer processing is performed on a per mini-slot basis. As in a TDMAchannel, the physical layer is concerned only with the burst start time (mini-slot number) and the burst length.

6.2.11.3 Transmission Time

Ideally, all the mini-slots contained in one S-CDMA frame are received simultaneously. These mini-slots may betransmitted from a single CM or may be transmitted from multiple CMs, as defined by the bandwidth allocationMAP message and the mini-slot mapping configuration settings (from the UCD). Note that a single CM mayhave more than one allocation active in a single S-CDMA frame.

6.2.11.4 Latency Considerations

S-CDMA frame timing is derived directly from (is phase locked to) the 10.24 MHz CMTS master clock. Basedon the allowable signaling rates and the fact that there are 128 signaling periods in a spreading interval, theS-CDMA frame time MUST always be a multiple of 25 µsec.

Selecting the number of spreading intervals per frame and the signaling rate therefore exactly define theS-CDMA frame duration. As a specific example, a burst profile defined with 10 spreading intervals per framewith a signaling rate of 2.56 Mbaud would result in a frame duration of 500 µsec.

The amount of additional upstream latency added by the use of S-CDMA mode is approximately one S-CDMAframe with the exact value described in Section 6.2.17.

Mini-slot m

Mini-slot m+1

Mini-slot m+41

Mini-slot m+42

Mini-slot m+43

Mini-slot m+83

Mini-slot m+84

Mini-slot m+85

Mini-slot m+125

code 0

code 1

code 2

code 3

code 4

code 5

code 6

code 125

code 126

code 127

frame f frame f+1

.........

frame f+2


code 7

58


6.2.11.5 Spreader-off Bursts for Maintenance on S-CDMA channel

Spreader-off bursts are defined as bursts on an S-CDMA channel whose attributes specify that the spreader beturned off. For a spreader-off burst, both the S-CDMA framer and S-CDMA spreader are bypassed. The InitialMaintenance burst type MUST be specified (via UCD) to use spreader-off bursts. The Station Maintenance bursttype MAY be specified (via UCD) to use spreader-off or spreader-on bursts. The CM MUST support bothspreader-on and spreader-off modes for Station Maintenance bursts. All remaining IUC burst types MUST bespecified (via UCD) to use spreader-on bursts. The S-CDMA channel will be programmed (via UCD) for Cmscodes per mini-slot, p number of active codes, K spreading intervals per S-CDMA frame, and a resultant s mini-slots per frame, where s=p/Cms.

Then each S-CDMA frame, where a transmission with the spreader off is to occur, will contain exactly s mini-slots, where each mini-slot consists of Cms*K symbols.

In the case where the number of active codes (p) is less than 128, the frame will still contain exactly s mini-slots,where each mini-slot consists of Cms*K symbols. The first mini-slot of a frame will start with the first symbol ofthe frame. If a burst spans multiple frames, the burst will start relative to the first frame and continue withoutinterruption into the next frame.

Spreader-off bursts for Station Maintenance Regions (IUC 4) MUST be padded with zero data symbols from theend of the R-S encoded data until the end of the burst as defined by the burst boundaries of Section 6.2.5.1.1.Spreader-off bursts for Initial Maintenance Regions (IUC3) MUST be padded with zero data symbols from theend of the R-S encoded data until the end of the burst as defined by the burst boundaries of Section 6.2.5.1.1.Differential encoding and R-S byte interleaving MUST NOT be used with spreader-off bursts on S-CDMAchannels.1

1. This paragraph updated by RKV per RFI2-N-02135 on 10/29/02, per RFI2-N-02173 on 10/30/02.

59


Figure 6-15 S-CDMA and Spreader-off Intervals

The CMTS scheduler MUST ensure that the spreader-off interval is aligned to the start of an S-CDMA frame,occurs completely within one or more S-CDMA frames, and MUST ensure that no spreader-on bursts arescheduled during these same frames. The CMTS scheduler MUST grant at most one spreader-off burst per CMper frame. It is the responsibility of the CMTS to allocate mini-slots to the NULL SID, as required to preventinterference between bursts (i.e., before and after spreader-off bursts when the CM might not be sufficientlysynchronized).

During spreader-off bursts on S-CDMA channels when less than 128 active codes are in use, the spreader-offframe will contain quiet mini-slots (dead time) equal to the number of inactive codes.

6.2.12 S-CDMA Framer

The S-CDMA framer maps mini-slots to spreading codes and spreading intervals by arranging them as symbolswithin an S-CDMA frame. It also performs an interleaving function, to provide protection against impulse noise.The S-CDMA framer's function of mapping mini-slots to spreading codes and spreading intervals is illustrated inSection 6.2.11, “S-CDMA Framer and Interleaver,” on page 54. As previously described, an S-CDMA frame isdefined by the number of spreading intervals per frame, codes per mini-slot, and number of active codes. Theframer uses this information to map the mini-slots of a transmission into frames. The framer maps completegrants so that any interleaving which is performed is not constrained by individual mini-slot boundaries. Theframer MUST align transmissions to begin and end on mini-slot boundaries. Within a transmission, the framernumbers the symbols or bits and allocates them to codes and spreading intervals independent of the mini-slotmapping. When using TCM encoding, the TCM encoded symbols from the TCM encoder are split into two

Mini-slotm+63

Min

i-slo

tm+

64M

ini-s

lotm

+65

Min

i-slo

tm+

127

Min

i-slo

tm+

66

Min

i-slo

tm+

69M

ini-s

lotm

+68

Min

i-slo

tm+

67

Mini-slotm+1

Mini-slotm

Mini-slotm+191

Mini-slotm+129

Mini-slotm+128

code127

code126

code3

code2

code1

code0

framef

Spreader-onframe

framef+2

Spreader-onframe

framef+1

Spreader-off frame

Kspreadingintervals 128*Kmodulationintervals Kspreadingintervals

60


subsymbols consisting of the coded subsymbol which is the two bits and the parity generated from theconvolution encoder, and the uncoded subsymbol consisting of the rest of the bits. When TCM is off, therandomizer output is treated as a continuous bit stream ignoring byte boundaries, as specified in Section 6.2.13,“Symbol Mapping,” on page 64."

6.2.12.1 Subframe Definition

The S-CDMA framer performs interleaving independently of mini-slots. Interleaving is constrained by subframeboundaries, where a subframe is a rectangular subset of an S-CDMA frame over which interleaving isperformed. A subframe is normally an integer number of Reed-Solomon codewords to enhance protection fromimpulse noise.

Given an S-CDMA frame which is N active codes by K spreading intervals, a subframe is defined to be a groupof R contiguous rows, where R is an integer in the range from 1 to N. A subframe is defined to exist entirelywithin a single frame and does not span multiple frames. Each subframe contains R*K locations and eachlocation holds one symbol used for mapping and spreading. Each transmission MUST start with a new subframe.The last subframe of a frame MUST be shortened to fit entirely within a single S-CDMA frame, and the lastsubframe of a transmission MUST be shortened to fit within the granted mini-slots. In both of these cases thesubframe will be only R' rows instead of R rows where R'≤R. Figure 6-16 shows a subframe consisting of R rowsand K spreading intervals within an S-CDMA frame.

Figure 6-16 Subframe structure

The parameters that define a subframe and the numbering within a subframe are codes per subframe andinterleaver step size. These two parameters are specified as part of the burst attributes and can vary between burstprofiles. These parameters determine the size of the subframe, and also how the subframe is filled with symbols.The valid range for codes per subframe is from 1 to the number of active codes in use. The parameter interleaverstep size is used while putting TCM coded subsymbols and preamble symbols into the frame. Both of these typesof symbols fill in subframes first along a row, and the interleaver step size parameter indicates the spreadinginterval increment to be used while filling in the symbols.

frame length(K)

Rco

des

Other subframes

Other subframes

Num

ber

ofA

ctiv

eC

odes

(N)

Row 1

Row 2

Row R

0 1 (K-1)Spreading Interval

61


6.2.12.2 Framer Operation

The symbols entering the framer MUST be placed into the framer according to the following sets of rules. Thereare two sets of rules which apply to different types of input symbols. Preamble symbols and coded TCMsubsymbols follow one set of rules, while non-TCM encoded symbols and uncoded TCM subsymbols follow thesecond set of rules. The rules are specified in the following sections.

6.2.12.2.1 Rules for Preamble and Coded TCM Symbols

The preamble (whether TCM is on or off) and the coded TCM subsymbols MUST fill in the frame according tothe following rules.

1. The first symbol or subsymbol MUST be placed in the first spreading interval of the first row of the grantedmini-slot. In Figure 6-16, “Subframe structure,” on page 61 this would be row 1, spreading interval 0assuming that this is the start of the first mini-slot of the grant.

2. Subsequent symbols MUST be placed at the next available spreading interval Interleaver Step Size awayfrom the previous. For instance if the previous symbol was placed at spreading interval X, the next symbol isplaced at X + Interleaver Step Size.

3. If the addition of the Interleaver Step Size results in the next location being beyond the end of the frame, thenext location MUST be located modulo the frame length. For instance if J + Interleaver Step Size = K+1, thenthe next location would be spreading interval 1.

4. If the next location is already occupied, then the spreading interval MUST be incremented by 1 until the nextunoccupied spreading interval is located. For instance if the desired location is spreading interval X andspreading interval X is occupied, but not X+1, then X+1 would be used.

5. After filling all of the spreading intervals of a single row, the operation is repeated starting with the next rowand step 1 above.

6. After placing all of the preamble and data symbols into the frame, the remaining symbols in the burst, asdefined by the burst boundaries of Section 6.2.5.1.1, MUST be filled with zero data symbols which will bemapped to non-zero power.1

7. Any locations that have only a TCM uncoded subsymbol MUST be filled with zero bits in the codedsubsymbol portion before mapping and spreading.

6.2.12.2.2 Rules for Uncoded Symbols and the Uncoded TCM Subsymbols

Symbols without TCM encoding and uncoded TCM subsymbols MUST fill subframes according to thefollowing rules.

1. The first symbol MUST be placed in the first available code of the first available spreading interval of thesubframe after the preamble has been placed into the frame. The symbols are filled from row 1 through row Rand after filling a spreading interval, the next spreading interval is filled from row 1 through row R.

2. Uncoded symbols and the uncoded portion of TCM symbols MUST NOT be placed in the same framelocation (spreading interval, code) as a preamble symbol. For instance if there is a preamble symbol in row X,spreading interval Y; and row (X+1), spreading interval Y is unused, the symbol should be placed into row(X+1), spreading interval Y.

1. Section 6.2.12.2.1, numbered paragraph 6 updated per RFI2-N-02135 by RKV on 10/29/02.

62


3. Subsequent symbols MUST be placed in the next available row of the first available spreading interval of thecurrent subframe. This causes the subframe to be filled column-wise bottom to top and then from left to right.For instance if row 1 through row R of spreading interval X is already occupied, the next symbol would beplaced into the first available row of spreading interval X+1.

4. After completely filling a subframe, the next subframe MUST begin as specified in step 1 above.

5. The number of rows contained in the last subframe of a frame MUST be reduced to fit entirely within theframe if there is not adequate space for a full subframe.

6. The number of rows contained in the last subframe of a grant of mini-slots, MUST be reduced to fit entirelywithin the granted mini-slots if there is not adequate space for a full subframe within the grant.

7. After placing all of the data symbols into the frame, the remaining symbols in the burst, as defined by theburst boundaries of Section 6.2.5.1.1, MUST be filled with zero data symbols which will be mapped to non-zero power.1

8. Any locations that have only a TCM coded subsymbol MUST be filled with zero bits in the uncodedsubsymbol portion before mapping and spreading.

6.2.12.2.3 Subframe Example

Figure 6-17 below shows an example which follows the above specified rules. Each box in the figure representsa symbol which can contain either a preamble symbol, an uncoded symbol when not using TCM, or an uncodedand coded subsymbol when using TCM. In this example there are 9 spreading intervals in the frame, 3 rows forthe subframe, an Interleaver Step Size of 3, and the preamble is 4 symbols. Based on these parameters thesubframe would be filled as shown. If the data is TCM encoded, the Cs would represent locations of the codedsubsymbols and the Us represent the locations of the uncoded subsymbols. If the TCM is not used, then thesymbols would be placed according to the Us only.

Figure 6-17 Symbol Numbering Without TCM

6.2.12.2.4 Frame Transmission

Once a frame is completed and ready for transmission, the symbols MUST be mapped and spread in spreadinginterval order. This means that spreading interval 0, as described in Figure 6-16, MUST be the first spreadinginterval on the wire. For TCM encoded data, the coded and uncoded subsymbols from each location in the frameMUST be combined to create complete symbols before mapping and spreading. This corresponds to creating anew symbol where the coded portion of the symbol is Ci and the uncoded portion is Uj. The preamble symbolsremain intact.

1. Section 6.2.12.2.2, numbered paragraph 7 updated per RFI2-N-02135 by RKV on 10/29/02.

U0

C5

P0

U2

C8

P3

U5

C11

U4

C2

U7

C6

P1

U10

C9

U9

C0

U13

C12

U12

C3

U15

C7

P2

U18

C10

U17

C1

step=3

frame length

3ro

ws

U1

C14U3

C17U6

C20U8

C15U11

C18U14

C21U16

C16U19

C19

U21

C13

U20

C4

U22

C22

63


6.2.13 Symbol Mapping

The modulation mode is configurable via MAC messages. Differential encoded QPSK and 16QAM are availablefor TDMA channels. QPSK, 8QAM, 16QAM, 32QAM, and 64QAM are available for TDMA and S-CDMAchannels. TCM encoded QPSK, 8QAM, 16QAM, 32QAM, 64QAM and 128QAM are available for S-CDMAchannels. The symbols transmitted in each mode and the mapping of the input bits to the I and Q constellationMUST be as defined in Table 6-3. In the table, x1 represents the LSB of each of the symbol maps and x2, x3, x4,x5, x6 and x7 represents the MSB for QPSK, 8QAM, 16QAM, 32QAM, 64QAM, and 128QAM respectively.The MSB MUST be the first bit in the serial data into the symbol mapper and it MUST be mapped to the MSB ofthe symbol map. The number of data bytes may not map into an integer number of symbols. In this case, the lastsymbol MUST be padded with zero bits in the LSB locations after all data bits are processed.

All constellations are defined on a common integer grid in Figure 6-18. This defines each QAM symbol with 5-bit values on each (I and Q) axis. The relative symbol amplitudes defined by the grid MUST be maintainedacross all constellations. Different constellations may be used, for example, in different burst profiles, inpreamble and data symbols within the same burst, and in modulating different spreading codes within a frame.

In Figure 6-18, Eav denotes the average constellation energy for equally likely symbols. For each constellationthe integer values of Eav and differences in dB compared to 64QAM, Gconst , are given. The QPSK0 constellationis employed for low-power preamble and QPSK data symbols. Use of QPSK1 is restricted to high-powerpreamble symbols.

Table 6-3 I/Q Mapping

The upstream symbol constellations MUST be as shown in Figure 6-18.

The upstream QPSK Gray-coded and differential symbol mappings MUST be as shown in Figure 6-19

The upstream 8QAM symbol mapping MUST be as shown in Figure 6-20.

The upstream 16QAM Gray-coded symbol mapping MUST be as shown in Figure 6-21.

The upstream 16QAM differential symbol mapping MUST be as shown in Figure 6-21.

The upstream 32QAM symbol mapping MUST be as shown in Figure 6-22.

The upstream 64QAM Gray-coded symbol mapping MUST be as shown in Figure 6-23.

The TCM symbol mappings used for S-CDMA are shown in Figure 6-24 through Figure 6-26.

The upstream QPSK TCM symbol mappings MUST be as shown in Figure 6-24.

The upstream 8QAM TCM symbol mapping MUST be as shown in Figure 6-24.

QAM Mode Input bit Definitions

QPSK x2x1

8QAM x3x2x1

16QAM x4x3x2x1

32QAM x5x4x3x2x1

64QAM x6x5x4x3x2x1

128QAM x7x6x5x4x3x2x1

64






If differential quadrant encoding is enabled, then the currently-transmitted symbol quadrant is derived from thepreviously transmitted symbol quadrant and the current input bits via Table 6-4. If differential quadrant encodingis enabled, the upstream PMD sublayer MUST apply these differential encoding rules to all transmitted symbols(including those that carry preamble bits). Differential quadrant encoding is only available for QPSK and16QAM on TDMA channels. In Table 6-4, I(1)Q(1) refers to x2x1 and x4x3 from Table 6-3 for QPSK and16QAM cases respectively.

Table 6-4 Definition of Differential Quadrant Coding

CurrentInput BitsI(1) Q(1)

QuadrantPhase Change

MSBs of PreviouslyTransmitted Symbol

MSBs for CurrentlyTransmitted Symbol

00 0 ° 11 11

00 0 ° 01 01

00 0 ° 00 00

00 0 ° 10 10

01 90 ° 11 01

01 90 ° 01 00

01 90 ° 00 10

01 90 ° 10 11

11 180 ° 11 00

11 180 ° 01 10

11 180 ° 00 11

11 180 ° 10 01

10 270 ° 11 10

10 270 ° 01 11

10 270 ° 00 01

10 270 ° 10 00

65


Figure 6-18 Symbol Constellations

+15

+12

+8

0

-8

-12

-15-15 -12 -8 0 +8 +12 +15

+12

+4

-4

-12

-12 -4 +4 +12

8QAM-DS: Eav = 160 (Gconst = -0.21 dB)Imaginary part

(quadrature)

Real part(in-phase)

QPSK1

QPSK0

16QAM-SQ: Eav = 160 (Gconst = -0.21 dB) 32QAM-DS: Eav = 168 (Gconst = 0 dB)

+12

+4

-4

-12

-12 -4 +4 +12

+14

+10

+6

+2

-2

-6

-10

-14

-14 -10 -6 -2 +2 +6 +10 +14

64QAM-SQ: Eav = 168 (Gconst = 0 dB)

+14

+10

+6

+2

-2

-6

-10

-14

-14 -10 -6 -2 +2 +6 +10 +14

+15+13+11+9+7+5+3+1-1-3-5-7-9

-11-13-15

-15-13-11 -9 -7 -5 -3 -1 +1 +3 +5 +7+9+11+13+15

QPSK0: Eav = 128 (Gconst = -1.18 dB rel to 64QAM)

QPSK1: Eav = 288 (Gconst = +2.34 dB)

128QAM-DS: Eav = 170 (Gconst = 0.05 dB)

66


Figure 6-19 QPSK Gray and Differential Symbol Mapping

Figure 6-20 8QAM Symbol Mapping

00 10

01 11

Label bits x2x1 (I,Q)

I

Q

Label bits x3x2x1

100 000

110 011

010 001

111 101

2

2

I

Q

2

Gray-codeviolation

67




(a) Gray-CodedMapping (I,Q,I,Q)

(b) Mapping for DifferentialEncoding

Label bits x4x3x2x1

0110 1111

0101 1100

0000 1001

0011 1010

0100 1110

0010 1000

0001 1011

0111 11010101 11110111 1101

0110 11000100 1110

0000 1010

0011 1001

0010 1000

0001 1011

Q Q

I I

Label bits x5x4x3x2x1

2

2

2

2

2

2

1101011111 10010 10111

11011 1011011101 01010

11001 0111001011 11110

11000 0111101001 00110

0110101000 00111 00010

01100 0001110000 00101

10100 0000100100 10011

10101 0000011100 10001

Q

I

2

Gray-codeviolation

68



Figure 6-24 QPSK and 8QAM TCM Symbol Mapping

Label bits x6x5x4x3x2x1 (I,Q,I,Q,I,Q)

011100 011110 010110 010100 110100 110110 111110 111100

011101 011111 010111 010101 110101 110111 111111 111101

011001 011011 010011 010001 110001 110011 111011 111001

011000 011010 010010 010000 110000 110010 111010 111000

001000 001010 000010 000000 100000 100010 101010 101000

001001 001011 000011 000001 100001 100011 101011 101001

001101 001111 000111 000101 100101 100111 101111 101101

001100 001110 000110 000100 100100 100110 101110 101100

Q

I

Binary labels x 3x2x1

100

000

110

010

001

101

011

111

Binary labels x 2x1

11

01

10

00

69


Figure 6-25 16QAM and 32QAM TCM Symbol Mapping

Figure 6-26 64QAM and 128QAM TCM Symbol Mapping

Octal labels o2o1 (= bin. lab. x5x4x3x2x1 )Octal labels o2o1 (= bin. labels x4 x3x2x1)

Subset B0 Subset B1

17 03

05 11

01 15

13 07

10 14

16 12

02 06

04 00

3123 2113

0715 3705

1725 2735

0133 1103

3426 2416

0436 1406

1220 2230

0210 3200

0135 6115

0571 2511

2155 4175

7743 5723

1327 7307

1763 3703

6551 4531

3347 5367

7054 5034

1074 3014

2440 4460

6246 4226

1632 7612

3652 5672

0266 2206

0420 6400

Subset B0 Subset B1

128QAM: octal labels o3o2o1

(= bin. lab. x7x6x5x4x3x2x1 )64QAM: octal labels o2o1

(= bin. lab. x6x5x4x3x2x1)

110172140042050132100 102

126164156074066124116 134

060022030012020162170 052

076014006004036154146 044

150032000002010072040 142

166024016034026064056 174

120062070152160122130 112

136054046144176114106 104133051043141173111103 101

125067075157165127135 117

163021013031023061053 171

155037005007015077045 147

073011003001033151143 041

065027035017025167175 057

123161153071063121113 131

115177145047055137105 107

70


6.2.14 S-CDMA Spreader

The basis of signal transmission with S-CDMA is direct-sequence spread-spectrum modulation. S-CDMAemploys a family of orthogonal digital code words, called spreading codes, to simultaneously transmit up to 128modulation symbols. In each spreading interval, a vector, Pk, is transmitted such that:

Pk = Sk*C,

where Sk is a vector, [sk,127, sk,126,..., sk,0], of modulation symbols on the integer grid of Section 6.2.13 to betransmitted in spreading interval k, and C is a matrix,

where the rows of C are the 128 spreading codes such that Code(j) = [cj,127, cj,126,..., cj,0]. The result of thespreading operation is the transmission vector Pk which has 128 elements, [pk,127, pk,126,..., pk,0], where eachelement is transmitted at the signaling rate, with element pk,0 transmitted first in time. The first element S0 intothe spreader is defined as follows. As a point of reference, for 128 allocated codes, and considering the firstcolumn of the framer (k = 0), S0 is the first symbol in time to enter the framer, occupies the lower left element ofthe framer, and is the first element into the spreader.

The set of orthogonal codes used for the spreading operation is quasi-cyclic and consists of values which areeither +1 or -1. Code(0) consists of 128 elements all of which have value of +1. For each of the other spreadingcodes Code(j), the element cj,0 is -1 and the remaining elements are obtained by a cyclic shift of a sequence x asis shown in the above matrix in this section.

The sequence xi is defined such that the elements corresponding to the following set of indices are equal to -1:

{2 3 4 5 6 7 9 10 11 13 16 17 18 19 20 21 25 26 28 30 31 33 34 35 37 39 40 41 49 51 52 55 56 59 60 61 65 66 6769 72 73 74 77 78 79 81 84 90 92 94 97 100 101 103 106 109 110 111 114 117 119 121};

The remaining elements of Code(1) have a value of +1.

Each Code(j) is obtained by cyclic shift to the left (in the direction of increasing indices) of Code(j-1) where theelement, cj,0, has a value of -1 and does not take part in the cyclic shift.

Although each code is defined to have equal power, the spread symbols may have slightly unequal power sincethe symbols at the input to the spreader have varying values of Eav according to the integer symbol grid ofSection 6.2.13.

If a CM has not been assigned to use a particular code, j, at a spreading time interval, k, then in its computation ofits transmission vector Pk, it will set sk,j to numerical zero. The assignment of codes to the CM is performed bythe framer as it assigns a burst of symbols a particular order in the two-dimensional space of codes and time. Thissymbol sequencing is described in detail in Section 6.2.12.

The I and Q components of the symbols are spread using the same spreading code.

It is also important to note that in the matrix multiply of the equation above and subsequent CM processing priorto the D/A, there is an essential clipping operation wherein --- as an example --- filtered (pulse shaped) elements

C

c127 127, c127 126, … c127 0,

c126 127, c126 126, … c126 0,

… … … …c0 127, c0 126, … c0 0,

x1 x127 … x2 1–

x2 x1 … x3 1–

… … … … 1–

x127 x126 … x1 1–

1 1 1 1 1

= =

71


of Pk in excess of some vendor-specific absolute value are clipped (retaining complex angle) to this absolutevalue. This nonlinear operation, deviating from the equation above and the subsequent linear processing prior tothe D/A, is essential for meeting spurious emission and MER requirements safely and efficiently while operatingat the highest CM average transmit power levels (see Table 6-8, “User Unique Burst Parameters,” on page 81).

6.2.14.1 Code Hopping

Code hopping refers to a systematic re-ordering of the rows of the spreading matrix, C, at each spreadinginterval, k. The code-hopping algorithm uses a pseudo-random number, lfsr_out(k), to determine a cyclic shift ofthe rows of the matrix C. When the number of active codes equals 128, the code hopping algorithm uses allcodes. When the number of active codes is less than 128, the code hopping algorithm hops only over the cycliccodes (Code(0), the all 1s code, is excluded). The generalization of the spreading matrix at spreading interval, k,is given by (where matrix elements, cj,i are as defined above in Section 6.2.14):

where,

In S-CDMA mode, the CM MUST support code-hopping.

Note that when the number of active codes is less than 128, the unused codes are those starting with matrixindex 0. In this case, the code hopping continues to “hop” over all of the codes except for Code(0), even if thenumber of active codes is less than 127.

The pseudo-random number generator which determines the spreading matrix reordering is the linear-feedbackshift register (LFSR) which is shown in Figure 6-27. In order to align the CM's code-hopping pseudo-randomsequence with that at the CMTS, the pseudo random generator must output the following value at the firstspreading interval of each frame:

lfsr_out(frame_number * spreading_interval_per_frame)

where lfsr_out(k) is the value of lfsr_out after k shifts following the code hopping seed load into the LFSR.1

(The description of the frame counter and the procedures for its synchronization are contained in Section6.2.11.2, “Mini-slot Numbering” on page 54). At this reset, a 15-bit initialization value (seed) is loaded into theshift register and is used at the first spreading interval. Then at each subsequent spreading interval, k, a new bit isshifted into the LFSR producing a new 7-bit value, lfsr_out(k). This value is used, with bit 7 as the MSB, tocompute the spreading matrix indices as given by the equation above. Note that the code hopping mechanism(LFSR, spreading interval index) is advanced every spreading interval (128 modulation intervals) in bothspreader-on and spreader-off frames.

1. Text from “In order to align” to this footnote, updated per RFI2-N-02123 by RKV on 10/29/02.

Ck

cf k 127,( ) 127, cf k 127,( ) 126, … cf k 127,( ) 0,

cf k 126,( ) 127, cf k 126,( ) 126, … cf k 126,( ) 0,

… … … …cf k 0,( ) 127, cf k 0,( ) 126, … cf k 0,( ) 0,

=

≤≤≤≤

<++−+−

=1271

1270

1281)127),)(_126((mod

128),128),)(_128((mod),(

i

i

CodesActiveikoutlfsrulo

CodesActiveikoutlfsruloikf

72


Figure 6-27 Code Hopping Random Number Generator

The 15-bit seed value is configured in response to the Upstream Channel Descriptor message from the CMTS.

6.2.15 Transmit Pre-Equalizer

A transmit pre-equalizer of a linear equalizer structure, as shown in Figure 6-28, MUST be configured by theCM in response to the Ranging Response (RNG-RSP) message transmitted by the CMTS.

There are two modes of operation for the pre-equalizer of a CM: DOCISIS 1.1 mode, and DOCSIS 2.0 mode. InDOCSIS 1.1 mode, the CM MUST support a (T)-spaced equalizer structure with 8 taps; the pre-equalizer MAYhave 1, 2 or 4 samples per symbol, with a tap length longer than 8 symbols. In DOCSIS 1.1 mode, for backwardscompatibility, the CMTS MAY support fractionally spaced equalizer format (T/2 and T/4). In DOCSIS 2.0 mode,the pre-equalizer MUST support a symbol (T)-spaced equalizer structure with 24 taps.

In DOCSIS 1.x-only logical channels the CM and the CMTS MUST use DOCSIS 1.1 mode.

In DOCSIS 2.0-only logical channels the CM and the CMTS MUST use DOCSIS 2.0 mode.

In DOCSIS 1.x/2.0 mixed logical channels the CM and the CMTS MUST use DOCSIS 1.1 mode from initialranging until DOCSIS 2.0 is activated in the registration process (if it is activated), and MUST use DOCSIS 2.0mode after DOCSIS 2.0 is activated.

Figure 6-28 Transmit Pre-Equalizer Structure

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

modulo(128) ormodulo(127) +1

Random Offset7

Initialization value (seed)

lfsr_out

R = T, T/2, T/4

F3

Z-R

F4

Z-R

F5

Z-R

F6F2

Z-R

F1

Z-R Z-R

FN

I-QInput

I-QOutput

Z-1

I-QInput

Z-1 Z-1 Z-1...

F1 F2 F3 F4 F17

Z-1 Z-1...

F18 F24

... ...EqualizerOutput

73


The RNG-RSP MAC message carries the CM transmit equalization information, and may instruct the CM toeither convolve the equalizer coefficients or (in DOCSIS 2.0 mode only) load them directly (refer toSection 8.3.6.1, “Encodings,” on page 146). When the CM is instructed to convolve the transmit equalizercoefficients, it MUST convolve the coefficients sent by the CMTS in the RNG-RSP with the existing coefficientsto get the new coefficients. After convolving, the CM MUST truncate the convolution result such that 24 taps (8taps in DOCSIS 1.1 mode) remain after the truncation, with the main tap located at the tap designated by the lastRNG-RSP received by the CM. The operation of the convolution is formulized by the following equation:

When the CM is instructed to load the transmit equalizer coefficients it MUST load the coefficients sent by theCMTS into the pre-equalizer coefficients after proper normalization, if necessary.

In DOCSIS 1.x-only channels, in response to an initial ranging request and periodic ranging requests prior to CMregistration, when the CMTS sends the pre-equalizer coefficients, the CMTS MUST compute and send themwith an equalizer length of 8 and in T-spaced format, where T is the modulation interval. After registration, theCMTS MAY use a fractionally spaced equalizer format (T/2- or T/4-spaced) with a longer tap length to matchthe CM pre-equalizer capabilities that the CMTS learned from the REG-REQ message modem capabilities field.See Section 8.3.8.1.1, “Modem Capabilities,” on page 153 for proper use of the modem capabilities field.

In DOCSIS 2.0-only channels, the CMTS MUST compute and send the pre-equalizer coefficients with anequalizer length of 24 and in T-spaced format at all times.

In DOCSIS 1.x/2.0 mixed logical channels, in response to an initial ranging request and periodic rangingrequests prior to CM registration, when the CMTS sends the pre-equalizer coefficients, the CMTS MUSTcompute and send them with an equalizer length of 8 and in T-spaced format. After registration, if the DOCSIS1.1 mode is activated, the CMTS MAY use a fractionally spaced equalizer format (T/2- or T/4-spaced) with alonger tap length to match the CM pre-equalizer capabilities that the CMTS learned from the REG-REQ messagemodem capabilities field. If DOCSIS 2.0 is activated, the CMTS MUST use a T-spaced equalizer structure with24 taps. If the first update of the pre-equalizer after the activation of DOCSIS 2.0 uses “convolve” mode, the CMMUST zero-pad the existing 8-tap filter to a 24-tap filter, and then convolve according to the rules above.

Prior to making an initial ranging request and whenever the upstream channel frequency or upstream channelmodulation rate changes, the CM MUST initialize the coefficients of the pre-equalizer to a default setting inwhich all coefficients are zero except the real coefficient of the first tap (i.e., F1). Whenever the main location ischanged, the CM, not the CMTS, MUST compensate for the delay (ranging offset) due to a shift from theprevious main tap location to a new main tap location of the equalizer coefficients sent by the CMTS (in both“convolve” and “load” operations). The pre-equalizer coefficients are then updated through the subsequentranging process (unicast initial ranging and periodic ranging).

In DOCSIS 1.1 mode, the CMTS MUST NOT move the main tap location during periodic ranging.

Fnm 1+ F

n k– Lm

Lm 1+–+

m F̂k L

m 1++ , n=1...24⋅

k max 1 Lm 1+

n Lm

Lm 1+– 24–+,–( )=

min 24 Lm 1+

n Lm

Lm 1+– 1–+,–( )

∑=

where:

Fnm

are the coefficients prior to the convolution

Fnm 1+

are the coefficients after the convolution

F̂n are the coefficients sent from the CMTS

Lm is the main tap location prior to the convolution

Lm 1+

is the main tap location after the convolution as dictated by the CMTS

74


In DOCSIS 1.1 mode, the CMTS MUST NOT instruct the CM to load the transmit equalizer coefficients.

In DOCSIS 2.0 mode, the CMTS MAY move the main tap location during unicast initial ranging or periodicranging.

Equalizer coefficients may be included in every RNG-RSP message, but typically they only occur when theCMTS determines the channel response has significantly changed. The frequency of equalizer coefficientupdates in the RNG-RSP message is determined by the CMTS.

The CM MUST normalize the transmit equalizer coefficients in order to guarantee proper operation (such as notto overflow or clip). The CM MUST NOT change its target transmit power due to gain or loss of the newcoefficients in both “convolve” and “load” operations. The target power is defined in Section 6.2.18, “TransmitPower Requirements,” on page 76.

In DOCSIS 1.1 mode, if the CM equalizer structure implements the same number of coefficients as assigned inthe RNG-RSP message, then the CM MUST NOT change the location of the main tap in the RNG-RSP message.If the CM equalizer structure implements a different number of coefficients than defined in the RNG-RSPmessage, the CM MAY shift the location of the main tap value. Again, in doing so, the CM MUST adjust itsranging offset, in addition to any adjustment in the RNG-RSP message, by an amount that compensates for themovement of the main tap location.

6.2.16 Spectral Shaping

The upstream transmitter MUST approximate a Nyquist square-root raised-cosine pulse-shaping filter with roll-off factor alpha =0.25. The -30dB transmitted bandwidth MUST NOT exceed the Channel Width values in Table6-5. The Channel Width values are given analytically by

ChannelWidth = ModulationRate*(1+alpha).

Table 6-5 Maximum Channel Width

6.2.16.1 Upstream Frequency Agility and Range

The upstream PMD sublayer MUST support operation over the frequency range of 5-42 MHz edge to edge.

Offset frequency commands MUST be supported per Table 6-8.1

Modulation Rate (kHz) Channel Width (kHz)

160 200

320 400

640 800

1,280 1,600

2,560 3,200

5,120 6,400

1. Section 6.2.16.1, second paragraph updated per RFI2-N-02104 by RKV on 10/28/02.

75


6.2.16.2 Spectrum Format

The upstream modulator MUST provide operation with the format s(t) = I(t)*cos(ωt) - Q(t)*sin(ωt), where tdenotes time and ω denotes angular frequency.

6.2.17 Relative Processing Delays

The CM MAP processing delay is the time provided between arrival of the last bit of a MAP message at a CMand the effectiveness of this MAP. During this time, the CM should process the MAP message and fill itsinterleavers (or its framer, in S-CDMA mode) with encoded data. The CMTS MUST transmit the MAP messageearly enough to allow the CM MAP processing delay specified below.

The CM MAP processing delay, Dp, is given by the equations:

where M is the number of elements in the CM interleavers (in the case of TDMA), or framer (in the case ofS-CDMA). In DOCSIS 1.x mode, M = 0. Note that in the above equations, the values for Br and Ir*Nr are takento be the maximum from all of the specified burst types in a particular UCD.

In S-CDMA mode, M = 128(K+1), where K is the number of spreading intervals per frame. This is the timerequired for processing an S-CDMA frame plus an extra spreading interval. For example in the case of K = 32,which corresponds to the maximum framer size, the CM MAP processing time is 1025 µsec, assuming amodulation rate of 5.12 MHz.

Notes:

1. The CM MAP processing delay does not include downstream FEC de-interleaving delay.

2. The “effectiveness of the MAP” relates to the beginning of the burst frame at the RF output of the CM. In theS-CDMA mode, “effectiveness of the MAP” relates to the beginning (at the RF output of the CM) of the firstspreading interval of the S-CDMA frame which contains the burst.

6.2.18 Transmit Power Requirements

The CM MUST support varying the amount of transmit power. Requirements are presented for 1) range ofreported transmit power, 2) step size of power commands, 3) step size accuracy (actual change in output powercompared to commanded change), and 4) absolute accuracy of CM output power. The protocol by which poweradjustments are performed is defined in Section 11.2.4. Such adjustments by the CM MUST be within the rangesof tolerances described below. A CM MUST confirm that the transmit power limits are met after a RNG-RSP isreceived or after a UCD change.

0,

0,

sec,12.5

200

=

≠=

+=

rr

rrr

p

IB

INI

M

MD µ

76


Transmit power is defined as the average RF power in the occupied bandwidth (channel width) transmitted in thedata symbols of a burst, assuming equally likely QAM symbols, measured at the F-connector of the CM.Maximum and minimum transmit power level requirements refer to the CM’s target transmit power level,defined as the CM’s estimate of its actual transmit power. The actual transmitted power MUST be within ±2 dBof the target power. The target transmit power MUST be variable over the range specified in Table 6-8.

Transmit power as reported by the CM in the MIB is referenced to the 64QAM constellation. When transmittingwith other constellations, a slightly different transmit power will result, depending on the constellation gain inTable 6-6 (see Section 6.2.13). As an example, if the reported power is 30 dBmV, 64QAM will be transmittedwith a target power of 30 dBmV, while QPSK will be transmitted with 28.82 dBmV.

The actual transmitted power within a burst MUST be constant to within 0.1 dB peak to peak. This excludes theamplitude variation theoretically present due to QAM amplitude modulation, pulse shaping, pre-equalization,and for S-CDMA, spreading and varying number of allocated codes.

6.2.18.1 TDMA Transmit Power Calculations

In TDMA mode, the CM determines its target transmit power Pt as follows. Define:

Pr = Reported power level (dBmV) of CM in MIB (refers to 64QAM constellation)∆P = Power level adjustment (dB); for example, as commanded in ranging response messageGconst = Constellation gain (dB) relative to 64QAM constellation (see above table)Pmin = Minimum target transmit power permitted for the CM per Section 6.2.21.1 (see above table)Pmax = Maximum target transmit power permitted for the CM per Section 6.2.21.1 (see above table)Phi = min(Pmax - Gconst) over all burst profiles used by the CM (see above table)Plow = max(Pmin - Gconst) over all burst profiles used by the CM (see above table)Pt = Target transmit power level (dBmV) of CM (actual transmitted power as estimated by CM)

The CM updates its reported power by the following steps:

(1) Pr = Pr + ∆P //Add power level adjustment to reported power level(2) Pr = min[Pr , Phi] //Clip at max power limit(3) Pr = max[Pr , Plow] //Clip at min power limit

The CM then transmits with target power Pt = Pr + Gconst , i.e., the reported power plus the constellation gain.

Usually the reported power level is a relatively constant quantity, while the transmitted power level variesdynamically as different burst profiles, with different constellation gains, are transmitted. A CM’s target transmitpower MUST never be below Pmin or above Pmax . This implies that in some cases the extreme transmit powerlevels (e.g., 58 dBmV for QPSK and 8 dBmV) may not be permitted if burst profiles with multiple constellations

Table 6-6 Constellation Gains and Power Limits

Constellation

ConstellationGain GconstRelative to

64QAM (dB)

Pmin(dBmV)

Pmax(dBmV)TDMA

Pmax(dBmV)S-CDMA

Pmin -Gconst

(dBmV)

Pmax -Gconst

(dBmV)TDMA

Pmax -Gconst

(dBmV)S-CDMA

QPSK -1.18 8 58 53 9.18 59.18 54.18

8QAM -0.21 8 55 53 8.21 55.21 53.21

16QAM -0.21 8 55 53 8.21 55.21 53.21

32QAM 0.00 8 54 53 8.00 54.00 53.00

64QAM 0.00 8 54 53 8.00 54.00 53.00

128QAM 0.05 8 N/A 53 7.95 N/A 52.95

77


are active. Also, if only QPSK is used, the reported power may be greater than 58 dBmV, although the targettransmit power will not exceed 58 dBmV.

For example, if only QPSK and 64QAM burst profiles are active, Phi = 54 dBmV and Plow = 9.2 dBmV. Themaximum permitted QPSK transmitted power is 54 - 1.2 = 52.8 dBmV, the minimum QPSK power is 9.2 - 1.2 =8 dBmV, the maximum 64QAM power is 54 dBmV, and the minimum 64QAM power is 9.2 dBmV.

6.2.18.2 S-CDMA Transmit Power Calculations

In S-CDMA mode, the CM determines its target transmit power Pt as follows. Define:

Pr = reported power level (dBmV) of CM in MIB (refers to 64QAM constellation and all active codestransmitted)Phi = min[Pmax - Gconst] over all burst profiles used by the CM (see above table)Plow = max[Pmin - Gconst] + 10 log(number_active_codes / number_of_codes_per_mini-slot) where themaximum is over all burst profiles used by the CM (see above table)



In a spreader-on frame, the CM then transmits each code i with target power

Pt,i = Pr + Gconst,i - 10 log(number_active_codes)

i.e., the reported power plus the constellation gain Gconst,i of that code, less a factor taking into account thenumber of active codes. The total transmit power Pt in a frame is the sum of the individual transmit powers Pt,i ofeach code, where the sum is performed using absolute power quantities (non-dB domain).

In a spreader-off frame, the CM target transmit power is Pt = Pr + Gconst .

The transmitted power level varies dynamically as the number of allocated codes varies, and as different burstprofiles, with different constellation gains, are transmitted. A CM’s target transmit power MUST never be belowPmin or above Pmax , including over all numbers of allocated codes and all burst profiles. This implies that insome cases the extreme transmit power levels (e.g., 8 and 53 dBmV) may not be permitted. Also if, for example,only QPSK is used, the reported power may be greater than 53 dBmV, although the target transmit power will notexceed 53 dBmV.

If, for example, QPSK and 64QAM burst profiles are active, the number of active codes is 128 and the number ofcodes per mini-slot is 2, then Phi = 53 dBmV and Plow = 27.24 dBmV. The maximum permitted QPSKtransmitted power is 53 – 1.18 = 51.82 dBmV when all active codes are transmitted. The minimum QPSK poweris 27.24 – 1.18 – 10log(128) + 10log(2) = 8 dBmV, when one mini-slot is transmitted. The last term in the sum isthe result of summing the individual powers over 2 codes. Similarly, the maximum 64QAM power is 53 dBmVwhen all active codes are transmitted and the minimum 64QAM power is 27.24 – 10log(128) + 10log(2) = 9.18dBmV when one mini-slot is transmitted. The minimum QPSK power permitted while transmitting, for example,2 minislots is 11 dBmV, and the minimum 64QAM power permitted while transmitting 2 minislots is 12.2dBmV.1

1. First two sentences of this paragraph updated per RFI2-N-02105 by RKV on 10/28/02.

78


The CM needs to implement some form of clipping on the transmitted waveform at the higher output powers inorder to prevent peak to average ratio (PAR) issues.

The power received at the CMTS in a spreader-on frame will sometimes be less than the nominal power of aspreader-off frame because of such factors as 1) broadcast opportunities not used by any CM, 2) unicast grantsnot used by one or more CMs, or 3) mini-slots assigned to the NULL SID.

6.2.18.3 Transmit Power Step Size

The step resolution in transmit power MUST be 1dB or less. When a CM is commanded with finer resolutionthan it can implement, it MUST round to the nearest supported step size. If the commanded step is half waybetween two supported step sizes, the CM MUST choose the smaller step. For example, with a supported stepresolution of 1 dB, a command to step ±0.5 dB would result in no step, while a command to step ±0.75 dB wouldresult in a ±1 dB step.

The step size accuracy MUST be within ±0.4 dB. For example, the actual power increase resulting from acommand to increase the power level by 1 dB in a CM's next transmitted burst MUST be between 0.6 dB and1.4 dB.

A relaxation in step size accuracy to ±1.4 dB is allowed for one gain change when changing the powerthroughout the full power control range in either direction (from low-end to high-end power and vice versa). Thelocations of these two gain changes with relaxed accuracy MUST be at least 2 dB apart, thus enabling the use oflarge step attenuators in the coverage of the full power control range (hysteresis effect).

6.2.19 Burst Profiles

The transmission characteristics are separated into three portions: a) Channel Parameters, b) Burst ProfileAttributes, and c) User Unique Parameters. The Channel Parameters include i) the modulation rate (six ratesfrom 160 ksym/sec to 5.12 Msym/sec in octave steps), ii) the center frequency (Hz), iii) the 1536-bit PreambleSuperstring, and iv) the S-CDMA channel parameters. The Channel Parameters are further described in Section8.3.3 Table 8-18; these characteristics are shared by all users on a given channel. The Burst Profile Attributes arelisted in Table 6-7, and are further described in Section 8.3.3 Table 8-19; these parameters are the sharedattributes corresponding to a burst type.

The CM MUST generate each burst at the appropriate time as conveyed in the mini-slot grants provided by theCMTS MAPs (Section 8.3.4).

79


The CM MUST support all burst profiles commanded by the CMTS via the Burst Descriptors in the UCD(Section 8.3.3), and subsequently assigned for transmission in a MAP (Section 8.3.4).1 2 3

Table 6-7 Burst Profile Attributes

Burst Profile Attributes Configuration Settings

Modulation QPSK, 8 QAM, 16 QAM, 32 QAM, 64QAM, 128 QAM(TCM Only)

Differential Encoding On/Off

TCM Encoding On/Off

Preamble Length 0-1536 bits (Note Section 6.2.9)

Preamble Value offset 0 to 1534

R-S FEC Error Correction (T) 0 to 16 (0 implies no R-S FEC. Thenumber of codeword parity bytes is 2*T)

R-S FEC Codeword Information Bytes (k) Fixed: 16 to 253 (assuming R-S FEC on)Shortened: 16 to 253 (assuming R-S FECon)

Scrambler Seed 15 bits

Maximum Burst Length (mini-slots)1

1. A burst length of 0 mini-slots in the Channel Profile means that the burst length is vari-able on that channel for that burst type. The burst length, while not fixed, is grantedexplicitly by the CMTS to the CM in the MAP.

0 to 255

Guard Time 4 to 255 modulation intervals

There is no guard time in S-CDMA

Last Codeword Length Fixed, shortened

Scrambler On/Off On/Off

Byte Interleaver Depth (Ir)2

2. If depth=1, no interleaving; if depth=0, dynamic mode.

0 to floor(2048/Nr)3

3. Nr is the R-S codeword size k+2T as defined in Section 6.2.6.1.

Byte Interleaver Block Size (Br)4

4. Used only in dynamic mode

2*Nr to 2048

Preamble Type QPSK0/QPSK1

S-CDMA Spreader5

5. Used only for S-CDMA channels.

On/Off

S-CDMA Codes per Subframe5 1 to 128

S-CDMA Interleaver Step5 1 to (spreading intervals per frame - 1)

1. Range changed from 5 - 255 to 4 - 255 per RFI2-N-02085 by RKV on 10/28/02.2. “1 for S-CDMA channels” changed to “There is no guard time in S-CDMA”

per RFI2-N-02210, by GO, on 11/22/02.3. Added row text per ECN RFI2-N-02210, by GO, on 11/21/02.

80


The User Unique Parameters may vary for each user even when using the same burst type on the same channel asanother user (for example, Power Level), and are listed in Table 6-8:1

The CM MUST implement the Offset Frequency Adjustment to effect a change in upstream carrier frequencywithin ±10 Hz of the commanded change.2

6.2.19.1 Ranging Offset

Ranging Offset is the time difference between the CM upstream frame time base and the CMTS upstream frametime base. It is an advancement equal to roughly the round-trip delay between the CM and the CMTS, and isneeded to synchronize upstream transmissions in the TDMA and S-CDMA schemes. The CMTS MUST providethe CM with feedback adjustments of this offset, based on reception of one or more successfully received bursts(i.e., satisfactory result from each technique employed: error correction and/or CRC). The CMTS sends theseTiming Adjust commands to the CM in the Ranging Response MAC message (see Section 8.3.6), where anegative value implies the Ranging Offset is to be decreased, resulting in later times of transmission at the CM.

For TDMA channels the CM MUST implement the Timing Adjust command with resolution of at most 1 symbolduration (of the symbol rate in use for a given burst), and (other than a fixed bias) with accuracy within ±0.25

Table 6-8 User Unique Burst Parameters

User Unique Parameter Adjustment Command Resulting Parameter Value

Power Level 8-bit two's complement,resolution = 0.25 dB

TDMA:+8 to +54 dBmV (32QAM, 64QAM)+8 to +55 dBmV (8QAM, 16QAM)+8 to +58 dBmV (QPSK)S-CDMA: +8 to +53 dBmV(all modulations)

Resolution = 1 dB or better

Offset Frequency Range = ±32 kHz, resolution = 1 Hz Frequency Range per Section6.2.16.1 Upstream Frequency Agilityand Range, on page 75

Ranging Offset Integer part: 32-bit two'scomplement, resolution = (1 / 10.24MHz) = 6.25 µsec/64 = 97.65625 ns

Fractional part: unsigned 8-bitfractional extension, resolution = 6.25µsec/(64*256) = 0.3814697265625nsec

Range: sufficient for maximum cableplant length per Section 4.1,Broadband Access Network,on page 23

Resolution: TDMA: 6.25 µsec/64.S-CDMA: 6.25 µsec/(64*256)

Burst Length (mini-slots) if variableon this channel (changes burst-to-burst)

N/A 1 to 255 mini-slots

Transmit Equalizer Coefficients

(See Section 6.2.15, Transmit Pre-Equalizer, on page 73)

DOCSIS 2.0 mode: 24 complexcoefficients, 4 bytes per coefficient(2 real and 2 imaginary), load andconvolve modes

DOCSIS 1.1 mode: up to 64complex coefficients, 4 bytes percoefficient (2 real and 2 imaginary),convolve mode only

DOCSIS 2.0 mode: 24 complexcoefficients

DOCSIS 1.1 mode: up to 64complex coefficients

1. Table 6-8 replaced per RFI2-N-02104 by RKV on 10/28/02.2. Section 6.2.19, last paragraph updated per RFI2-N-02104 by RKV on 10/28/02.

81


µsec plus ±1/2 symbol owing to resolution. As an example, for the maximum symbol rate of 5.12 Msps, thecorresponding symbol period would be 195 ns, the corresponding maximum resolution for the Timing AdjustMUST be 195 ns, and the corresponding minimum accuracy MUST be ±348 ns. The accuracy of CM bursttiming of ±0.25 µsec plus ±1/2 symbol is relative to the mini-slot boundaries derivable at the CM based on anideal processing of the timestamp signals received from the CMTS.

The resolution of the integer part of the Timing Adjust parameter, which is used for TDMA channels, is (1 /10.24 MHz) = 6.25 µsec/64 ~= 97.66 ns. For S-CDMA channels the CMTS provides an additional fractionalfield in the Timing Adjust command, with resolution of 1/16384 of the frame tick increment = (6.25 µsec/(64*256) ~= 0.3814 nsec. For S-CDMA channels, the CM MUST implement the Timing Adjust to within ±0.01of the nominal chip period. As an example, for the maximum chip rate of 5.12 Mcps, the correspondingmaximum resolution for implementation of the timing correction would be (±0.01)*195 ns or roughly ±2 ns.1

6.2.19.2 TDMA Reconfiguration Times

The CM MUST be capable of switching burst profiles with no reconfiguration time required between burstsexcept for changes in the following parameters: 1) Output Power, 2) Symbol Rate, 3) Offset frequency, 4)Channel Frequency, and 5) Ranging Offset.

For output power changes: If Output Power is to be changed by 1 dB or less, the CM MUST be able toimplement the change between bursts as long as the CMTS allocates at least 96 symbols plus 5 µsec between thelast symbol center of one burst and the first symbol center of the following burst. If Output Power is to bechanged by more than 1 dB, the CM MUST be able to implement the change between bursts as long as theCMTS allocates at least 96 symbols plus 10 µsec between the last symbol center of one burst and the first symbolcenter of the following burst. The maximum reconfiguration time of 96 symbols should compensate for the rampdown time of one burst and the ramp up time of the next burst as well as the overall transmitter delay timeincluding the pipeline delay and optional pre-equalizer delay. The Output Power of the CM MUST be settled towithin ± 0.1 dB of its final output power level a) within 5 µsec from the beginning of a change of 1 dB or less,and b) within 10 µsec from the beginning of a change of greater than 1 dB. Output Power MUST NOT bechanged until the CM is provided sufficient time between bursts by the CMTS, and MUST NOT change whilemore than -30 dB of any symbol’s energy of the previous burst remains to be transmitted, or more than -30 dB ofany symbol’s energy of the next burst has been transmitted.

For Symbol Rate changes, the CM MUST be able to transmit consecutive bursts as long as the CMTS allows therequired time between bursts for UCD parameter changes (see Section 11.3.2, “Changing Upstream ChannelDescriptor Message Parameters,” on page 253). Symbol Rate MUST NOT be changed until the CM is providedsufficient time between bursts by the CMTS, and MUST NOT change while more than -30 dB of any symbol’senergy of the previous burst remains to be transmitted, or more than -30 dB of any symbol’s energy of the nextburst has been transmitted.

For Offset Frequency changes, the CM MUST be able to transmit consecutive bursts as long as the CMTSallocates at least 96 symbols in between the last symbol center of one burst and the first symbol center of thefollowing burst. The maximum reconfiguration time of 96 symbols should compensate for the ramp down timeof one burst and the ramp up time of the next burst as well as the overall transmitter delay time including thepipeline delay and optional pre-equalizer delay. Offset frequency MUST NOT be changed until the CM isprovided sufficient time between bursts by the CMTS, and MUST NOT change while more than -30 dB of anysymbol’s energy of the previous burst remains to be transmitted, or more than -30 dB of any symbol’s energy ofthe next burst has been transmitted.

1. Section 6.2.19.1, all three paragraphs replaced per RFI2-N-02104 by RKV on 10/29/02.

82


For Channel Frequency changes, then the CM MUST be able to implement the change between bursts as long asthe CMTS allocates at least 96 symbols plus 100 msec between the last symbol center of one burst and the firstsymbol of the following burst. The Channel Frequency of the CM MUST be settled within the phase noise andaccuracy requirements of Section 6.2.21.5 and Section 6.2.21.6 within 100 msec from the beginning of thechange. Channel Frequency MUST NOT be changed until the CM is provided sufficient time between bursts bythe CMTS, and MUST NOT change while more than -30 dB of any symbol’s energy of the previous burstremains to be transmitted, or more than -30 dB of any symbol’s energy of the next burst has been transmitted.

For Ranging Offset changes, the CM MUST be able to transmit consecutive bursts as long as the CMTS allocatesat least 96 symbols in between the last symbol center of one burst and the first symbol center of the followingburst. The maximum reconfiguration time of 96 symbols should compensate for the ramp down time of one burstand the ramp up time of the next burst as well as the overall transmitter delay time including the pipeline delayand optional pre-equalizer delay. Ranging Offset MUST NOT be changed until the CM is provided sufficienttime between bursts by the CMTS, and MUST NOT change while more than -30 dB of any symbol’s energy ofthe previous burst remains to be transmitted, or more than -30 dB of any symbol’s energy of the next burst hasbeen transmitted.

For modulation type changes, the CM MUST be able to transmit consecutive bursts with no reconfiguration timebetween them (except for the minimum guard time). The modulation MUST NOT change while more than -30dB of any symbol’s energy of the previous burst remains to be transmitted, or more than -30 dB of any symbol’senergy of the next burst has been transmitted, EXCLUDING the effect of the transmit equalizer (if present in theCM). [This is to be verified with the transmit equalizer providing no filtering; delay only, if that. Note that if theCMTS has decision feedback in its equalizer, it may need to provide more than the 96 symbol gap between burstsof different modulation type which the same CM may use; this is a CMTS decision.]

6.2.19.3 S-CDMA Reconfiguration Times

In S-CDMA mode, for changes in Output Power per mini-slot, Offset Frequency, Pre-equalizer coefficients, and/or Ranging Offset, the CM MUST be able to transmit consecutive bursts as long as the CMTS allocates the timeduration of at least one frame in between the bursts. For all other burst profile parameter changes, noreconfiguration is required beyond what is provided by the MAC for such changes.

6.2.19.4 CM Timing Offsets When Changing Modulation Rate

When making a modulation rate change the CM MUST employ the following timing offsets when changingmodulation rates. The offsets in the table correspond to the contribution of DOCSIS 1.0 and 1.1 legacy upstreamreceivers to changes in latency when making modulation rate changes. These offsets are maintained intoDOCSIS 2.0 but with the addition of including in the table the highest modulation rate. The timing offset toapply is the difference between the entry in the table corresponding to the new modulation rate and the entrycorresponding to the original modulation rate. The offsets are referenced to the center of the first symbol in theburst, which is the reference point for burst timing as stated in Section 6.2.20. Specification of these offsets isneeded so that CMs apply uniform adjustments to their ranging offsets and so that CMTSs can appropriatelyhandle CMs that apply these offsets when making modulation rate changes.

Modulation RateTiming Offset (in units of 1/64 time ticksreferenced to 5.12 MHz)

5.12 MHz 0 (reference)

2.56 MHz 0

1.28 MHz 24

0.64 MHz 72

0.32 MHz 168

0.16 MHz 360

83


As an example, suppose a CM is on an upstream channel operating at a modulation rate of 1.28 MHz. Now,suppose the UCD message from the CMTS changes the modulation rate of the channel to 0.32 MHz. The CMapplies an additional timing offset of 168 – 24 = 144 to its ranging offset to compensate for this modulation ratechange. The value of 144 is positive, and thus, the CM will add to its ranging offset so that it effectivelytransmits earlier by 144 units of 1/64 time ticks.

Furthermore, in changing modulation rates, if a CM has its own contribution to a change in latency, the CMMUST also compensate for this CM-specific latency difference. This is in addition to the offset applied from thevalues in the table above, which result from legacy CMTS upstream receiver contributions to changes in latency.The requirements for CM burst timing accuracy found earlier in this section, referenced to the modulation ratethat is the lower of the original and the new modulation rate, apply after the modulation rate change with therequired timing offsets above considered.

A CMTS that does not apply the same internal physical delay offsets as the legacy DOCSIS upstream CMTSreceiver implementation is capable of receiving a CM burst after a modulation rate change in any of thefollowing ways but is not limited necessarily to only these ways:

a) The CMTS may implement the internal physical delay offset, as specified in the above table.

b) The CMTS may implement an internal timing compensation based on the expected offset in the above table.

c) The CMTS may increase the guard time.

d) The CMTS may send an unsolicited RNG-RSP to each CM to adjust the delay offset. As discussed inSection 6.3.6, the CM is expected to be capable of adjusting its timing offset at any time with the accuracyspecified within this section.1

6.2.20 Burst Timing Convention

Figure 6-29 illustrates the nominal burst timing for TDMA channels.

1. Section 6.2.19.4 added per RFI2-N-02178 by RKV on 10/30/02.

84


Figure 6-29 Nominal TDMA Burst Timing

Figure 6-30 indicates worst-case burst timing for a TDMA channel. In this example, burst N arrives 1.5 symbolslate, and burst N+1 arrives 1.5 symbols early, but separation of 5 symbols is maintained; 8-symbol guardbandshown.

PreambleFirst

Symbol

B) Timing is referencedto the symbol centerof the first symbolof each burst

Ramp Up

PreambleLast

Symbol

Data FirstSymbol

Last FECParity Symbol

Ramp down

Center of PreambleFirst Symbol = Minislot Boundary

MinislotBoundary

PreambleFirst Symbol

Note: Ramp down of one burst canoverlap ramp up of following burst even with

one transmitter assigned both bursts.

Burst N

A) Nominal Burst Profile (no timing errors); 8 symbolguard band is illustrated; 10 symbol ramp up and ramp downis illustrated.

Burst N+1

10Symbols

8Symbols

85


Figure 6-30 Worst-Case TDMA Burst Timing

At a symbol rate of Rs, symbols occur at a rate of one each Ts = 1/Rs seconds. Ramp Up and Ramp Down are thespread of a symbol in the time domain beyond Ts duration owing to the symbol-shaping filter and any residualeffect from the transmit equalizer. If only one symbol were transmitted, its duration would be longer than Ts dueto the shaping filter impulse response being longer than Ts. The spread of the first and last symbols of a bursttransmission effectively extends the duration of the burst to longer than N * Ts, where N is the number ofsymbols in the burst.

For S-CDMA channels, the bursts from all CMs are synchronized. This means that the ramp down of one burstmay occur at the same time as the ramp up of the subsequent burst. The CM MUST meet the ranging andsynchronization requirements of S-CDMA to assure that the ramp down and ramp up of bursts are aligned.

6.2.21 Fidelity Requirements

The following requirements assume that any pre-equalization is disabled unless otherwise noted.

6.2.21.1 Spurious Emissions

The spurious emissions specifications are separated into two regions based on the transmit power. Region 1 isdefined to have a power range of +14 dBmV to (Pmax - 3), i.e., the central region. Region 2 is defined from +8dBmV to +14 dBmV and (Pmax - 3) to Pmax, i.e., the low and high ends of the transmit power. Pmax is defined inTable 6-8, “User Unique Burst Parameters,” on page 81.

1.5 1.55 symbols

Symbol center ofBurst N, last symbol;1.5 symbols late

Symbol center ofBurst N+1, last symbol;1.5 symbols early

Time equal to 5 symbols separatesthe first symbol center of burst N+1and the last symbol center of burst N

8 symbol guardband

Worst case Burst timinginput to CMTS

Burst N+1

Burst N

MinislotBoundary

Symbol center of BurstN+1, first symbol; 1.5symbols early

86


For S-CDMA mode, when a modem is transmitting fewer than 4 spreading codes, the region 2 specifications areused for all transmit power levels. Otherwise, for all other numbers of spreading codes (e.g., 4 to 128) or forTDMA mode, the spurious emissions specifications are used according to the power ranges defined for regions 1and 2 above.

In addition, for S-CDMA, the spurious emission specifications for S-CDMA MUST be met for anynumber_allocated_codes, as defined in Section 6.2.19.

The noise and spurious power MUST NOT exceed the levels given in Table 6-9, Table 6-10, and Table 6-11.

In Table 6-9, Inband spurious includes noise, carrier leakage, clock lines, synthesizer spurious products, andother undesired transmitter products. It does not include ISI. The measurement bandwidth for Inband spurious isequal to the modulation rate (e.g., 160 to 5120 kHz). All requirements expressed in dBc are relative to the actualtransmit power that the CM emits.

The measurement bandwidth for the three (or fewer) Carrier-Related Frequency Bands (below 42 MHz) is 160kHz, with up to three 160 kHz bands, each with no more than the value given in Table 6-9, allowed to beexcluded from the “Bands within 5 to 42 MHz Transmitting Burst” specs of Table 6-11. Carrier-related spuriousemissions include all products whose frequency is a function of the carrier frequency of the upstreamtransmission, such as but not limited to carrier harmonics.

The measurement bandwidth is also 160 kHz for the Between Bursts specs of Table 6-9 below 42 MHz.

The Transmitting Burst specs apply during the mini-slots granted to the CM (when the CM uses all or a portionof the grant), and for 32 modulation intervals before and after the granted mini-slots. The Between Bursts specsapply except during a used grant of mini-slots, and the 32 modulation intervals before and after the used grant.

In TDMA mode, a mini-slot may be as short as 32 modulation intervals, or 6.25 microseconds at the 5.12 Msym/sec rate, or as short as 200 microseconds at the 160 ksym/sec rate.

87


Table 6-9 Spurious Emissions

6.2.21.1.1 Adjacent Channel Spurious Emissions

Spurious emissions from a transmitted carrier may occur in an adjacent channel which could be occupied by acarrier of the same or different modulation rate. The following table lists the required adjacent channel spuriousemission levels for all combinations of transmitted carrier modulation rates and adjacent channel modulationrates. The measurement is performed in an adjacent channel interval that is of appropriate bandwidth anddistance from the transmitted carrier based on the modulation rates of the transmitted carrier and the carrier in theadjacent channel.

Parameter Transmitting Burst Between Bursts

Inband -40 dBc The greater of -72 dBc or -59 dBmV

Adjacent Band See Table 6-10 The greater of -72 dBc or -59 dBmV

3 or Fewer Carrier-Related FrequencyBands(such as second harmonic, if < 42 MHz)

Region 1: -50 dBc fortransmitted modulationrate = 320 ksps andabove; -47 dBc fortransmitted modulationrate = 160 ksps

Region 2: -47 dBc

The greater of -72 dBc or -59 dBmV

Bands within 5 to 42 MHz (excluding assignedchannel, adjacent channels, and carrier-relatedchannels)

See Table 6-11 The greater of -72 dBc or -59 dBmV

CM Integrated Spurious Emissions Limits (all in 4

MHz, includes discretes)1

42 to 54 MHz54 to 60 MHz60 to 88 MHz88- to 860 MHz

1. These spec limits exclude a single discrete spur related to the tuned received channel; this single discrete spur MUSTbe no greater than -40 dBmV.

max(-40 dBc, -26 dBmV)-35 dBmV-40 dBmV-45 dBmV

-26 dBmV-40 dBmV-40 dBmV

max(-45 dBmV, -40 dB ref d/s2)

2. “dB ref d/s” is relative to the received downstream signal level. Some spurious outputs are proportional to the receivesignal level.

CM Discrete Spurious Emissions Limits1

42 to 54 MHz54 to 88 MHz88 to 860 MHz

-max(-50 dBc, -36 dBmV)-50 dBmV-50 dBmV

-36 dBmV-50 dBmV-50 dBmV

88


Table 6-10 Adjacent Channel Spurious Emissions Relative to the Transmitted Burst Power Level

6.2.21.1.2 Spurious Emissions in 5 to 42 MHz

Spurious emissions, other than those in an adjacent channel or carrier related emissions listed above, may occurin intervals (frequency bands) that could be occupied by other carriers of the same or different modulation rates.To accommodate these different modulation rates and associated bandwidths, the spurious emissions aremeasured in an interval equal to the bandwidth corresponding to the modulation rate of the carrier that could betransmitted in that interval. This interval is independent of the current transmitted modulation rate.

The following table lists the possible modulation rates that could be transmitted in an interval, the requiredspurious level in that interval, and the initial measurement interval at which to start measuring the spuriousemissions. Measurements should start at the initial distance and be repeated at increasing distance from thecarrier until the upstream band edge, 5 MHz or 42 MHz, is reached. Measurement intervals should not includethe three or fewer carrier related emission bands excluded above.

Table 6-11 Spurious Emissions in 5 to 42 MHz Relative to the Transmitted Burst Power Level

6.2.21.2 Spurious Emissions During Burst On/Off Transients

Each transmitter MUST control spurious emissions, prior to and during ramp up and during and following rampdown, before and after a burst.

On/off spurious emissions, such as the change in voltage at the upstream transmitter output due to enabling ordisabling transmission, MUST be no more than 100 mV, and such a step MUST be dissipated no faster than 2 µsof constant slewing. This requirement applies when the CM is transmitting at +55 dBmV or more; at backed-offtransmit levels, the maximum change in voltage MUST decrease by a factor of 2 for each 6-dB decrease ofpower level from +55 dBmV, down to a maximum change of 7 mV at 31 dBmV and below. This requirementdoes not apply to CM power-on and power-off transients.

Transmittedcarrier

modulation rateSpecification in theinterval, Region 1

Specificationin the

interval,Region 2

Measurement intervaland distance from carrier

edgeAdjacent channel carrier

modulation rate

-47 dBc -45 dBc 20 kHz to 180 kHz 160 kHz


All modulationrates





Possible modulationrate in this interval

Specificationin the interval,

Region 1


Region 2Initial measurement interval and

distance from carrier edge

160 kHz -54 dBc -53 dBc 220 kHz to 380 kHz






89


6.2.21.3 Modulation Error Ratio (MER)

MER measures the cluster variance caused by the transmit waveform. It includes the effects of ISI, spurious,phase noise, and all other transmitter degradations.

6.2.21.3.1 Definitions

Symbol MER: MERsymb is defined as follows for TDMA or S-CDMA symbols. The transmitted RF waveform(after appropriate downconversion) is applied to the ideal receive symbol matched filter and is sampled once persymbol. For TDMA, the matched filter is a square-root raised cosine filter with alpha = 0.25. For S-CDMA, thematched filter is a square-root raised cosine filter with alpha = 0.25, convolved with the time-reversed spreadingcode sequence. (In this convolution, the spreading code sequence is expressed as a weighted impulse train spacedat the chip period.) No external noise (AWGN) is added to the signal. The carrier frequency offset, carrier phaseoffset, symbol timing and gain may be adjusted during each burst to maximize MERsymb. Equalization of thereceived waveform is not permitted. For cases where the CM transmit equalizer is ON, the transmit equalizercoefficients may be adjusted to maximize MERsymb. MERsymb is defined at the F connector of the CM, exceptthat when an echo channel is inserted, MERsymb is defined at the output of the echo channel. MERsymb iscomputed by the formula

where:

Eav is the average constellation energy for equally likely symbols (see Section 6.2.13 and Figure 6-18)N is the number of symbols averagedej is the error vector from the jth received symbol to the ideal transmitted QAM symbol on the grid ofFigure 6-18

For S-CDMA, MERsymb is averaged over all active codes.

MER of composite chips: MERchip is specified for composite S-CDMA chips to ensure that high SNR ismaintained, especially for a small number of allocated codes, to prevent noise funneling effects when manymodems transmit simultaneously. A composite S-CDMA chip is defined as the output of the spreader during onechip interval, that is, an element of the transmission vector defined in Section 6.2.14, “S-CDMA Spreader,”on page 71.

MERchip is defined as follows. The transmitted RF waveform (after appropriate downconversion) is applied tothe ideal receive chip matched filter and is sampled once per chip. The matched filter is a square-root raisedcosine filter with alpha = 0.25. No external noise (AWGN) is added to the signal. The carrier frequency offset,carrier phase offset, timing and gain may be adjusted during each burst to maximize MERchip. Equalization ofthe received waveform is not permitted. For cases where the CM transmit equalizer is ON, the transmit equalizercoefficients may be adjusted to maximize MERchip. MERchip is defined at the F connector of the CM. MERchip is

MERsymb dB( ) 1010

Eav

1N---- ej

2

j 1=

N

∑-------------------------------

log⋅=

Pk

90


computed by the formula

where:

pj is the jth ideal transmitted composite chiprj is the jth received composite chipN is the number of composite chips observed

6.2.21.3.2 Requirements

Unless otherwise stated, the MER MUST meet or exceed the following limits over the full transmit power rangeof Table 6-8 for each modulation, each modulation rate, and over the full carrier frequency range, and for S-CDMA, over any valid number of active and allocated codes. The 5-42 MHz carrier frequency range refers moreprecisely to [5 MHz + modulation rate * 1.25 / 2] to [42 MHz - modulation rate * 1.25 / 2]. At the break pointsbetween regions, the higher MER specification applies.

Case 1: Flat channel, transmit equalization OFF

Case 1a: for modulation rates 2.56 MHz and below

MERsymb >= 30 dB over 15 to 30 MHz carrier frequencyMERsymb >= 27 dB over 10 MHz to 15 MHz and 30 MHz to 35 MHz carrier frequencyMERsymb >= 23 dB over 5 MHz to 10 MHz and 35 MHz to 42 MHz carrier frequency

Case 1b: for modulation rate 5.12 MHz

MERsymb >= 27 dB over 15 to 30 MHz carrier frequencyMERsymb >= 24 dB over 10 MHz to 15 MHz and 30 MHz to 35 MHz carrier frequencyMERsymb >= 20 dB over 5 MHz to 10 MHz and 35 MHz to 42 MHz carrier frequency

Case 2: Flat channel, transmit equalization ON

Case 2a: for TDMA/QPSK, MERsymb >= 30 dB.

Case 2b: for S-CDMA and all TDMA modulations except QPSK, MERsymb >= 35 dB.

Case 2c: for S-CDMA, MERchip >= 33 dB.

Case 3: Echo channel, transmit equalization ON

Case 3a: In the presence of a single echo selected from the channel micro-reflections defined in Table 4-2 onpage 26, the measured MERsymb MUST be >= 30 dB for TDMA/QPSK, and >= 33 dB for S-CDMA and allTDMA modulations except QPSK.

Case 3b: In the presence of two or three of the echoes defined in Table 4-2 (at most one of each specifiedmagnitude and delay), the measured MERsymb MUST be >= 29 dB.

MERchip dB( ) 10 10

pj2

j 1=

N

∑

pj rj– 2

j 1=

N

∑----------------------------

log⋅=

91


Since the table does not bound echo delay for the -30 dBc case, for testing purposes it is assumed that the timespan of the echo at this magnitude is less than or equal to 1.5 µs.

The CMTS MUST provide a test mode in which it:

• Accepts equalizer coefficients via an external interface, e.g., Ethernet.

• Sends the coefficients to the CM's pre-equalizer via ranging response message (both set and convolvemodes).

• Does not adjust the CM's frequency, timing or power.

6.2.21.4 Filter Distortion

The following requirements assume that any pre-equalization is disabled.

6.2.21.4.1 Amplitude

The spectral mask MUST be the ideal square-root raised-cosine spectrum with alpha = 0.25, within the rangesgiven in Table 6-12.

Table 6-12 Filter Amplitude Distortion

Where fc is the center frequency, Rs is the modulation rate, and the spectral density is measured with a resolutionbandwidth of 10 kHz or less.

6.2.21.4.2 Phase

fc - 5Rs/8 Hz to fc + 5Rs/8 Hz: Group Delay Variation MUST NOT be greater than 100 nsec.

6.2.21.5 Carrier Phase Noise

The upstream transmitter total integrated phase noise (including discrete spurious noise) MUST be less than orequal to -46 dBc summed over the spectral regions spanning 200 Hz to 400 kHz above and below the carrier.

The upstream transmitter total integrated phase noise (including discrete spurious noise) MUST be less than orequal to -44 dBc summed over the spectral regions spanning 8 kHz to 3.2 MHz above and below the carrier.

The CM MUST provide a test mode in which:

• A continuous (non-bursted), unmodulated (CW) upstream signal is transmitted at the commanded carrierfrequency, modulation rate and level. This is equivalent to replacing the chip sequence at the spreader outputwith the constant sequence (1, 1, 1, 1, 1, 1, ...) at nominal amplitude, equal on both I and Q.

Frequency Amplitude Range

low high

fc - 5Rs/8 - -30dB

fc - Rs/2 -3.5dB -2.5dB

fc - 3Rs/8 to fc - Rs/4 -0.5dB +0.3dB

fc - Rs/4 to fc + Rs/4 -0.3dB +0.3dB

fc + Rs/4 to fc + 3Rs/8 -0.5dB +0.3dB

fc + Rs/2 -3.5dB -2.5dB

fc + 5Rs/8 - -30dB

92


• The CM tracks the downstream symbol clock and uses it to generate the upstream symbol clock as in normalsynchronous operation.1

6.2.21.6 Channel Frequency Accuracy

The CM MUST implement the assigned channel frequency within ±50 parts per million over a temperature rangeof 0 to 40 degrees C up to five years from date of manufacture.

6.2.21.7 Modulation Rate Accuracy

For TDMA mode, the upstream modulator MUST provide an absolute accuracy of symbol rates ±50 parts permillion over a temperature range of 0 to 40 degrees C up to five years from date of manufacture.

For S-CDMA mode, the upstream modulator MUST lock the upstream chip rate to the downstream symbol rate,subject to the symbol timing jitter requirements of Section 6.2.21.8.

6.2.21.8 Modulation Timing Jitter

6.2.21.8.1 Symbol Timing Jitter for Asynchronous Operation

For TDMA mode, peak-to-peak symbol jitter, referenced to the previous symbol zero-crossing, of the transmittedwaveform, MUST be less than 0.02 of the nominal symbol duration over a 2-sec period. In other words, thedifference between the maximum and the minimum symbol duration during the 2-sec period shall be less than0.02 of the nominal symbol duration for each of the five upstream symbol rates.

For TDMA mode, the peak-to-peak cumulative phase error, referenced to the first symbol time and with anyfixed symbol frequency offset factored out, MUST be less than 0.04 of the nominal symbol duration over a 0.1-sec period. In other words, the difference between the maximum and the minimum cumulative phase error duringthe 0.1-sec period shall be less than 0.04 of the nominal symbol duration for each of the five upstream symbolrates. Factoring out a fixed symbol frequency offset is to be done by using the computed mean symbol durationduring the 0.1 sec.

6.2.21.8.2 Chip Timing Jitter for Synchronous Operation

All jitter specifications assume a downstream input to the CM per 6.3.5, 6.3.6, 6.3.7.2, 6.3.7.3, 6.3.9, and 6.3.10.

For S-CDMA mode, upstream chip clock timing error (with the mean error subtracted out) relative to the CMTSmaster clock MUST be less than 0.005 RMS of the chip period over a 35-second measurement interval. Thisapplies 1) to the worst-case jitter and frequency drift specified for the CMTS Master clock and the CMTSdownstream symbol clock in the requirements above and 2) for any round-trip propagation delay up to themaximum allowed.

The CM upstream chip clock SHOULD track the jitter components below 10 Hz in the input downstream symbolclock with an error transfer function below -25 dB. The CM upstream chip clock SHOULD attenuate the jittercomponents in the input downstream symbol clock above 200 Hz.

1. Section 6.2.21.5, text from “The CM MUST provide” to footnote updated per RFI2-N-02102by RKV on 10/28/02.

93


The CM MUST provide a test mode in which:

• A continuous (non-bursted) upstream signal is transmitted at the commanded carrier frequency, modulationrate and level.

• The chip sequence at the spreader output is replaced with an alternating binary sequence (1, -1, 1, -1, 1, -1, ...)at nominal amplitude, equal on both I and Q.

• The CM tracks the downstream symbol clock and uses it to generate the upstream symbol clock as in normalsynchronous operation.

6.2.22 Upstream Demodulator Input Power Characteristics

The maximum total input power to the upstream demodulator MUST NOT exceed 35 dBmV in the 5-42 MHzfrequency range of operation.

The intended received power in each carrier MUST be within the values shown in Table 6-13.

Table 6-13 Maximum Range of Commanded NominalReceive Power in Each Carrier

The demodulator MUST operate within its defined performance specifications with received bursts within ±6 dBof the nominal commanded received power.

6.2.23 Upstream Electrical Output from the CM

The CM MUST output an RF modulated signal with the characteristics delineated in Table 6-14.

Modulation Rate(kHz)

Maximum Range(dBmV)

160 -16 to +14

320 -13 to +17

640 -10 to +20

1,280 -7 to +23

2,560 -4 to +26

5,120 -1 to +29

94


Table 6-14 Electrical Output from CM

6.3 Downstream

6.3.1 Downstream Protocol

The downstream PMD sublayer MUST conform to ITU-T Recommendations J.83, Annex B for Low-DelayVideo Applications [ITU J.83-B], with the exceptions called out in Section 6.3.2.

Note: Any reference in this document to the transmission of television in the forward channel that is not consistent with [EN300 429] is outside the normative scope as only [EN 300 429] is used for digital multi-program TV distribution by cable inEuropean applications. See Section 1 (1.1 Scope).

6.3.2 Scalable Interleaving to Support Low Latency

The downstream PMD sublayer MUST support a variable-depth interleaver with the characteristics defined inTable 6-15. The table contains a subset of interleaver modes found in [ITU J.83-B].

Table 6-15 Interleaver Characteristics

The interleaver depth, which is coded in a 4-bit control word contained in the FEC frame synchronization trailer,always reflects the interleaving in the immediately-following frame. In addition, errors are allowed while theinterleaver memory is flushed after a change in interleaving is indicated.

Refer to [ITU J.83-B] for the control bit specifications required to specify which interleaving mode is used.

Parameter Value

Frequency 5 to 42 MHz edge to edge

Level range (one channel) TDMA:

+8 to +54 dBmV (32QAM, 64QAM)+8 to +55 dBmV (8QAM, 16QAM)+8 to +58 dBmV (QPSK)

S-CDMA:

+8 to +53 dBmV (all modulations)

Modulation Type QPSK, 8QAM, 16QAM, 32QAM, 64QAM, and 128QAM

Modulation Rate (nominal) TDMA: 160, 320, 640, 1280, 2560 and 5120 kHz

S-CDMA: 1280, 2560 and 5120 kHz

Bandwidth TDMA: 200, 400, 800, 1600, 3200 and 6400 kHz

S-CDMA: 1600, 3200 and 6400 kHz

Output impedance 75 ohms

Output Return Loss > 6 dB (5-42 MHz)

Connector F connector per [ISO-169-24] (common with the input)

I(Number of Taps)

J(Increment)

Burst Protection64QAM/256QAM

Latency64QAM/256QAM

8 16 5.9 µsec/4.1 µsec 0.22 msec/0.15 msec

16 8 12 µsec/8.2 µsec 0.48 msec/0.33 msec

32 4 24 µsec/16 µsec 0.98 msec/0.68 msec



95


6.3.3 Downstream Frequency Plan

The downstream frequency plan should comply with Harmonic Related Carrier (HRC), Incremental RelatedCarrier (IRC) or Standard (STD) North American frequency plans per [EIA-S542]. However, operation below acenter frequency of 91 MHz is not required.

6.3.4 CMTS Output Electrical

The CMTS MUST output an RF modulated signal with the following characteristics defined in Table 6-16.

96


Table 6-16 CMTS Output

6.3.5 Downstream Electrical Input to CM

The CM MUST be able to locate and accept RF modulated signals located within channels defined in [EIA-S542] for Harmonic Related Carrier (HRC), Incremental Related Carrier (IRC), and Standard (STD) NorthAmerican frequency plans. Operation below a center frequency of 91 MHz is not required. The signals will havethe characteristics defined in Table 6-17, “Electrical Input to CM,” on page 98.

Parameter Value

Center Frequency (fc) 91 to 857 MHz ±30 kHz 1

1. ±30 kHz includes an allowance of 25 kHz for the largest FCC frequency offset normally built intoupconverters.

Level Adjustable over the range 50 to 61 dBmV

Modulation Type 64QAM and 256QAM

Symbol Rate (nominal)

64QAM 5.056941 Msym/sec

256QAM 5.360537 Msym/sec

Nominal Channel Spacing 6 MHz

Frequency response

64QAM alpha ~0.18 Square Root Raised Cosine shaping

256QAM alpha ~0.12 Square Root Raised Cosine shaping

Total Discrete Spurious Inband (fc ± 3 MHz) < -57dBc

Inband Spurious and Noise (fc ± 3 MHz) < -48dBc; where channel spurious and noise includesall discrete spurious, noise, carrier leakage, clocklines, synthesizer products, and other undesiredtransmitter products. Noise within +- 50kHz of thecarrier is excluded.

Adjacent channel (fc ± 3.0 MHz) to (fc ± 3.75 MHz) < -58 dBc in 750 kHz

Adjacent channel (fc ± 3.75 MHz) to (fc ± 9 MHz) < -62 dBc, in 5.25 MHz, excluding up to 3 spurs, eachof which must be <-60 dBc when measured in a 10kHz band

Next adjacent channel (fc ± 9 MHz) to (fc ± 15 MHz) Less than the greater of -65 dBc or -12dBmV in6MHz, excluding up to three discrete spurs. The totalpower in the spurs must be < -60dBc when each ismeasured with 10 kHz bandwidth.

Other channels (47 MHz to 1,000 MHz) < -12dBmV in each 6 MHz channel, excluding up tothree discrete spurs. The total power in the spursmust be < -60dBc when each is measured with 10kHzbandwidth.

Phase Noise 1 kHz - 10 kHz: -33dBc double sided noise power

10 kHz - 50 kHz: -51dBc double sided noise power

50 kHz - 3 MHz: -51dBc double sided noise power

Output Impedance 75 ohms

Output Return Loss > 14 dB within an output channel up to 750 MHz; > 13dB in an output channel above 750 MHz

Connector F connector per [ISO-169-24]

97


Table 6-17 Electrical Input to CM

6.3.6 CM BER Performance

The bit-error-rate performance of a CM MUST be as described in this section. The requirements apply to theI = 128, J = 1 mode of interleaving.

6.3.6.1 64QAM

6.3.6.1.1 64QAM CM BER Performance

Implementation loss of the CM MUST be such that the CM achieves a post-FEC BER less than or equal to 10-8

when operating at a carrier to noise ratio (Es/No) of 23.5 dB or greater.

6.3.6.1.2 64QAM Image Rejection Performance

Performance as described in Section 6.3.6.1.1 MUST be met with analog or digital signal at +10 dBc in anyportion of the RF band other than the adjacent channels.

6.3.6.1.3 64QAM Adjacent Channel Performance

Performance as described in Section 6.3.6.1.1 MUST be met with a digital signal at 0 dBc in the adjacentchannels.

Performance as described in Section 6.3.6.1.1 MUST be met with an analog signal at +10 dBc in the adjacentchannels.

Performance as described in Section 6.3.6.1.1, with an additional 0.2-dB allowance, MUST be met with a digitalsignal at +10 dBc in the adjacent channels.

6.3.6.2 256QAM

6.3.6.2.1 256QAM CM BER Performance


when operating at a carrier to noise ratio (Es/No) as shown below.

Input Receive Signal LevelEs/No

Parameter Value

Center Frequency 91 to 857 MHz ±30 kHz

Level Range (one channel) -15 dBmV to +15 dBmV


Symbol Rate (nominal) 5.056941 Msym/sec (64QAM) and 5.360537 Msym/sec (256QAM)

Bandwidth 6 MHz (alpha = 0.18 Square Root Raised Cosine shaping for 64QAM andalpha = 0.12 Square Root Raised Cosine shaping for 256QAM)

Total Input Power (40-900 MHz) <30 dBmV

Input (load) Impedance 75 ohms

Input Return Loss > 6 dB (88-860 MHz)

Connector F connector per [ISO-169-24] (common with the output)

98


-6 dBmV to +15dBmV30dB or greater

Less than -6dBmV down to -15dBmV33dB or greater

6.3.6.2.2 256QAM Image Rejection Performance

Performance as described in Section 6.3.6.2.1 MUST be met with an analog or a digital signal at +10 dBc in anyportion of the RF band other than the adjacent channels.

6.3.6.2.3 256QAM Adjacent Channel Performance

Performance as described in Section 6.3.6.2.1 MUST be met with an analog or a digital signal at 0 dBc in theadjacent channels.

Performance as described in Section 6.3.6.2.1, with an additional 0.5-dB allowance, MUST be met with ananalog signal at +10 dBc in the adjacent channels.

Performance as described in Section 6.3.6.2.1, with an additional 1.0-dB allowance, MUST be met with a digitalsignal at +10 dBc in the adjacent channels.

6.3.7 CMTS Timestamp Jitter

The CMTS timestamp jitter MUST be less than 500 nsec peak-to-peak at the output of the DownstreamTransmission Convergence Sublayer. This jitter is relative to an ideal Downstream Transmission ConvergenceSublayer that transfers the MPEG packet data to the Downstream Physical Media Dependent Sublayer with aperfectly continuous and smooth clock at the MPEG packet data rate. Downstream Physical Media DependentSublayer processing MUST NOT be considered in timestamp generation and transfer to the DownstreamPhysical Media Dependent Sublayer.

Thus, any two timestamps N1 and N2 (N2 > N1) which were transferred to the Downstream Physical MediaDependent Sublayer at times T1 and T2 respectively must satisfy the following relationship:

| (N2-N1)/fCMTS - (T2-T1) | < 500x10-9

In the equation, the value of (N2-N1) is assumed to account for the effect of rollover of the timebase counter, andT1 and T2 represent time in seconds. fCMTS is the actual frequency of the CMTS master timebase and mayinclude a fixed frequency offset from the nominal frequency of 10.24 MHz. This frequency offset is bounded bya requirement further below in this section.

The jitter includes inaccuracy in timestamp value and the jitter in all clocks. The 500 nsec allocated for jitter atthe Downstream Transmission Convergence Sublayer output MUST be reduced by any jitter that is introducedby the Downstream Physical Media Dependent Sublayer.

The CM is expected to meet the burst timing accuracy requirements in Section 6.2.19 when the time stampscontain this worst-case jitter.

Note: Jitter is the error (i.e., measured) relative to the CMTS Master Clock. (The CMTS Master Clock is the 10.24 MHz clockused for generating the timestamps.)

99


6.3.7.1 CMTS Master Clock Jitter for Asynchronous Operation

The CMTS 10.24 MHz Master Clock MUST have frequency accuracy of ≤ ±5 ppm, drift rate ≤ 10-8 per second,and edge jitter of ≤ 10 nsec peak-to-peak (±5 nsec) over a temperature range of 0 to 40 degrees C up to ten yearsfrom date of manufacture.1 [The drift rate and jitter requirements on the CMTS Master Clock implies that theduration of two adjacent segments of 10,240,000 cycles will be within 30 nsec, due to 10 nsec jitter on eachsegments’ duration, and 10 nsec due to frequency drift. Durations of other counter lengths also may be deduced:adjacent 1,024,000 segments, ≤ 21 nsec; 1,024,000 length segments separated by one 10,240,000 cycle segment,≤ 30 nsec; adjacent 102,400,000 segments, ≤ 120 nsec. The CMTS Master Clock MUST meet such test limits in99% or more measurements.]

6.3.7.2 CMTS Master Clock Jitter for Synchronous Operation

In addition to the requirements in Section 6.3.7.1, the 10.24 MHz CMTS master clock MUST meet the followingdouble sideband phase noise requirements over the specified frequency ranges:

< [-50 + 20*log(fMC/10.24)] dBc (i.e., < 0.05 nsec RMS) 10 Hz to 100 Hz

< [-58 + 20*log(fMC/10.24)] dBc (i.e., < 0.02 nsec RMS) 100 Hz to 1 kHz

< [-50 + 20*log(fMC/10.24)] dBc (i.e., < 0.05 nsec RMS) 1 kHz to 10 kHz

< [-50 + 20*log(fMC/10.24)] dBc (i.e., < 0.05 nsec RMS) 10 kHz to fMC/2

where fMC is the frequency of the measured master clock in MHz. The value of fMC MUST be either an integralmultiple or divisor of 10.24 MHz. For example, if a 20.48 MHz oscillator is used as the master clock frequencysource, and there is no explicit 10.24 MHz clock to test, the 20.48 MHz clock may be used with fMC equal to20.48 in the above expressions.

6.3.7.3 CMTS Master Clock Frequency Drift for Synchronous Operation

The frequency of the master clock MUST NOT drift more than 1e-8 per second.

6.3.8 CMTS Clock Generation

The CMTS has the following three options related to the synchronization of the CMTS Master Clock and theDownstream Symbol Clock:

1. Not locked.

2. Downstream Symbol Clock locked to CMTS Master Clock.

3. CMTS Master Clock locked to Downstream Symbol Clock.

For S-CDMA operation the Master Clock and the Downstream Symbol Clock MUST be locked using eitheroption 2 or 3.

1. This specification MAY also be met by synchronizing the CMTS Master Clock oscillator to an external fre-quency reference source. If this approach is used, the internal CMTS Master Clock MUST have frequencyaccuracy of ±20ppm over a temperature range of 0 to 40 degrees C up to 10 years from date of manufacturewhen no frequency reference source is connected. The drift rate and edge jitter MUST be as specified above.

100


Let fb' represent the rate of the Downstream Symbol Clock which is locked to the CMTS Master Clock and let fm

'

represent the rate of the CMTS Master Clock locked to the Downstream Symbol Clock. Let fb represent thenominal specified downstream symbol rate and let fm represent the nominal CMTS Master Clock rate (10.24MHz).

With the Downstream Symbol Clock locked to the CMTS Master Clock the following equation MUST hold:

fb' = fm*M/N

With the CMTS Master Clock locked to the Downstream Symbol Clock the following equation MUST hold:

fm' = fb*N/M

M and N MUST be unsigned integer values each representable in 16 bits. (These are specified in the channelTLV parameters of the UCD). When the Downstream Symbol Clock and the CMTS Master Clock are not lockedtogether, the values of M and N are not valid and are ignored by the CM.1

The values of M and N MUST result in a value of fb' or fm

' which is not more than +/-1 ppm from its specifiednominal value. Table 6-18 lists the downstream modes of operation, their associated nominal symbol rates, fb,example values for M and N, the resulting synchronized clock rates, and their offsets from their nominal values.

Table 6-18 Downstream symbol rates and example parameters for synchronization with the CMTSMaster Clock

6.3.9 CMTS Downstream Symbol Clock Jitter for Synchronous Operation

The downstream symbol clock MUST meet the following double sideband phase noise requirements over thespecified frequency ranges:

< [-53 + 20*log(fDS/5.057)] dBc (i.e., < 0.07 nsec RMS) 10 Hz to 100 Hz

< [-53 + 20*log(fDS/5.057)] dBc (i.e., < 0.07 nsec RMS) 100 Hz to 1 kHz

< [-53 + 20*log(fDS/5.057)] dBc (i.e., < 0.07 nsec RMS) 1 kHz to 10 kHz


< [-30 + 20*log(fDS/5.057)] dBc (i.e., < 1 nsec RMS) 100 kHz to (fDS /2)

where fDS is the frequency of the measured clock in MHz. The value of fDS MUST be an integral multiple ordivisor of the downstream symbol clock. For example, an fDS = 20.227764 MHz clock may be measured if thereis no explicit 5.056941 MHz clock available.

1. Deleted “(Sync mode = 0)” from paragraph per ECN RFI2-N-02210, by GO, on 11/21/02.

Downstreammode

NominalSpecified

Symbol Rate, fb(MHz) M/N

CMTS Master ClockRate, fm' (MHz)

Downstream SymbolRate, fb' (MHz)

Offset fromNominal

Annex B,64QAM

5.056941 401/812 10.239990... 5.056945... 0.95 ppm

Annex B,256QAM

5.360537 78/149 10.240000... 5.360536... 0.02 ppm

101


The CMTS MUST provide a test mode in which:

• The downstream QAM symbol sequence is replaced with an alternating binary sequence (1, -1, 1, -1, 1, -1, ...)at nominal amplitude, on both I and Q.

• The CMTS generates the downstream symbol clock from the 10.24 MHz reference clock as in normal syn-chronous operation.

If an explicit downstream symbol clock which is capable of meeting the above phase noise requirements isavailable (e.g., a smooth clock without clock domain jitter), this test mode is not required.

6.3.10 CMTS Downstream Symbol Clock Drift for Synchronous Operation

The frequency of the downstream symbol clock MUST NOT drift more than 1e-8 per second.

102


7 Downstream Transmission Convergence Sublayer

7.1 Introduction

This section applies to the first technology option referred to in Section 1 (1.1 Scope). For the second option,refer to Annex F.

In order to improve demodulation robustness, facilitate common receiving hardware for both video and data, andprovide an opportunity for the possible future multiplexing of video and data over the PMD sublayer bitstreamdefined in Section 6, a sublayer is interposed between the downstream PMD sublayer and the Data-Over-CableMAC sublayer.

The downstream bitstream is defined as a continuous series of 188-byte MPEG [ITU-T H.222.0] packets. Thesepackets consist of a 4-byte header followed by 184 bytes of payload. The header identifies the payload asbelonging to the Data-Over-Cable MAC. Other values of the header may indicate other payloads. The mixture ofMAC payloads and those of other services is optional and is controlled by the CMTS.

Figure 7-1 illustrates the interleaving of Data-Over-Cable (DOC) MAC bytes with other digital information(digital video in the example shown).

Figure 7-1 Example of Interleaving MPEG Packets in Downstream

7.2 MPEG Packet Format

The format of an MPEG Packet carrying DOCSIS data is shown in Figure 7-2. The packet consists of a 4-byteMPEG Header, a pointer_field (not present in all packets) and the DOCSIS Payload.

Figure 7-2 Format of an MPEG Packet

header=DOC DOC MAC payload

header=video digital video payload








MPEG Header(4 bytes)

pointer_field(1 byte)

DOCSIS Payload(183 or 184 bytes)

103


7.3 MPEG Header for DOCSIS Data-Over-Cable

The format of the MPEG Transport Stream header is defined in section 2.4 of [ITU-T H.222.0]. The particularfield values that distinguish Data-Over-Cable MAC streams are defined in Table 7-1. Field names are from theITU specification.

The MPEG Header consists of 4 bytes that begin the 188-byte MPEG Packet. The format of the header for use ona DOCSIS Data-Over-Cable PID is restricted to that shown in Table 7-1. The header format conforms to theMPEG standard, but its use is restricted in this specification to NOT ALLOW inclusion of an adaptation_field inthe MPEG packets.

Table 7-1 MPEG Header Format for DOCSIS Data-Over-Cable Packets

7.4 MPEG Payload for DOCSIS Data-Over-Cable

The MPEG payload portion of the MPEG packet will carry the DOCSIS MAC frames. The first byte of theMPEG payload will be a ‘pointer_field’ if the payload_unit_start_indicator (PUSI) of the MPEG header is set.

7.4.1 stuff_byte

This standard defines a stuff_byte pattern having a value (0xFF) that is used within the DOCSIS payload to fillany gaps between the DOCSIS MAC frames. This value is chosen as an unused value for the first byte of theDOCSIS MAC frame. The ‘FC’ byte of the MAC Header will be defined to never contain this value. (FC_TYPE= ‘11’ indicates a MAC-specific frame, and FC_PARM = ‘11111’ is not currently used and, according to thisspecification, is defined as an illegal value for FC_PARM.)

7.4.2 pointer_field

The pointer_field is present as the fifth byte of the MPEG packet (first byte following the MPEG header)whenever the PUSI is set to one in the MPEG header. The interpretation of the pointer_field is as follows:

The pointer_field contains the number of bytes in this packet that immediately follow the pointer_field that theCM decoder must skip past before looking for the beginning of an DOCSIS MAC Frame. A pointer field MUSTbe present if it is possible to begin a Data-Over-Cable MAC Frame in the packet, and MUST point to either:

1. the beginning of the first MAC frame to start in the packet, or

2. to any stuff_byte preceding the MAC frame.

Field Length (bits) Description

sync_byte 8 0x47; MPEG Packet Sync byte

transport_error_indicator 1 Indicates an error has occurred in the reception of the packet.This bit is reset to zero by the sender, and set to onewhenever an error occurs in transmission of the packet

payload_unit_start_indicator 1 A value of one indicates the presence of a pointer_field as thefirst byte of the payload (fifth byte of the packet)

transport_priority 1 Reserved; set to zero

PID (see Note) 13 DOCSIS Data-Over-Cable well-known PID (0x1FFE)

transport_scrambling_control 2 Reserved, set to ‘00’

adaptation_field_control 2 ‘01’; use of the adaptation_field is NOT ALLOWED on theDOCSIS PID

continuity_counter 4 cyclic counter within this PID

104


7.5 Interaction with the MAC Sublayer

MAC frames may begin anywhere within an MPEG packet, MAC frames may span MPEG packets, and severalMAC frames may exist within an MPEG packet.

The following figures show the format of the MPEG packets that carry DOCSIS MAC frames. In all cases, thePUSI flag indicates the presence of the pointer_field as the first byte of the MPEG payload.

Figure 7-3 shows a MAC frame that is positioned immediately after the pointer_field byte. In this case,pointer_field is zero, and the DOCSIS decoder will begin searching for a valid FC byte at the byte immediatelyfollowing the pointer_field.

Figure 7-3 Packet Format Where a MAC Frame Immediately Follows the pointer_field

Figure 7-4 shows the more general case where a MAC Frame is preceded by the tail of a previous MAC Frameand a sequence of stuffing bytes. In this case, the pointer_field still identifies the first byte after the tail of Frame#1 (a stuff_byte) as the position where the decoder should begin searching for a legal MAC sublayer FC value.This format allows the multiplexing operation in the CMTS to immediately insert a MAC frame that is availablefor transmission if that frame arrives after the MPEG header and pointer_field have been transmitted.

In order to facilitate multiplexing of the MPEG packet stream carrying DOCSIS data with other MPEG-encodeddata, the CMTS SHOULD NOT transmit MPEG packets with the DOCSIS PID which contain only stuff_bytesin the payload area. MPEG null packets SHOULD be transmitted instead. Note that there are timing relationshipsimplicit in the DOCSIS MAC sublayer which must also be preserved by any MPEG multiplexing operation.

Figure 7-4 Packet Format with MAC Frame Preceded by Stuffing Bytes

Figure 7-5 shows that multiple MAC frames may be contained within the MPEG packet. The MAC frames maybe concatenated one after the other or be separated by an optional sequence of stuffing bytes.

Figure 7-5 Packet Format Showing Multiple MAC Frames in a Single Packet

MPEG Header(PUSI = 1)

pointer_field(= 0)

MAC Frame(up to 183 bytes)

stuff_byte(s)(0 or more)


pointer_field(= M)

Tail of MAC Frame #1(M bytes)


Start of MAC Frame #2


pointer_field(= 0)

MAC Frame#1


MAC Frame#2

MAC Frame#3

105


Figure 7-6 shows the case where a MAC frame spans multiple MPEG packets. In this case, the pointer_field ofthe succeeding frame points to the byte following the last byte of the tail of the first frame.

Figure 7-6 Packet Format Where a MAC Frame Spans Multiple Packets

The Transmission Convergence sublayer must operate closely with the MAC sublayer in providing an accuratetimestamp to be inserted into the Time Synchronization message (refer to Section 8.3.2 and Section 9.3).

7.6 Interaction with the Physical Layer

The MPEG-2 packet stream MUST be encoded according to [ITU-T J.83-B], including MPEG-2 transportframing using a parity checksum as described in [ITU-T J.83-B].

7.7 MPEG Header Synchronization and Recovery

The MPEG-2 packet stream SHOULD be declared “in frame” (i.e., correct packet alignment has been achieved)when five consecutive correct parity checksums, each 188 bytes from the previous one, have been received.

The MPEG-2 packet stream SHOULD be declared “out of frame,” and a search for correct packet alignmentstarted, when nine consecutive incorrect parity checksums are received.

The format of MAC frames is described in detail in Section 8.


pointer_field(= 0)

stuff_bytes(0 or more)

Start of MAC Frame #1(up to 183 bytes)


Continuation of MAC Frame #1(184 bytes)


pointer_field(= M)

Tail of MAC Frame #1(M bytes)


Start of MAC Frame #2(M bytes)

106


8 Media Access Control Specification

8.1 Introduction

8.1.1 Overview

This section describes version 2.0 of the DOCSIS MAC protocol. Some of the MAC protocol highlights include:

• Bandwidth allocation controlled by CMTS

• A stream of mini-slots in the upstream

• Dynamic mix of contention- and reservation-based upstream transmit opportunities

• Bandwidth efficiency through support of variable-length packets

• Extensions provided for future support of ATM or other Data PDU

• Quality-of-service including:

• Support for Bandwidth and Latency Guarantees

• Packet Classification

• Dynamic Service Establishment

• Extensions provided for security at the data link layer

• Support for a wide range of data rates

8.1.2 Definitions

8.1.2.1 MAC-Sublayer Domain

A MAC-sublayer domain is a collection of upstream and downstream channels for which a single MACAllocation and Management protocol operates. Its attachments include one CMTS and some number of CMs.The CMTS MUST service all of the upstream and downstream channels; each CM accesses one logical upstreamand one downstream channel at a time. The CMTS MUST police and discard any packets received that have asource MAC address that is not a unicast MAC address. The upstream channels may be any combination ofDOCSIS 1.x or 2.0 formats. A single upstream channel MAY transport DOCSIS 1.x and 2.0 bursts.

8.1.2.2 MAC Service Access Point

A MAC Service Access Point (MSAP) is an attachment to a MAC-sublayer domain. (Refer to Section 5.2)

8.1.2.3 Service Flows

The concept of Service Flows is central to the operation of the MAC protocol. Service Flows provide amechanism for upstream and downstream Quality of Service management. In particular, they are integral tobandwidth allocation.

A Service Flow ID defines a particular unidirectional mapping between a CM and the CMTS. Active UpstreamService Flow IDs also have associated Service IDs or SIDs. Upstream bandwidth is allocated to SIDs, and henceto CMs, by the CMTS. Service IDs provide the mechanism by which upstream Quality of Service isimplemented.

107


The CMTS MAY assign one or more Service Flow IDs (SFIDs) to each CM, corresponding to the Service Flowsrequired by the CM. This mapping can be negotiated between the CMTS and the CM during CM registration orvia dynamic service establishment (refer to Section 11.4).

In a basic CM implementation, two Service Flows (one upstream, one downstream) could be used, for example,to offer best-effort IP service. However, the Service Flow concept allows for more complex CMs to be developedwith support for multiple service classes while supporting interoperability with more basic modems. With thesemore complex modems, it is possible that certain Service Flows will be configured in such a way that they cannotcarry all types of traffic. That is, they may have a maximum packet size limitation or be restricted to small fixedsize unsolicited grants. Furthermore it might not be appropriate to send other kinds of data on Service Flows thatare being used for Constant Bit Rate (CBR)-type applications.

Even in these complex modems, it is necessary to be able to send certain upstream packets needed for MACmanagement, SNMP management, key management, etc. For the network to function properly, all CMs MUSTsupport at least one upstream and one downstream Service Flow. These Service Flows MUST always beprovisioned to allow the CM to request and to send the largest possible unconcatenated MAC frame (refer toSection 8.2.2). These Service Flows are referred to as the upstream and downstream Primary Service Flows. TheSID assigned to the upstream Primary Service Flow is referred to as the Primary SID.

The Primary SID MUST always be assigned to the first provisioned upstream Service Flow during theregistration process (which may or may not be the same temporary SID used for the registration process). ThePrimary Service Flows MUST be immediately activated at registration time. The Primary SID MUST always beused for periodic ranging after registration. The Primary Service Flows MAY be used for traffic. All unicastService Flows MUST use the security association defined for the Primary Service Flow. (Refer to [DOCSIS8])

All Service Flow IDs are unique within a single MAC-sublayer domain. The mapping of a unicast ServiceIdentifier to an active/admitted Service Flow MUST be unique within a single MAC-sublayer domain. Thelength of the Service Flow ID is 32 bits. The length of the Service ID is 14 bits (although the Service ID issometimes carried in the low-order bits of a 16-bit field).

8.1.2.4 Upstream Intervals, Mini-Slots and 6.25-Microsecond Increments

The upstream transmission time-line is divided into intervals by the upstream bandwidth allocation mechanism.Each interval is an integral number of mini-slots. A “mini-slot” is the unit of granularity for upstreamtransmission opportunities. There is no implication that any PDU can actually be transmitted in a single mini-slot. Each interval is labeled with a usage code which defines both the type of traffic that can be transmittedduring that interval and the physical-layer modulation encoding. The usage code values are defined in Table 8-20and allowed use is defined in Section 8.3. The binding of these values to physical-layer parameters is defined inTable 8-18.

8.1.2.4.1 TDMA mode

For DOCSIS 1.x channels, a mini-slot is a power-of-two multiple of 6.25µs increments, i.e., 2, 4, 8, 16, 32, 64, or128 times 6.25µs. For DOCSIS 2.0 TDMA, a mini-slot is a power-of-two multiple of 6.25µs increments: 1, 2, 4,8, 16, 32, 64, or 128 times 6.25µs. The relationship between mini-slots, bytes, and time ticks is described furtherin Section 9.3.4.

108


8.1.2.4.2 S-CDMA mode

For DOCSIS 2.0 S-CDMA channels, a mini-slot is not restricted to be a power-of-two multiple of 6.25µsincrements. Instead a mini-slot is a unit of capacity that is dependent on the modulation rate, number of

spreading codes, and number of spreading intervals configured for the upstream channel.1 While the channelmay be configured such that the time duration of a mini-slot is a power-of-two multiple of 6.25µs increments,there is no special significance to 6.25µs time ticks for S-CDMA channels. The relationship between mini-slotsand S-CDMA framing is described further in Section 6.2.11. The relationship between mini-slots, bytes, andtime ticks is described further in Section 9.3.4.

8.1.2.5 MAC Frame

A MAC layer frame is a unit of data exchanged between two (or more) entities at the Data Link Layer. A MACframe consists of a MAC Header (beginning with a Frame Control byte; see Figure 8-3), and may incorporate avariable-length data PDU. The variable-length PDU includes a pair of 48-bit addresses, data, and a CRC. Inspecial cases, the MAC Header may encapsulate multiple MAC frames (see Section 8.2.5.5) into a single MACframe. The MAC layer definition of a frame is different from any physical layer or MPEG layer definition of aframe.

8.1.2.6 Logical Upstream Channels

The MAC layer deals with logical upstreams. A logical upstream is identified with an upstream channel IDwhich is unique within the MSAP. A logical upstream consists of a contiguous stream of mini-slots which aredescribed and allocated by the UCD and MAP messages associated with a channel ID. A CM can only register tooperate on a single logical upstream channel.

There are 4 distinct types of logical upstream:

• Type 1: DOCSIS 1.x upstreams that support no DOCSIS 2.0 TDMA features.

• Type 2: Mixed upstreams that support DOCSIS 1.x and DOCSIS 2.0 TDMA bursts.

• Type 3A: DOCSIS 2.0 TDMA only upstreams that cannot support DOCSIS 1.x CMs.

• Type 3S: S-CDMA upstreams that support only CMs operating in S-CDMA mode.2

All valid logical upstreams fall into one of these 4 categories.

In DOCSIS 2.0 it is possible for multiple logical upstreams to share the same spectrum. When this occurs thelogical upstreams sharing the same spectrum are time domain multiplexed and only one is active at any time.Theonly exception to this rule is that it is possible for the Broadcast Initial Maintenance regions to be simultaneous.When a logical upstream channel is inactive its mini-slots are allocated to the NULL SID by its associated MAPmessages. Having multiple logical upstreams that share the same spectrum is the only way to have modemsoperating in S-CDMA mode share the same upstream spectrum with modems not operating in S-CDMA mode.

The CMTS MUST support all four logical upstream channel types individually, and MUST also support thefollowing three combinations of two logical upstream channels sharing the same upstream spectrum:

• One DOCSIS 1.x-only logical channel plus one S-CDMA logical channel with the same modulation rate onboth logical channels

1. This relationship holds true on an S-CDMA channel even if the burst parameters for a particular IUC have thespreader disabled.

2. Revised these four bulleted statements per ECN RFI2-N-02210, by GO, on 11/21/02.

109


• One mixed DOCSIS 1.x and A-TDMA logical channel plus one S-CDMA logical channel with the samemodulation rate on both logical channels

• One A-TDMA-only logical channel plus one S-CDMA logical channel with the same modulation rate onboth logical channels

The CMTS MAY support other combinations of logical channels sharing the same upstream spectrum, includingcombinations of logical channels with different modulation rates.

8.1.2.7 DOCSIS 2.0 Only Logical Upstreams

DOCSIS 2.0 Only Logical Upstreams have operational parameters in their associated UCD messages thatprevent the operation of DOCSIS 1.x CMs. See Section 8.3.3 for a detailed description of which parametervalues make a channel a DOCSIS 2.0 Only Upstream. The UCD messages for DOCSIS 2.0 Only LogicalUpstreams use a different MAC management message type (see Section 8.3.1) than do UCD messages forchannels that can support 1.x CMs. This prevents 1.x CMs from attempting to use DOCSIS 2.0 Only Upstreamsor from being confused by UCD messages for those channels. A logical upstream is a DOCSIS 2.0 Onlyupstream if and only if it is an S-CDMA upstream or a DOCSIS 2.0 TDMA only upstream.

8.1.3 Future Use

A number of fields are defined as being “for future use” or Reserved in the various MAC frames described in thisdocument. These fields MUST NOT be interpreted or used in any manner by this version (2.0) of the MACprotocol.

8.2 MAC Frame Formats

8.2.1 Generic MAC Frame Format

A MAC frame is the basic unit of transfer between MAC sublayers at the CMTS and the cable modem. The samebasic structure is used in both the upstream and downstream directions. MAC frames are variable in length. Theterm “frame” is used in this context to indicate a unit of information that is passed between MAC sublayer peers.This is not to be confused with the term “framing” that indicates some fixed timing relationship.

There are three distinct regions to consider, as shown in Figure 8-1. Preceding the MAC frame is either PMDsublayer overhead (upstream) or an MPEG transmission convergence header (downstream). The first part of theMAC frame is the MAC Header. The MAC Header uniquely identifies the contents of the MAC frame.Following the header is the optional Data PDU region. The format of the Data PDU and whether it is evenpresent is described in the MAC Header.

Figure 8-1 Generic MAC Frame Format

MAC Frame

MAC Header Data PDU (optional)

PMD Overhead(upstream)

MPEG PSI Header(downstream)

(see Figure 8-4)(see Figure 8-3)

(see Table 7-1)

110


8.2.1.1 PMD Overhead

In the upstream direction, the PHY layer indicates the start of the MAC frame to the MAC sublayer. From theMAC sublayer’s perspective, it only needs to know the total amount of overhead so it can account for it in theBandwidth Allocation process. More information on this may be found in the PMD Sublayer section of thisdocument (Section 6).

The FEC overhead is spread throughout the MAC frame and is assumed to be transparent to the MAC datastream. The MAC sublayer does need to be able to account for the overhead when doing Bandwidth Allocation.More information on this may be found in the Upstream Bandwidth Allocation section of this document (refer toSection 9.1).

8.2.1.2 MAC Frame Transport

The transport of MAC frames by the PMD sublayer for upstream channels is shown in Figure 8-2.

Figure 8-2 Upstream MAC/PMD Convergence

The layering of MAC frames over MPEG in the downstream channel is described in Section 7.

Note that the CMTS PHY ensures that the CMTS MAC receives upstream MAC frames in the same order theCM mapped the MAC frames onto mini-slots. That is to say that if MAC frame X begins in mini-slot n and MACframe Y begins in mini-slot n+m, then the CMTS MAC will receive X before it receives Y. This is true evenwhen, as is possible with S-CDMA, mini-slots n and n+m are actually simultaneously transmitted within thePHY layer.

8.2.1.3 Ordering of Bits and Octets

Within an octet, the least-significant bit is the first transmitted on the wire. This follows the convention used by

Ethernet and [ISO 8802-3]. This is often called bit-little-endian order.1

1. This applies to the upstream channel only. For the downstream channel, the MPEG transmission convergencesublayer presents an octet-wide interface to the MAC, so the MAC sublayer does not define the bit order.

PMD Sublayer

MAC Sublayer

Upper Layer

Start of Burst atMini-slotboundary



MAC Frame MAC Frame MAC Frame

Data FECPMDoverhead

PMDoverhead

PMDoverhead

Data FECPMDoverhead

PMDoverhead

DataPMDoverhead FEC Data FEC Data FEC

111


Within the MAC layer, when numeric quantities are represented by more than one octet (i.e., 16-bit and 32-bitvalues), the octet containing the most-significant bits is the first transmitted on the wire. This is sometimes calledbyte-big-endian order.

This section follows the textual convention that when bit-fields are presented in tables, the most-significant bitsare topmost in the table. For example, in Table 8-2, FC_TYPE occupies the two most-significant bits andEHDR_ON occupies the least-significant bit.

8.2.1.3.1 Representing Negative Numbers

Signed integer values MUST be transmitted and received in two’s complement format.

8.2.1.3.2 Type-Length-Value Fields

Many MAC messages incorporate Type-Length-Value (TLV) fields. TLV fields are unordered lists of TLV-tuples. Some TLV’s are nested (see Annex C). All TLV Length fields, except for EH_LEN (see Section 8.2.6),MUST be greater than zero. Unless otherwise specified, Type is one byte and Length is one byte.

Using this encoding, new parameters may be added which some devices cannot interpret. A CM or CMTS whichdoes not recognize a parameter type MUST skip over this parameter and MUST NOT treat the event as an errorcondition.

8.2.1.4 MAC Header Format

The MAC Header format MUST be as shown in Figure 8-3.

Figure 8-3 MAC Header Format

All MAC Headers MUST have the general format as shown in Table 8-1. The Frame Control (FC) field is thefirst byte and uniquely identifies the rest of the contents within the MAC Header. The FC field is followed by 3bytes of MAC control; an OPTIONAL Extended Header field (EHDR); plus a Header Check Sequence (HCS) toensure the integrity of the MAC Header.

FC(1 byte)

MAC_PARM(1 byte)

LEN (SID)(2 bytes)

EHDR(0-240 bytes)

FC PARM(5 bits)

EHDR_ON(1 bit)

FC TYPE(2 bits)

HCS(2 bytes)

112


Table 8-1 Generic MAC Header Format

The HCS field is a 16-bit CRC that ensures the integrity of the MAC Header, even in a collision environment.The HCS field coverage MUST include the entire MAC Header, starting with the FC field and including any

EHDR field that may be present. The HCS is calculated using CRC-CCITT (x16 + x12 + x5 + 1) as defined in[ITU-T X.25].

The FC field is broken down into the FC_TYPE sub-field, FC_PARM sub-field and an EHDR_ON indicationflag. The format of the FC field MUST be as shown in Table 8-2.

Table 8-2 FC Field Format

The FC_TYPE sub-field is the two MSBs of the FC field. These bits MUST always be interpreted in the samemanner to indicate one of four possible MAC frame formats. These types include: MAC Header with PacketPDU; MAC Header with ATM cells; MAC Header reserved for future PDU types; or a MAC Header used forspecific MAC control purposes. These types are spelled out in more detail in the remainder of this section.

The five bits following the FC_TYPE sub-field is the FC_PARM sub-field. The use of these bits are dependenton the type of MAC Header. The LSB of the FC field is the EHDR_ON indicator. If this bit is set, then anExtended Header (EHDR) is present. The EHDR provides a mechanism to allow the MAC Header to beextensible in an inter-operable manner.

The Transmission Convergence Sublayer stuff-byte pattern is defined to be a value of 0xFF. This precludes theuse of FC byte values which have FC_TYPE = ‘11’ and FC_PARM = ‘11111’.

MAC Header Field Usage Size

FC Frame Control: Identifies type of MAC Header 8 bits

MAC_PARM Parameter field whose use is dependent on FC:

if EHDR_ON=1; used for EHDR field length (ELEN)

else if for concatenated frames (see Table 8-10) used for

MAC frame count

else (for Requests only) indicates the number of mini-slots

requested

8 bits

LEN (SID) The length of the MAC frame. The length is defined to be the sum of thenumber of bytes in the extended header (if present) and the number ofbytes following the HCS field. (For a REQ Header, this field is the Service IDinstead)

16 bits

EHDR Extended MAC Header (where present; variable size). 0-240 bytes

HCS MAC Header Check Sequence 2 bytes

Length of a MAC Header 6 bytes + EHDR

FC Field Usage Size

FC_TYPE MAC Frame Control Type field:

00: Packet PDU MAC Header

01: ATM PDU MAC Header

10: Reserved PDU MAC Header

11: MAC Specific Header

2 bits

FC_PARM Parameter bits, use dependent on FC_TYPE. 5 bits

EHDR_ON When = 1, indicates that EHDR field is present.

[Length of EHDR (ELEN) determined by MAC_PARM field]

1 bit

113


The MAC_PARM field of the MAC Header serves several purposes depending on the FC field. If theEHDR_ON indicator is set, then the MAC_PARM field MUST be used as the Extended Header length (ELEN).The EHDR field may vary from 0 to 240 bytes. If this is a concatenation MAC Header, then the MAC_PARMfield represents the number of MAC frames (CNT) in the concatenation (see Section 8.2.5.5). If this is a RequestMAC Header (REQ) (see Section 8.2.5.3), then the MAC_PARM field represents the amount of bandwidthbeing requested. In all other cases, the MAC_PARM field is reserved for future use.

The third field has two possible uses. In most cases, it indicates the length (LEN) of this MAC frame. In onespecial case, the Request MAC Header, it is used to indicate the cable modem’s Service ID since no PDU followsthe MAC Header.

The Extended Header (EHDR) field provides extensions to the MAC frame format. It is used to implement datalink security as well as frame fragmentation, and can be extended to add support for additional functions in futurereleases. Initial implementations SHOULD pass this field to the processor. This will allow future softwareupgrades to take advantage of this capability. (Refer to Section 8.2.6 for details.)

8.2.1.5 Data PDU

The MAC Header may be followed by a Data PDU. The type and format of the Data PDU is defined in the FrameControl field of the MAC Header. The FC field explicitly defines a Packet Data PDU, an ATM Data PDU, aMAC-Specific Frame and a reserved code point (used as an escape mechanism for future extensions). All CMsMUST use the length in the MAC Header to skip over any reserved data.

8.2.2 Packet-Based MAC Frames

8.2.2.1 Variable-Length Packets

The MAC sublayer MUST support a variable-length Ethernet/[ISO8802-3]-type Packet Data PDU. With theexception of packets which have been subject to Payload Header suppression, the Packet PDU MUST be passedacross the network in its entirety, including its original CRC. In the case where Payload Header Suppression hasbeen applied to the Packet PDU, all bytes except those suppressed MUST be passed across the network and theCRC covers only those bytes actually transmitted (Refer to Section 8.2.6.3.1). A unique Packet MAC Header isappended to the beginning. The frame format without an Extended header MUST be as shown in Figure 8-4 andTable 8-3.

Figure 8-4 Ethernet/802.3 Packet PDU Format

FC(1 byte)

MAC_PARM(1 byte)

LEN(2 bytes)

HCS(2 bytes)

FC PARM= 00000

EHDR_ON= 0

FC TYPE= 00

Packet PDU1

(18-1518 bytes)

SA(6 bytes)

Type/Len(2 bytes)

User Data0-1500

CRC(4 bytes)

DA(6 bytes)

1 Frame size is limited to 1518 bytes in the absence of VLAN tagging. Cooperating deviceswhich implement IEEE 802.1Q VLAN tagging MAY use a frame size up to 1522 bytes.

114


Table 8-3 Packet PDU Format

Under certain circumstances (see Appendix VI) it may be necessary to transmit a packet PDU MAC framewithout an actual PDU. This is done so that the extended header can be used to carry certain information aboutthe state of the service flow. This could also happen as a result of PHS (see Section 8.2.6.3.1). Such a frame willhave the length field in MAC header set to the length of the extended header and will have no packet data, andtherefore no CRC. This can only happen with frames transmitted on the upstream as frames transmitted on thedownstream always have at least the DA and SA fields of the packet PDU.

8.2.3 ATM Cell MAC Frames

The FC_TYPE 0x01 is reserved for future definition of ATM Cell MAC Frames. This FC_TYPE field in theMAC Header indicates that an ATM PDU is present. This PDU MUST be silently discarded by MACimplementations of this version (2.0) of the specification. Compliant version 2.0 implementations MUST use thelength field to skip over the ATM PDU

8.2.4 Reserved PDU MAC Frames

The MAC sublayer provides a reserved FC code point to allow for support of future (to be defined) PDU formats.The FC field of the MAC Header indicates that a Reserved PDU is present. This PDU MUST be silentlydiscarded by MAC implementations of this version (2.0) of the specification. Compliant version 2.0implementations MUST use the length field to skip over the Reserved PDU.

Field Usage Size

FC FC_TYPE = 00; Packet MAC Header

FC_PARM[4:0] = 00000; other values reserved for future use andignored

EHDR_ON = 0 if there is no extended header, 1 if there is an EHDR

8 bits

MAC_PARM MAC_PARM = x; MUST be set to zero if there is no EHDR;

Otherwise set to length of EHDR

8 bits

LEN LEN = n+x; length of Packet PDU in bytes + length of EHDR 16 bits

EHDR Extended MAC Header, if present x (0-240) bytes

HCS MAC Header Check Sequence 16 bits

Packet Data PacketPDU:

DA - 48 bit Destination Address

SA - 48 bit Source Address

Type/Len - 16 bit Ethernet Type or [ISO8802-3] Length Field

User Data (variable length, 0-1500 bytes)

CRC - 32-bit CRC over packet PDU (as defined in Ethernet/[ISO8802-3])

n bytes

Length of Packet MAC frame 6 + x + n bytes

115


The format of the Reserved PDU without an extended header MUST be as shown in Figure 8-5 and Table 8-4.

Figure 8-5 Reserved PDU Format

Table 8-4 Reserved PDU Format

8.2.5 MAC-Specific Headers

There are several MAC Headers which are used for very specific functions. These functions include support fordownstream timing and upstream ranging/power adjust, requesting bandwidth, fragmentation and concatenatingmultiple MAC frames.

Table describes FC_PARM usage within the MAC Specific Header.

Table 8-5 MAC-Specific Headers and Frames

Field Usage Size

FC FC_TYPE = 10; Reserved PDU MAC Header

FC_PARM[4:0]; reserved for future use


8 bits



8 bits

LEN LEN = n+x; length of Reserved PDU + length of EHDR in bytes 16 bits



User Data Reserved Data PDU n bytes

Length of Reserved PDU MAC frame 6 + x + n bytes

FC_PARM Header/Frame Type

00000 Timing Header

00001 MAC Management Header

00010 Request Frame

00011 Fragmentation Header

11100 Concatenation Header

FC(1 byte)

MAC_PARM(1 byte)

LEN(2 bytes)

HCS(2 bytes)

FC PARM= RRRRR

EHDR_ON= 0

FC TYPE= 10

Reserved PDU(n bytes)

116


8.2.5.1 Timing Header

A specific MAC Header is identified to help support the timing and adjustments required. In the downstream,this MAC Header MUST be used to transport the Global Timing Reference to which all cable modemssynchronize. In the upstream, this MAC Header MUST be used as part of the Ranging message needed for acable modem’s timing and power adjustments. The Timing MAC Header is followed by a Packet Data PDU. Theformat MUST be as shown in Figure 8-6 and Table 8-6.

Figure 8-6 Timing MAC Header

FC(1 byte)

MAC_PARM(1 byte)

LEN(2 bytes)

HCS(2 bytes)

FC PARM= 00000

EHDR_ON= 0

FC TYPE= 11

Packet PDU(various lengths)

117


Table 8-6 Timing MAC Header Format

8.2.5.2 MAC Management Header

A specific MAC Header is identified to help support the MAC management messages required. This MACHeader MUST be used to transport all MAC management messages (refer to Section 8.3). The format MUST beas shown Figure 8-7 and Table 8-7.

Figure 8-7 Management MAC Header

Table 8-7 MAC Management Format

Field Usage Size

FC FC_TYPE = 11; MAC Specific Header

FC_PARM[4:0] = 00000; Timing MAC Header

EHDR_ON = 0; Extended header prohibited for SYNC and RNG-REQ

8 bits

MAC_PARM Reserved for future use 8 bits

LEN LEN = n; Length of Packet PDU in bytes 16 bits

EHDR Extended MAC Header not present 0 bytes


Packet Data MAC Management message:

SYNC message (downstream only)

RNG-REQ (upstream only)

n bytes

Length of Timing Message MAC frame 6 + n bytes

Field Usage SizeFC FC_TYPE = 11; MAC Specific Header

FC_PARM[4:0] = 00001; Management MAC Header


8 bits



8 bits

LEN LEN = n+x; length of MAC management message + length of EHDR inbytes

16 bits



Packet Data MAC management message n bytes

Length of Packet MAC frame 6 + x + n bytes

FC(1 byte)

MAC_PARM(1 byte)

LEN(2 bytes)

HCS(2 bytes)

FC PARM= 00001

EHDR_ON= 0

FC TYPE= 11

MAC mgmt msg(24-1522 bytes)

118


8.2.5.3 Request Frame

The Request Frame is the basic mechanism that a cable modem uses to request bandwidth. As such, it is onlyapplicable in the upstream. There MUST be no Data PDUs following the Request Frame. The general format ofthe Request MUST be as shown in Figure 8-8 and Table 8-8.

Figure 8-8 Request Frame Format

Table 8-8 Request Frame (REQ) Format

Because the Request Frame does not have a Data PDU following it, the LEN field is not needed. The LEN fieldMUST be replaced with an SID. The SID MUST uniquely identify a particular Service Flow within a given CM.

The bandwidth request, REQ, MUST be specified in mini-slots. The REQ field MUST indicate the current totalamount of bandwidth requested for this service queue including appropriate allowance for the PHY overhead.

8.2.5.4 Fragmentation Header

The Fragmentation MAC Header provides the basic mechanism to split a larger MAC PDU into smaller piecesthat are transmitted individually and then re-assembled at the CMTS. As such, it is only applicable in theupstream. The general format of the Fragmentation MAC Header MUST be as shown in Figure 8-9.

Field Usage Size

FC FC_TYPE = 11; MAC-Specific Header

FC_PARM[4:0] = 00010; MAC Header only; no data PDU following

EHDR_ON = 0; No EHDR allowed

8 bits

MAC_PARM REQ, total number of mini-slots requested 8 bits

SID Service ID (0...0x1FFF) 16 bits

EHDR Extended MAC Header not allowed 0 bytes


Length of a REQ MAC Header 6 bytes

FC(1 byte)

MAC_PARM(1 byte)

SID(2 bytes)

HCS(2 bytes)

FC PARM= 00010

EHDR_ON= 0

FC TYPE= 11

119


A compliant CM MUST support fragmentation. A compliant CMTS MAY support fragmentation. To decreasethe burden on the CMTS and to reduce unnecessary overhead, fragmentation headers MUST NOT be used onunfragmented frames.

Figure 8-9 Fragmentation MAC Header Format

Table 8-9 Fragmentation MAC Frame (FRAG) Format

8.2.5.5 Concatenation Header

A Specific MAC Header is defined to allow multiple MAC frames to be concatenated. This allows a single MAC

“burst” to be transferred across the network. The PHY overhead1 and the Concatenation MAC Header only occuronce. Concatenation of multiple MAC frames MUST be as shown in Figure 8-10. Concatenation of multipleMAC frames is the only method by which the CM can transmit more than one MAC frame in a single transmitopportunity.

A compliant CM MUST support concatenation. A compliant CMTS MAY support concatenation. Concatenationonly applies to upstream traffic. Concatenation MUST NOT be used on downstream traffic.

Figure 8-10 Concatenation of Multiple MAC Frames

Field Usage Size

FC FC_TYPE = 11; MAC-Specific Header

FC_PARM [4:0] = 00011; Fragmentation MAC Header

EHDR_ON = 1; Fragmentation EHDR follows

8 bits

MAC_PARM ELEN = 6 bytes; length of Fragmentation EHDR 8 bits

LEN LEN = length of fragment payload + EHDR length + FCRC length 16 bits

EHDR Refer to Section 8.2.6.2 6 bytes


Fragment Data Fragment payload; portion of total MAC PDU being sent n bytes

FCRC CRC - 32-bit CRC over Fragment Data payload (as defined in Ethernet/[ISO8802-3]) 4 bytes

Length of a MAC Fragment Frame 16 + n bytes

1. This includes the preamble, guard time, and possibly zero-fill bytes in the last codeword. The FEC overheadrecurs for each codeword.

FC(1 byte)

MAC_PARM(1 byte)

LEN(2 bytes)

EHDR(6 bytes)

FC PARM= 00011

EHDR_ON= 1

FC TYPE= 11

HCS(2 bytes)

EH_LEN= 0101

EH_VALUE(5 bytes)

EH_TYPE= 0011

FragmentData

FCRC(4 bytes)

PHYOverhead

MAC Hdr(Concat)

MAC Frame 1(MAC HDR +

optional PDU)

MAC Frame n(MAC HDR +

optional PDU)

120


Only one Concatenation MAC Header MUST be present per MAC “burst.” Nested concatenation MUST NOTbe allowed. Immediately following the Concatenation MAC Header MUST be the MAC Header of the firstMAC frame. Information within the MAC Header indicates the length of the first MAC Frame and provides ameans to find the start of the next MAC Frame. Each MAC frame within a concatenation MUST be unique andMAY be of any type. This means that Packet and MAC-specific Frames MAY be mixed together. However, allframes in a concatenation MUST be assigned to the same Service Flow. If the CMTS supports concatenation, itMUST support concatenations containing multiple frame types, including both Packet and MAC-specificframes.

The embedded MAC frames MAY be addressed to different destinations and MUST be delivered as if they weretransmitted individually.

The format of the Concatenation MAC Header MUST be as shown in Figure 8-11 and Table 8-10.

Figure 8-11 Concatenation MAC Header Format

Table 8-10 Concatenated MAC Frame Format

The MAC_PARM field in the Concatenation MAC header provides a count of MAC frames as opposed toEHDR length or REQ amount as used in other MAC headers. If the field is non-zero, then it MUST indicate thetotal count of MAC Frames (CNT) in this concatenantion burst.

8.2.6 Extended MAC Headers

Every MAC Header, except the Timing, Concatenation MAC Header and Request Frame, has the capability ofdefining an Extended Header field (EHDR). The presence of an EHDR field MUST be indicated by theEHDR_ON flag in the FC field being set. Whenever this bit is set, then the MAC_PARM field MUST be used asthe EHDR length (ELEN). The minimum defined EHDR is 1 byte. The maximum EHDR length is 240 bytes.

Field Usage Size

FC FC_TYPE = 11; MAC Specific Header

FC_PARM[4:0] = 11100; Concatenation MAC Header

EHDR_ON = 0; No EHDR with Concatenation Header

8 bits

MAC_PARM CNT, number of MAC frames in this concatenation

CNT = 0 indicates unspecified number of MAC frames

8 bits

LEN LEN = x +... + y; length of all following MAC frames in bytes 16 bits

EHDR Extended MAC Header MUST NOT be used 0 bytes


MAC frame 1 First MAC frame: MAC Header plus OPTIONAL data PDU x bytes

MAC frame n Last MAC frame: MAC Header plus OPTIONAL data PDU y bytes

Length of Concatenated MAC frame 6 + LEN bytes

FC(1 byte)

MAC_PARM(1 byte)

LEN(2 bytes)

HCS(2 bytes)

FC PARM= 11100

EHDR_ON= 0

FC TYPE= 11

121


A compliant CMTS & CM MUST support extended headers.

The format of a generic MAC Header with an Extended Header included MUST be as shown in Figure 8-12 andTable 8-11. Note: Extended Headers MUST NOT be used in a Concatenation MAC Header, but MAY beincluded as part of the MAC Headers within the concatenation.

Extended Headers MUST NOT be used in Request Frames and Timing MAC Headers.

Figure 8-12 Extended MAC Format

Table 8-11 Example Extended Header Format

Since the EHDR increases the length of the MAC frame, the LEN field MUST be increased to include both thelength of the Data PDU and the length of the EHDR.

The EHDR field consists of one or more EH elements. Each EH element is variable sized. The first byte of theEH element MUST contain a type and a length field. Every CM MUST use this length to skip over any unknownEH elements. The format of an EH element MUST be as shown in Table 8-12.

Table 8-12 EH Element Format

The types of EH element defined in Table 8-13 MUST be supported. Reserved and extended types are undefinedat this point and MUST be ignored.

Field Usage Size

FC FC_TYPE = XX; Applies to all MAC Headers

FC_PARM[4:0] = XXXXX; dependent on FC_TYPE

EHDR_ON = 1; EHDR present this example

8 bits

MAC_PARM ELEN = x; length of EHDR in bytes 8 bits

LEN LEN = x + y; length of EHDR plus OPTIONAL data PDU in bytes 16 bits

EHDR Extended MAC Header present this example x bytes


PDU OPTIONAL data PDU y bytes

Length of MAC frame with EHDR 6 + x + y bytes

EH Element Fields Usage Size

EH_TYPE EH element Type Field 4 bits

EH_LEN Length of EH_VALUE 4 bits

EH_VALUE EH element data 0-15 bytes

FC(1 byte)

MAC_PARM(1 byte)

LEN(2 bytes)

EHDR(1-240 bytes)

FC PARM(reserved)

EHDR_ON= 1

FC TYPE= XX

HCS(2 bytes)

EH_LEN(4 bits)

EH_VALUE(0-15 bytes)

repeatEH_TYPE(4 bits)

data PDU(optional)

122


The first ten EH element types are intended for one-way transfer between the cable modem and the CMTS. Thenext five EH element types are for end-to-end usage within a MAC-sublayer domain. Thus, the informationattached to EHDR elements 10-14 on the upstream MUST also be attached when the information is forwardedwithin a MAC-sublayer domain. The final EH element type is an escape mechanism that allows for more typesand longer values, and MUST be as shown in Table 8-13.

Table 8-13 Extended Header Types

8.2.6.1 Piggyback Requests

Several Extended Headers can be used to request bandwidth for subsequent transmissions. These requests aregenerically referred to as “piggyback requests”. They are extremely valuable for performance because they arenot subject to contention as Request Frames generally are. (Refer to Section 9.4)

Requests for additional bandwidth can be included in Request, Upstream Privacy and Upstream Privacy withFragmentation Extended Header elements.

8.2.6.2 Fragmentation Extended Header

Fragmented packets use a combination of the Fragmentation MAC header and a modified version of theUpstream Privacy Extended header. Section 8.2.5.4 describes the Fragmentation MAC header. The UpstreamPrivacy Extended Header with Fragmentation, also known as the Fragmentation Extended Header, MUST be asshown in Table 8-14.

EH_TYPE EH_LEN EH_VALUE

0 0 Null configuration setting; may be used to pad the extended header. TheEH_LEN MUST be zero, but the configuration setting may be repeated.

1 3 Request: mini-slots requested (1 byte); SID (2 bytes) [CM --> CMTS]

2 2 Acknowledgment requested; SID (2 bytes) [CM --> CMTS]

3 (= BP_UP) 4 Upstream Privacy EH Element [DOCSIS8]

5 Upstream Privacy with Fragmentation1 EH Element [DOCSIS8](See 8.2.7)

1.An Upstream Privacy with Fragmentation EH Element MUST only occur within a Fragmentation MAC-Specific Header. (Refer to Section 8.2.5.4)

4 (= BP_DOWN) 4 Downstream Privacy EH Element [DOCSIS8]

5 1 Service Flow EH Element; Payload Header Suppression Header Downstream.

6 1 Service Flow EH Element; Payload Header Suppression Header Upstream

2 Service Flow EH Element; Payload Header Suppression Header Upstream (1 byte),Unsolicited Grant Synchronization Header (1 byte)

7 - 9 Reserved

10 - 14 Reserved [CM <-> CM]

15 XX Extended EH Element: EHX_TYPE (1 byte), EHX_LEN (1 byte), EH_VALUE(length determined by EHX_LEN)

123


Table 8-14 Fragmentation Extended Header Format

8.2.6.3 Service Flow Extended Header

The Service Flow EH Element is used to enhance Service Flow operations. It may consist of one or two bytes inthe EH_VALUE field. The Payload Header Suppression Header is the only byte in a one byte field or the firstbyte in a two byte field. The Unsolicited Grant Synchronization Header is the second byte in a two byte field.

8.2.6.3.1 Payload Header Suppression Header

In Payload Header Suppression (PHS), a repetitive portion of the payload headers following the HCS issuppressed by the sending entity and restored by the receiving entity. In the upstream, the sending entity is theCM and the receiving entity is the CMTS. In the downstream, the sending entity is the CMTS and the receivingentity is the CM.

For small payloads, Payload Header Suppression provides increased bandwidth efficiency without having to usecompression. Payload Header Suppression may be separately provisioned in the upstream and downstream, andis referenced with an extended header element.

A compliant CM MUST support Payload Header Suppression.1 A compliant CMTS MAY support PayloadHeader Suppression.

The Payload Header Suppression Extended Header sub-element has the following format:


EH_TYPE Upstream Privacy EH element = 3 4 bits

EH_LEN Length of EH_VALUE = 5 4 bits

EH_VALUE Key_seq; same as in BP_UP 4 bits

Ver = 1; version number for this EHDR 4 bits

BPI_ENABLEIf BPI_ENABLE=0, BPI disabledIf BPI_ENABLE=1, BPI enabled

1 bit

Toggle bit; same as in BP_UP1

1. Refer to [DOCSIS8]

1 bit

SID; Service ID associated with this fragment 14 bits

REQ; number of mini-slots for a piggyback request 8 bits

Reserved; must be set to zero 2 bits

First_Frag; set to one for first fragment only 1 bit

Last_Frag; set to one for last fragment only 1 bit

Frag_seq; fragment sequence count, incrementedfor each fragment.

4 bits

1. This is not intended to imply that the CM must be capable of determining when to invoke Payload HeaderSuppression. Payload Header Suppression support is only required for the explicitly signalled case.

124


Table 8-15 Payload Header Suppression EHDR Sub-Element Format

The Payload Header Suppression Index is unique per SID in the upstream and unique per CM in the downstream.Payload Header Suppression is disabled if this Extended Header element is omitted or, if included, with the PHSIvalue set to 0. The Payload Header Suppression Index (PHSI) references the suppressed byte string known as aPayload Header Suppression Field (PHSF).

Note: While PHS signaling allows for up to 255 Payload Header Suppression Rules per Service Flow, the exact number ofPHS rules supported per Service Flow is implementation dependent. Similarly, PHS signaling allows for PHS Sizes of up to 255bytes, however, the maximum PHS Size supported is implementation dependent. For interoperability, the minimum PHS Sizethat MUST be supported is 64 bytes for any PHS rule supported. As with any other parameter requested in a Dynamic ServiceRequest, a PHS-related DSx request can be denied because of a lack of resources.

The Upstream Suppression Field MUST begin with the first byte following the MAC Header Checksum. TheDownstream Suppression Field MUST begin with the thirteenth byte following the MAC Header Checksum.This allows the Ethernet SA and DA to be available for filtering by the CM.

The operation of Baseline Privacy (refer to [DOCSIS8]) is not affected by the use of PHS. When Fragmentationis inactive, Baseline Privacy begins encryption and decryption with the thirteenth byte following the MACHeader checksum.

Unless the entire Packet PDU is suppressed, the Packet PDU CRC is always transmitted, and MUST becalculated only on the bytes transmitted. The bytes that are suppressed MUST NOT be included in the CRCcalculation.

8.2.6.3.2 Unsolicited Grant Synchronization Header

The Unsolicited Grant Synchronization Header may be used to pass status information regarding Service Flowscheduling between the CM and CMTS. It is currently only defined for use in the upstream with UnsolicitedGrant and Unsolicited Grant with Activity Detection scheduling services. (Refer to Section 10.2.3, “UnsolicitedGrant Service with Activity Detection,” on page 215)

This extended header is similar to the Payload Suppression EHDR except that the EH_LEN is 2, and theEH_VALUE has one additional byte which includes information related to Unsolicited Grant Synchronization.For all other Service Flow Scheduling Types, the field SHOULD NOT be included in the Extended HeaderElement generated by the CM. The CMTS MAY ignore this field.


EH_TYPE Service Flow EH_TYPE=5 for downstream and EH_TYPE=6for upstream

4 bits


EH_VALUE 0 Indicates no payload header suppression oncurrent packet.

8 bits

1-255 Payload Header Suppression Index (PHSI)

125


Table 8-16 Unsolicited Grant Synchronization EHDR Sub-Element Format

8.2.7 Fragmented MAC Frames

When enabled, fragmentation is initiated any time the grant length is less than the requested length. Thisnormally occurs because the CMTS chooses to grant less than the requested bandwidth.

Figure 8-13 Fragmentation Details


EH_TYPE Service Flow EH_TYPE = 6 4 bits


EH_VALUE 0 Indicates no payload header suppressionon current packet.

8 bits[always present]

1-255 Payload Header Suppression Index (PHSI)

Queue Indicator 1 bit

Active Grants 7 bits

HDR EHDR PDU CRC

FC PARM LEN PRV other

HCS

FRAG HDR FHCS Frag Payload (first)

FRAG HDR FHCS Frag Payload (mid)

FRAG HDR Frag Payload (last)

FC EHDRLEN = 6 LEN

Length of Frag

0001111 1

Single PacketMAC Frame

Fragment #1

Fragment #2

FragmentationHeader

Fragment #3

EHDR

FCRC

FCRC

FCRC

F - Set on First fragment, clearotherwiseL - Set on Last fragment, clearotherwiseSSSS - 4 bit sequence number,increments on each fragmentof a packet, rolling over asnecessary.XX - Reserved, set to 00

35 Ver SID RQ

FHCS

FHCS- Fragment HCSFCRC- Fragment CRC

Encrypted Portion for Baseline Privacy



RSV

Fragment Payload

ConcatHDR

PDU1

MACHDR1

Concat of MultipleMAC Frames

Fragment Payload

MAC HDR

PDUn

MACHDR2

MACHDRn

CRC1

CRCn

XXFLSSSS

YYYY0001 ETXXXXXXXXXXXXXX

YYYY - Key Sequence number, default = 0000

E - Enable BPI: 1 = enable, 0 =disableT = Toggle: 1 = odd, 0 = Even,default = 0XXXXXXXXXXXXXX = 14 bit SID

12 Bytes 4 Bytes

1B 1B 2B 6B

1B 1B 2B 1B 1B

126


The CM MAC calculates how many bytes of the original frame, including overhead for a fragmentation headerand CRC, can be sent in the received grant. The CM MAC generates a fragmentation header for each fragment.Fragmented frames use the MAC Message type (FC = 11). The FC parameter field is set to (00011), in order touniquely identify the fragmentation header from other MAC Message types. A four bit sequence field is used inthe last byte of the Extended Header field to aid in reassembly and to detect dropped or missing fragments. The

CM arbitrarily selects a sequence number for the first fragment of a frame.1 Once the sequence number isselected for the first fragment, the CM MUST increment the sequence number by one for each fragmenttransmitted for that frame. There are two flags associated with the sequence number, F and L, where F is set toindicate the first fragment and L is set to indicate the last fragment. Both are cleared for middle fragments. TheCMTS stores the sequence number of the first fragment (F bit set) of each frame. The CMTS MUST verify thatthe fragment sequence field increments (by one) for each fragment of the frame.

The REQ field in the fragmentation header is used by the fragmentation protocol for First and Middle fragments(refer to Section 10.3). For the Last fragment, the REQ field is interpreted as a request for bandwidth for asubsequent frame.

Fragmentation headers are fixed size and MUST contain only a Fragmentation extended header element. Theextended header consists of a Privacy EH element extended by one byte to make the fragment overhead an even16 bytes. A Privacy EH element is used whether the original packet header contained a Privacy EH element ornot. If privacy is in use, the following fields, Version, Enable bit, and SID, in the fragment EH element are thesame with those of BP EH element inside the original MAC frame. If privacy is not in use, the Privacy EHelement is used but the enable bit is cleared. The SID used in the fragment EH element MUST match the SIDused in the Partial Grant that initiated the fragmentation. A separate CRC MUST be calculated for each fragment(note that each MAC frame payload will also contain the CRC for that packet). A packet CRC of a reassembledpacket MAY be checked by the CMTS even though an FCRC covers each fragment.

The CMTS MUST make certain that any fragmentary grant it makes is large enough to hold at least 17 bytes ofMAC layer data. This is to ensure that the grant is large enough to accommodate fragmentation overhead plus atleast 1 byte of actual data. The CMTS may want to enforce an even higher limit as small fragments are extremelyinefficient.

When Fragmentation is active, Baseline Privacy encryption and decryption begin with the first byte followingthe MAC Header checksum.

8.2.7.1 Considerations for Concatenated Packets and Fragmentation

MAC Management Messages and Data PDUs can occur in the same concatenated frame. Without fragmentation,the MAC Management Messages within a concatenated frame would be unencrypted. However, withfragmentation enabled on the concatenated frame, the entire concatenated frame is encrypted based on thePrivacy Extended Header Element. This allows Baseline Privacy to encrypt each fragment without examining itscontents. Clearly, this only applies when Baseline Privacy is enabled.

To ensure encryption synchronization, if fragmentation, concatenation and Baseline Privacy are all enabled, aCM MUST NOT concatenate BPKM MAC Management messages. This ensures that BPKM MAC Managementmessages are always sent unencrypted.

1. ‘Frame’ always refers to either frames with a single Packet PDU or concatenated frame.

127


8.2.8 Error-Handling

The cable network is a potentially harsh environment that can cause several different error conditions to occur.This section, together with Section 11.5, describes the procedures that are required when an exception occurs atthe MAC framing level.

The most obvious type of error occurs when the HCS on the MAC Header fails. This can be a result of noise onthe network or possibly by collisions in the upstream channel. Framing recovery on the downstream channel isperformed by the MPEG transmission convergence sublayer. In the upstream channel, framing is recovered oneach transmitted burst, such that framing on one burst is independent of framing on prior bursts. Hence, framingerrors within a burst are handled by simply ignoring that burst; i.e., errors are unrecoverable until the next burst.

A second exception, which applies only to the upstream, occurs when the Length field is corrupted and the MACthinks the frame is longer or shorter than it actually is. Synchronization will recover at the next valid upstreamdata interval.

For every MAC transmission, The HCS MUST be verified. When a bad HCS is detected, the MAC Header andany payload MUST be dropped.

For Packet PDU transmissions, a bad CRC may be detected. Since the CRC only covers the Data PDU and theHCS covers the MAC Header; the MAC Header is still considered valid. Thus, the Packet PDU MUST bedropped, but any pertinent information in the MAC Header (e.g., bandwidth request information) MAY be used.

8.2.8.1 Error Recovery During Fragmentation

There are some special error handling considerations for fragmentation. Each fragment has its ownfragmentation header complete with an HCS and its own FCRC. There may be other MAC headers and CRCswithin the fragmented payload. However, only the HCS of the fragment header and the FCRC are used for errordetection during fragment reassembly.

If the HCS for a fragment fails the CMTS MUST discard that fragment. If the HCS passes but the FCRC fails,the CMTS MUST discard that fragment, but MAY process any requests in the fragment header. The CMTSSHOULD process such a request if it is performing fragmentation in Piggyback Mode. (Refer to Section10.3.2.2) This allows the remainder of the frame to be transmitted as quickly as possible.

If a CMTS is performing fragmentation in Multiple Grant Mode (refer to Section 10.3.2.1) it SHOULD completeall the grants necessary to fulfil the CM’s original request even if a fragment is lost or discarded. This allows theremainder of the frame to be transmitted as quickly as possible.

If any fragment of a non-concatenated MAC frame is lost or discarded the CMTS MUST discard the rest of thatframe. If a fragment of a concatenated MAC frame is lost or discarded the CMTS MAY forward any frameswithin the concatenation that have been received correctly or it MAY discard all the frames in the concatenation.

A CMTS MUST terminate fragment reassembly if any of the following occurs for any fragment on a given SID:

• The CMTS receives a fragment with the L bit set.

• The CMTS receives an upstream fragment, other than the first one, with the F bit set.

• The CMTS receives a packet PDU frame with no fragmentation header.

• The CMTS deletes the SID for any reason.

In addition, the CMTS MAY terminate fragment reassembly based on implementation dependent criteria such asa reassembly timer. When a CMTS terminates fragment reassembly it MUST dispose of (either by discarding orforwarding) the reassembled frame(s).

128


8.2.8.2 Error Codes and Messages

SP-OSSIv2.0 [DOCSIS5] annex D lists CM and CMTS error codes and messages. When reporting errorconditions, these codes MUST be used as indicated in [DOCSIS5] and MAY be used for reporting errors viavendor-specific interfaces. If the error codes are used, the error messages MAY be replaced by other descriptivemessages.

8.3 MAC Management Messages

8.3.1 MAC Management Message Header

MAC Management Messages MUST be encapsulated in an LLC unnumbered information frame per[ISO8802-2], which in turn is encapsulated within the cable network MAC framing, as shown in Figure 8-14.Figure 8-14 shows the MAC Header and the MAC Management Message Header fields which are commonacross all MAC Management Messages.

Figure 8-14 MAC Header and MAC Management Message Header Fields

The fields MUST be as defined below:

FC, MAC PARM, LEN, HCS Common MAC frame header -refer to Section 8.2.1.4 for details. All messagesuse a MAC-specific header.

Destination Address (DA) MAC management frames will be addressed to a specific CM unicast address or tothe DOCSIS management multicast address. These DOCSIS MAC management addresses are described inAnnex A.

FC MAC PARM LEN

HCS

DA

DA SA

SA

msg LEN DSAP SSAP

type RSVDversioncontrol

CRC

Managementmessage payload

MAC header

MACManagement

MessageHeader

Bit 0 8 16 24 31

129


Source Address (SA) The MAC address of the source CM or CMTS system.

Msg Length Length of the MAC message from DSAP to the end of the payload.

DSAP The LLC null destination SAP (00) as defined by [ISO8802-2].

SSAP The LLC null source SAP (00) as defined by [ISO8802-2].

Control Unnumbered information frame (03) as defined by [ISO8802-2].

Version & Type Each 1 octet. Refer to Table 8-17. Messages with a version number of 1 are understood by allCMs and CMTSes compliant with all versions of the DOCSIS specification. Messages with a version number of2 are understood by DOCSIS 1.1 and 2.0 equipment, and messages with a version number of 3 are understood byDOCSIS 2.0 equipment. DOCSIS 2.0 compliant CMs and CMTSes MUST silently discard any message with aversion number greater than 3.

130


Table 8-17 MAC Management Message Types1

RSVD 1 octet. This field is used to align the message payload on a 32-bit boundary. Set to 0 for this version.

Management Message Payload Variable length. As defined for each specific management message.

CRC Covers message including header fields (DA, SA,...). Polynomial defined by [ISO8802-3].

Type Value Version Message Name Message Description

1 1 SYNC Timing Synchronization

2 or 29 1 or 3 UCD Upstream Channel Descriptor

A UCD for a DOCSIS 2.0 Only Channel uses atype of 29 and a version of 3. All other UCDs usea type of 2 and a version of 1. (see Section 8.3.3)

3 1 MAP Upstream Bandwidth Allocation

4 1 RNG-REQ Ranging Request

5 1 RNG-RSP Ranging Response

6 1 REG-REQ Registration Request

7 1 REG-RSP Registration Response

8 1 UCC-REQ Upstream Channel Change Request

9 1 UCC-RSP Upstream Channel Change Response

10 1 TRI-TCD Telephony Channel Descriptor [DOCSIS6]

11 1 TRI-TSI Termination System Information [DOCSIS6]

12 1 BPKM-REQ Privacy Key Management Request [DOCSIS8]

13 1 BPKM-RSP Privacy Key Management Response [DOCSIS8]

14 2 REG-ACK Registration Acknowledge

15 2 DSA-REQ Dynamic Service Addition Request

16 2 DSA-RSP Dynamic Service Addition Response

17 2 DSA-ACK Dynamic Service Addition Acknowledge

18 2 DSC-REQ Dynamic Service Change Request

19 2 DSC-RSP Dynamic Service Change Response

20 2 DSC-ACK Dynamic Service Change Acknowledge

21 2 DSD-REQ Dynamic Service Deletion Request

22 2 DSD-RSP Dynamic Service Deletion Response

23 2 DCC-REQ Dynamic Channel Change Request

24 2 DCC-RSP Dynamic Channel Change Response

25 2 DCC-ACK Dynamic Channel Change Acknowledge

26 2 DCI-REQ Device Class Identification Request

27 2 DCI-RSP Device Class Identification Response

28 2 UP-DIS Upstream Transmitter Disable

29 3 (See entry for UCD)

30 3 INIT-RNG-REQ Initial Ranging Request

31 3 TST-REQ Test Request Message

32–255 Reserved for future use

1. Table 8-17, last two rows updated per RFI2-N-02102 by RKV on 10/28/02.

131


A compliant CMTS or CM MUST support the MAC management message types listed in Table 8-17, exceptmessages specific to Telephony Return devices which MAY be supported.

8.3.2 Time Synchronization (SYNC)

Time Synchronization (SYNC) MUST be transmitted by CMTS at a periodic interval to establish MAC sublayertiming. This message MUST use an FC field with FC_TYPE = MAC Specific Header and FC_PARM = TimingMAC Header. This MUST be followed by a Packet PDU in the format shown in Figure 8-15.

Figure 8-15 Format of Packet PDU Following the Timing Header

The parameters shall be as defined below:

CMTS Timestamp The count state of an incrementing 32 bit binary counter clocked with the CMTS 10.24MHz master clock.

The CMTS timestamp represents the count state at the instant that the first byte (or a fixed time offset from thefirst byte) of the Time Synchronization MAC Management Message is transferred from the DownstreamTransmission Convergence Sublayer to the Downstream Physical Media Dependent Sublayer as described in

Section 6.3.7. The CMTS MUST NOT allow a SYNC message to cross an MPEG packet boundary.1

8.3.3 Upstream Channel Descriptor (UCD)

An Upstream Channel Descriptor MUST be transmitted by the CMTS at a periodic interval to define thecharacteristics of an logical upstream channel (Figure 8-16). A separate message MUST be transmitted for eachlogical upstream that is currently available for use.

The MAC management header for this message has 2 possible values for the type field and for the version field.For DOCSIS 2.0 Only Upstreams the CMTS MUST use a value of 29 for the type field and MUST use a value of3 for the version field. For all other logical upstreams the CMTS MUST use a value of 2 for the type field and avalue of 1 for the version field. A CMTS MUST NOT use type 5 TLVs to encode IUCs 1-6 in a UCD with amessage type of 2. A CMTS MUST use type 5 TLVs to encode all burst profiles in a UCD with a message typeof 29.

1. Since the SYNC message applies to all upstream channels within this MAC domain, units were chosen to beindependent of the modulation rate of any particular upstream channel. See Section 9.3.4 for time-unit rela-tionships.

MAC Management Message Header

CMTS Timestamp

Bit 0 8 16 24 31

~~

~~

132


A type 2 UCD MUST contain type 4 burst descriptors for IUCs 3 and 4, a type 4 burst descriptor for requests anda type 4 burst descriptor for data. The burst descriptors for requests and data MUST use 1.x TDMA. To describea 1.x/2.0 mixed logical channel the UCD MUST additionally contain a type 5 burst descriptor for 2.0 TDMAdata opportunities.

A type 29 UCD MUST contain a type 5 burst descriptor for IUC 3, a type 5 burst descriptor for requests, and atype 5 burst descriptor for data.

A CMTS MUST NOT include burst descriptors for IUCs 5 or 6 in a UCD message for a DOCSIS 2.0 OnlyUpstream.

For interoperability a CMTS SHOULD provide:- burst descriptors for IUCs 1, 5 and 6 in a type 2 UCD describing a 1.x only channel.- burst descriptors for IUCs 1, 5, 6, 9 and 10 in a type 2 UCD describing a 1.x/2.0 mixed logical channel.- burst descriptors for IUCs 1, 9 and 10 in a type 29 UCD.1

The CMTS MUST treat an upstream as a DOCSIS 2.0 Only Upstream if any of the following is true about thechannel wide parameters: S-CDMA mode is enabled, the Mini-slot size is 1 time tick, or the value of theModulation Rate parameter is 32. The CMTS MUST treat an upstream as a DOCSIS 2.0 Only Upstream if any ofthe following is true about any of IUCs 1-4: A modulation type other than QPSK or 16QAM is used, the FECError Correction (T) parameter is greater than 10, any portion of the extended preamble is used, any attributefrom Table 8-19, “Upstream Physical-Layer Burst Attributes,” on page 137 with a type greater than 11 is presentin the descriptor. Note that none of these conditions can ever be true for IUCs 5 or 6.

To provide for flexibility the message parameters following the channel ID MUST be encoded in a type/length/value (TLV) form in which the type and length fields are each 1 octet long.

Figure 8-16 Upstream Channel Descriptor

A CMTS MUST generate UCDs in the format shown in Figure 8-16, including all of the following parameters:

Configuration Change Count Incremented by one (modulo the field size) by the CMTS whenever any of thevalues of this channel descriptor change, excluding the S-CDMA snapshot TLV2. If the value of this count in a

1. Section 8.3.3 text from “The MAC management header” to this footnote updated per RFI2-N-02089by RKV on 10/28/02.

MAC ManagementMessage Header

ConfigurationChange Count

Bit 0 8 16 24 31

~~

Mini-SlotSize

Upstreamchannel ID

Downstreamchannel ID

TLV-encoded information for the overallchannel

TLV-encoded BurstDescription

TLV-encoded information for the subsequent burst descriptors

133


subsequent UCD remains the same, the CM can quickly decide that the channel operating parameters have notchanged, and may be able to disregard the remainder of the message. This value is also referenced from the MAP.

Mini-Slot Size The size T of the Mini-Slot for this upstream channel in units of the Timebase Tick of 6.25 µs.For channels that can support DOCSIS 1.x CMs the allowable values are T = 2M, M = 1,...7. That is, T = 2, 4, 8,16, 32, 64 or 128.

For DOCSIS 2.0 Only Channels the relationship between M and T remains the same, but the allowable valuesare M = 0,1,…7, with T = 1, 2, 4, 8, 16, 32, 64, or 128. If the value of T is 1 then the channel MUST be treated asa DOCSIS 2.0 Only Channel. On S-CDMA channels, this parameter will not have any effect.

Upstream Channel ID The identifier of the upstream channel to which this message refers. This identifier isarbitrarily chosen by the CMTS and is only unique within the MAC-Sublayer domain. Note: Upstream ChannelID = 0 is reserved to indicate telephony return [DOCSIS6].

Downstream Channel ID The identifier of the downstream channel on which this message has beentransmitted. This identifier is arbitrarily chosen by the CMTS and is only unique within the MAC-Sublayerdomain.

All other parameters are coded as TLV tuples. The type values used MUST be those defined in Table 8-18, forchannel parameters, and Table 8-19, for upstream physical layer burst attributes. Burst descriptors (type 4 and/ortype 5) MUST appear in the UCD message after all other channel-wide parameters.

2. Refer to Section 6.2.11.2 for a description of the Timestamp Snapshot. The periodic update of the snapshotassociation does not represent a change in the operating parameters of the channel, hence the UCD configura-tion change count will not be incremented.

Table 8-18 Channel TLV Parameters

NameType

(1 byte)Length(1 byte)

Value(Variable length)

Modulation Rate 1 1 Multiples of base rate of 160 kHz. (Value is 1, 2, 4, 8,16, or 32.) A value of 32 means that this is a DOCSIS2.0 Only Upstream. If S-CDMA mode is enabled thenthis parameter MUST have a value of 8, 16 or 32.

Frequency 2 4 Upstream center frequency (Hz)

Preamble Pattern 3 1-128 The Value field defines the first portion of thePreamble Superstring. If there is no ExtendedPreamble Pattern parameter, then this parameterdefines the entire Preamble Superstring. All burst-specific preamble values are chosen as bit-substrings of the Preamble Superstring.

The first byte of the Value field contains the first 8 bitsof the superstring, with the first bit of the preamblesuperstring in the MSB position of the first Value fieldbyte, the eighth bit of the preamble superstring in theLSB position of the first Value field byte; the secondbyte in the Value field contains the second eight bitsof the superstring, with the ninth bit of the superstringin the MSB of the second byte and sixteenth bit of thepreamble superstring in the LSB of the second byte,and so forth.

Burst Descriptor

(DOCSIS 1.x)

4 n May appear more than once; described below.

134


Burst Descriptor

(DOCSIS 2.0)

5 n May appear more than once; described below.

Extended Preamble Pattern 6 1-64 512 Bit Preamble Superstring extension.

The value field is concatenated to the end of thevalue field of the Preamble Pattern to complete thePreamble Superstring. This Parameter MUST NOTbe included unless the length of the PreamblePattern parameter is 128 bytes. Therefore the MSBof the first byte of the value field of this parameteralways follows the LSB of the 128th byte of the valuefield of the Preamble Pattern parameter in thePreamble Superstring.

S-CDMA Mode Enable1 7 1 1 = on; 2 = off, If parameter is on, the upstream willoperate in S-CDMA mode. Otherwise it operates inTDMA mode. If this parameter is set to on, this is aDOCSIS 2.0 Only Upstream.

S-CDMA Spreading Intervalsper frame

8 1 Number of consecutive spreading intervals mappedonto a two-dimensional frame. (Value is 1 through32).

This TLV MUST be present if S-CDMA Mode isenabled, and MUST NOT be present if it is not.

S-CDMA Codes per Mini-slot 9 1 Number of consecutive codes mapped into a two-dimensional mini-slot. (Value is 2 through 32).


S-CDMA Number of ActiveCodes

10 1 Number of codes available to carry data payload.(Value is 64 through 128). This value MUST be amultiple of Codes per Mini-slot (TLV type 9).


S-CDMA Code Hopping Seed 11 2 15-bit seed to initialize code hopping sequence. Thevalue is left-justified in the 2-byte field. Set seed = 0to disable code hopping.


S-CDMA US ratio numerator ‘M’ 12 2 The numerator (M) of the M/N ratio relating thedownstream symbol clock to the upstreammodulation clock.


S-CDMA US ratio denominator‘N’

13 2 The denominator (N) of the M/N ratio relating thedownstream symbol clock to the upstreammodulation clock.


S-CDMA Timestamp Snapshot2 14 9 Snapshot of the timestamp, mini-slot, and S-CDMAframe taken at an S-CDMA frame boundary at theCMTS. A new value MUST be sampled and sent witheach UCD message. Refer to Section 6.2.11.2, “Mini-slot Numbering,” on page 54.


Table 8-18 Channel TLV Parameters (Continued)

135


Burst Descriptors are composed of an upstream Interval Usage Code, followed by TLV encodings that define, foreach type of upstream usage interval, the physical-layer characteristics that are to be used during that interval.The upstream interval usage codes are defined in the MAP message (see Section 8.3.4 and Table 8-20). Theformat of the Burst Descriptors is shown in Figure 8-17, “Top-Level Encoding for Burst Descriptors,” onpage 136.

Figure 8-17 Top-Level Encoding for Burst Descriptors

In Figure 8-17:

Type 4For Burst Descriptors intended for DOCSIS 1.x and/or DOCSIS 2.0 modems. 5 is for Burst Descriptorsintended for DOCSIS 2.0 modems only.

Length The number of bytes in the overall object, including the IUC and the embedded TLV items.

IUC Interval Usage code defined in Table 8-20. The IUC is coded on the 4 least-significant bits. The 4 most-significant bits are unused (=0).

Maintain Power Spectral Density 15 1 1=on;2=off. If this value is on and the modulation rateis different from the previous UCD, the CM MUSTchange its transmit power level to keep the powerspectral density as close as possible to what it wasprior to the modulation rate change. If this value is offor this parameter is omitted then the CM maintainsthe same power level that it was using prior to themodulation rate change.

In any case the effect of this parameter only lasts untilthe CM receives a power adjustment in a RNG-RSP.

Ranging Required 16 1 0= no ranging required1= unicast initial ranging required2= broadcast initial ranging requiredIf this value is non-zero and the UCD change countdoes not match the UCD currently in effect, the CMMUST perform ranging as specified by this TLVbefore using any other transmit opportunities with thenew UCD parameters. If ranging is required, and theCM is already registered, then it MUST maintain itsSIDs and not re-register.

If this value is 0 or this TLV is omitted, no ranging isrequired.

1. CM MUST assume S-CDMA mode is off if TLV is not present.2. Refer to Section 6.2.11.2, “Mini-slot Numbering,” on page 54 for a description of the Timestamp Snapshot. A change

solely in this parameter for a particular UCD does not represent a change in overall channel operating parameters,hence the UCD channel change count will not be incremented.

Table 8-18 Channel TLV Parameters (Continued)

0 8 16 24 31

Type = 4 or 5burst descriptor

Length(n)

Interval UsageCode

TLV codes for PHY parameters(n-1)

136


TLV items TLV parameters described in Table 8-18, “Channel TLV Parameters,” on page 134.

Two different type values are used to describe Burst Descriptors. Type 4 Burst Descriptors MUST be understoodby all modems and MUST only be used to describe IUCs 1 through 6 from Table 8-20. Type 5 Burst DescriptorsMUST be understood by DOCSIS 2.0 modems. A type 5 burst descriptor MUST be used to describe any IUC ifany of the following is true: a modulation type other than QPSK or 16QAM is used, the FEC Error Correction(T) attribute is greater than 10, any portion of the Extended Preamble is used, or any attribute from Table 8-19,“Upstream Physical-Layer Burst Attributes,” on page 137 with a type greater than 11 is present in the descriptor.Type 5 burst descriptors MUST NOT be used to describe IUC 5 or IUC 6. Type 5 burst descriptors MUST beused to describe IUCs 9-11.

A Burst Descriptor MUST be included for each Interval Usage Code that is to be used in the allocation MAP. TheInterval Usage Code MUST be one of the values from Table 8-20.

Within each Burst Descriptor is an unordered list of Physical-layer attributes, encoded as TLV values. Theseattributes are shown in Table 8-19. The CMTS MUST ensure that the set of burst attributes for all the burstdescriptors in the UCD allow any CM on the upstream to be able to request enough mini-slots to be able totransmit a maximum size PDU (see Section 8.2.2, “Packet-Based MAC Frames,” on page 114).

Table 8-19 Upstream Physical-Layer Burst Attributes

NameType


Value(Variable Length)

Modulation Type 1 1 1 = QPSK

2 = 16QAM

3 = 8QAM

4 = 32QAM

5 = 64QAM

6 = 128QAM (S-CDMA only)

Values greater than 2 MUST NOT be used in adescriptor encoded in a type 4 TLV.

Differential Encoding 2 1 1 = on, 2 = off. (see Section 6.2.13, “Symbol Mapping,”on page 64).

Preamble Length 3 2 Up to 1536 bits for burst descriptors encoded in a type 5TLV. Up to 1024 bits for descriptors encoded in a type 4TLV. If this descriptor is encoded in a type 4 TLV then thesubstring of the Preamble Superstring defined by thisparameter and the Preamble Value Offset MUST NOTinclude any bits from the Extended Preamble Pattern.

The value must be an integral number of symbols (seeSection 6.2.9, “Preamble Prepend,” on page 53)

137


Preamble Value Offset 4 2 Identifies the bits to be used in the preamble. This isspecified as a starting offset into the Preamble Superstring (see Table 8-18). That is, a value of zero meansthat the first bit of the preamble for this burst type is thevalue of the first bit of the Preamble Superstring. A valueof 100 means that the preamble is to use the 101st andsucceeding bits from the Preamble Superstring. Thisvalue must be a multiple of the symbol size.

The first bit of the preamble is the first bit into the symbolmapper (see Figure 6-2, “TDMA Upstream TransmissionProcessing,” on page 42, and Figure 6-3, “S-CDMAUpstream Transmission Processing,” on page 43), andis I1 in the first symbol of the burst (see Section 6.2.13,“Symbol Mapping,” on page 64).

FEC Error Correction (T) 5 1 0-16 for descriptors encoded in a type 5 TLV.

0-10 for descriptors encoded in a type 4 TLV.

(0 implies no FEC. The number of codeword parity bytesis 2*T)

FEC Codeword InformationBytes (k)

6 1 Fixed: 16 to 253 (assuming FEC on)Shortened: 16 to 253 (assuming FEC on)(Not used if no FEC, T=0)

Scrambler Seed 7 2 The 15-bit seed value left justified in the 2 byte field. Bit15 is the MSB of the first byte and the LSB of the secondbyte is not used. (Not used if scrambler is off)

Maximum Burst Size 8 1 The maximum number of mini-slots that can betransmitted during this burst type. Absence of thisconfiguration setting implies that the burst size is limitedelsewhere. When the interval type is Short Data Grant(IUC 5) or Advanced PHY Short Data Grant (IUC 9), thisvalue MUST be present and greater than zero. (SeeSection 9.1.2.5) If the CMTS needs to limit the maximumlength of concatenated frames it SHOULD use thisconfiguration setting to do so.1

Guard Time Size 9 1 For TDMA channels, the number of modulation intervalsmeasured from the end of the last symbol of one burst tothe beginning of the first symbol of the preamble of animmediately following burst. In Type 4 burst descriptors,the CMTS MUST choose the parameters such that thenumber of bytes that fit into any valid number of mini-slots will not change if the guard time is increased by 1.For S-CDMA channels, there is no guard time, andhence the CM MUST ignore this value. This TLV MUSTNOT be present for S-CDMA channels.2

Last Codeword Length 10 1 1 = fixed; 2 = shortened

Scrambler on/off 11 1 1 = on; 2 = off

R-S Interleaver Depth (Ir) 12 1 Reed-Solomon block interleaving depth. A depth of 0indicates Dynamic Mode; a depth of 1 indicates RSInterleaving Disabled (see Section 6.2.6, “TDMA ByteInterleaver,” on page 47) (0 through

). This TLV MUST be present for

burst descriptors encoded in type 5 TLVs on DOCSIS 2.0TDMA channels. This TLV MUST NOT be present for S-CDMA channels or in descriptors encoded in a type 4TLV.

Table 8-19 Upstream Physical-Layer Burst Attributes (Continued)

2048 K 2T+( )⁄

138


R-S Interleaver Block Size (Br) 13 2 Reed-Solomon block interleaving size in Dynamic Mode.(2*Nr through 2048 where Nr=k+2T). This TLV MUST bepresent in burst descriptors encoded in type 5 TLVs forDOCSIS 2.0 TDMA channels. This TLV MUST NOT bepresent on S-CDMA channels or in descriptors encodedin a type 4 TLV.

Preamble Type 14 1 1 = QPSK0

2 = QPSK1

(Reference Figure 6-18, “Symbol Constellations,” onpage 66, and Section 6.2.9, “Preamble Prepend,” onpage 53) This TLV MUST NOT be present in descriptorsencoded in a type 4 TLV.

S-CDMA Spreader on/off 15 1 1 = on; 2 = off. This TLV MUST be present for S-CDMAchannels. This TLV MUST NOT be present for non-S-CDMA channels or in descriptors encoded in a type 4TLV.

S-CDMA Codes per Subframe 16 1 Number of codes per sub-frame used in the S-CDMAframer. (1 through 128). This TLV MUST be present forS-CDMA channels. This TLV MUST NOT be present fornon-S-CDMA channels or in descriptors encoded in atype 4 TLV.

S-CDMA Framer InterleavingStep Size

17 1 Size of interleaving steps used in S-CDMA framer. (1through 32). This TLV MUST be present for S-CDMAchannels. This TLV MUST NOT be present for non-S-CDMA channels or in descriptors encoded in a type 4TLV.

TCM Encoding 18 1 1 = on; 2 = off. This TLV MUST be present for S-CDMAchannels. This TLV MUST NOT be present for non-S-CDMA channels or in descriptors encoded in a type 4TLV.

1. Maximum Burst Size row, Value cell, last sentence added per RFI2-N-02090 by RKV on 10/28/02.2. Guard Time Size row, Value cell, entire text updated per RFI2-N-02085 superseded per RFI2-N-02173

by RKV on 10/30/02.

Table 8-19 Upstream Physical-Layer Burst Attributes (Continued)

139


8.3.3.1 Example of UCD Encoded TLV Data

An example of UCD encoded TLV data is given in Figure 8-18.

Figure 8-18 Example of UCD Encoded TLV Data

Type1

Length1

Type2

Type3

Type6

Type4

Type5

Type4

Type5

Length4

Length1-128

Length1-64

LengthN

LengthN

LengthN

LengthN

ModulationRate

Frequency

PreamblePattern

Extended PreamblePattern

First Burst Descriptor

Second Burst Descriptor

Third Burst Descriptor

Fourth Burst Descriptor

140


8.3.4 Upstream Bandwidth Allocation Map (MAP)

A CMTS MUST generate MAPs in the format shown in Figure 8-19.

Figure 8-19 MAP Format

The parameters MUST be as follows:

Upstream Channel ID The identifier of the upstream channel to which this message refers.

UCD Count Matches the value of the Configuration Change Count of the UCD which describes the burstparameters which apply to this map. See Section 11.3.2.

Number Elements Number of information elements in the map.

Reserved Reserved field for alignment.

Alloc Start Time Effective start time from CMTS initialization (in mini-slots) for assignments within thismap.

Ack Time Latest time, from CMTS initialization, (mini-slots) processed in upstream. This time is used by theCMs for collision detection purposes. See Section 9.4.

Ranging Backoff Start Initial back-off window for initial ranging contention, expressed as a power of two.Values range 0-15 (the highest order bits must be unused and set to 0).

Ranging Backoff End Final back-off window for initial ranging contention, expressed as a power of two.Values range 0-15 (the highest order bits must be unused and set to 0).

RangingBackoff

Start

MAC ManagementMessage Header

UpstreamChannel ID

UCD CountNumber ofelements

Reserved

Alloc Start Time

Ack Time

RangingBackoff End

DataBackoff

Start

DataBackoff End

MAP Information Elements

Bit 0 8 16 24 31

141


Data Backoff Start Initial back-off window for contention data and requests, expressed as a power of two.Values range 0-15 (the highest order bits must be unused and set to 0).

Data Backoff End Final back-off window for contention data and requests, expressed as a power of two.Values range 0-15 (the highest order bits must be unused and set to 0).

MAP Information Elements MUST be in the format defined in Figure 8-20 and Table 8-20. Values for IUCsare defined in Table 8-20 and are described in detail in Section 9.1.2.

Note: Refer to Section 9.1.1 for the relationship between Alloc Start/Ack Time and the timebase.

Figure 8-20 MAP Information Element Structure

SID IUC offset = 0first interval

SID IUC offsetsecond interval

SID IUC offsetlast interval

SID=0 IUC=7offset = map

lengthend-of-list (Null IE)

SID IUCoffset = map

length

Acknowledgementsand Data Grants

Pending

SID IUCoffset =map

length

Bit 0 13 17 3114 18

142


Table 8-20 Allocation MAP Information Elements (IE)

8.3.5 Ranging Request (RNG-REQ)

A Ranging Request MUST be transmitted by a CM at initialization on an upstream other than a DOCSIS 2.0Only Upstream, and periodically on request from CMTS to determine network delay and request poweradjustment. On a DOCSIS 2.0 Only Upstream the CM transmits a INIT-RNG-REQ (see Section 8.3.26) messageat initialization instead, but uses the RNG-REQ for all unicast maintenance opportunities provided by the CMTS.This message MUST use an FC_TYPE = MAC Specific Header and FC_PARM = Timing MAC Header. ThisMUST be followed by a Packet PDU in the format shown in Figure 8-21.

IE Name1

1. Each IE is a 32-bit quantity, of which the most significant 14 bits represent the SID, the middle 4 bits the IUC, and the low-order 14 bits the mini-slot offset.

Interval UsageCode (IUC)

(4 bits)SID

(14 bits) Mini-slot Offset (14 bits)

Request 1 any Starting offset of REQ region

REQ/Data(refer to Annex A, formulticast definition)

2 multicast Starting offset of IMMEDIATE Data region(well-known multicasts define start intervals)

Initial Maintenance2

2. The CMTS MUST NOT use a unicast SID with an initial maintenance IUC on any upstream that is not a DOCSIS 2.0 OnlyUpstream.

3 broadcast orunicast

Starting offset of MAINT region (used in Initial or PeriodicRanging)

Station Maintenance 4 unicast3

3. The SID used in the Station Maintenance IE MUST be a Temporary SID, or the Primary SID that was assigned in theREG-RSP message to a CM.

Starting offset of MAINT region (used in Periodic Ranging)

Short Data Grant4

4. The distinction between long and short data grants is related to the amount of data that can be transmitted in the grant. Ashort data grant interval may use FEC parameters that are appropriate to short packets while a long data grant may beable to take advantage of greater FEC coding efficiency.

5 unicast Starting offset of Data Grant assignment;

If inferred length = 0, then it is a Data Grant pending.

Long Data Grant 6 unicast Starting offset of Data Grant assignment;

If inferred length = 0, then it is a Data Grant Pending

Null IE 7 zero Ending offset of the previous grant. Used to bound thelength of the last actual interval allocation.

Data Ack 8 unicast CMTS sets to map length

Advanced PHY Short5

Data Grant

5. The Advanced PHY types are provided for channels carrying a combination of DOCSIS 1.x and DOCSIS 2.0 bursts andalso for channels carrying DOCSIS 2.0 bursts only.



Advanced PHY LongData Grant



Advanced PHYUnsolicited Grant

11 unicast Starting offset of Data Grant assignment

Reserved 12-14 any Reserved

Expansion 15 expandedIUC

# of additional 32-bit words in this IE

143


Figure 8-21 Packet PDU Following the Timing Header

Parameters MUST be as follows:

SID For RNG-REQ messages transmitted in Broadcast Initial Maintenance intervals:

• Initialization SID if modem is attempting to join the network

• Initialization SID if modem has not yet registered and is changing upstream, downstream, or bothdownstream and upstream channels as directed by a downloaded parameter file

• Temporary SID if modem has not yet registered and is changing upstream (not downstream)channels as directed by a downloaded parameter file

• Primary SID (previously assigned in REG-RSP) if modem is registered and is changing upstreamchannels, or if the CM is redoing initial ranging as a result of a Dcc, UCC, or UCD change (seeSections 8.3.3 and 11.3.2)

For RNG-REQ messages transmitted in Unicast Initial Maintenance or Station Maintenance intervals:

• Temporary SID if modem has not yet registered

• Primary SID (previously assigned in REG-RSP) if modem is registered or is redoing initial rangingas a result of DCC, UCC, or UCD change

This is a 16-bit field of which the lower 14 bits define the SID, with bits 14 and 15 defined to be 0.

Downstream Channel ID The identifier of the downstream channel on which the CM received the UCDwhich described this upstream. This is an 8-bit field.

Pending Till Complete If zero, then all previous Ranging Response attributes have been applied prior totransmittting this request. If nonzero then this is time estimated to be needed to complete assimilation of rangingparameters. Note that only equalization can be deferred. Units are in unsigned centiseconds (10 msec).

8.3.6 Ranging Response (RNG-RSP)

A Ranging Response MUST be transmitted by a CMTS in response to received RNG-REQ or INIT-RNG-REQ.The state machines describing the ranging procedure appear in Section 11.2.4. In that procedure it may be notedthat, from the point of view of the CM, reception of a Ranging Response is stateless. In particular, the CMMUST be prepared to receive a Ranging Response at any time, not just following a Ranging Request.

To provide for flexibility, the message parameters following the Upstream Channel ID MUST be encoded in atype/length/value (TLV) form.


SID

Bit 0 8 16 24 31

~~

~~

DownstreamChannel ID

Pending TillComplete

144


Figure 8-22 Ranging Response

A CMTS MUST generate Ranging Responses in the form shown in Figure 8-22, including all of the followingparameters:

SID If the modem is being instructed by this response to move to a different channel, this is initialization SID.Otherwise, this is the SID from the corresponding RNG-REQ to which this response refers, except that if thecorresponding RNG-REQ was an initial ranging request specifying a initialization SID, then this is the assignedtemporary SID.

Upstream Channel ID The identifier of the upstream channel on which the CMTS received the RNG-REQ orINIT-RNG-REQ to which this response refers. On the first ranging response received by the CM during initialranging, this channel ID may be different from the channel ID the CM used to transmit the range request (seeAppendix III). Thus, the CM MUST use this channel ID for the rest of its transactions, not the channel ID fromwhich it initiated the range request.

All other parameters are coded as TLV tuples.

Ranging Status Used to indicate whether upstream messages are received within acceptable limits by CMTS.

Timing Adjust, Integer Part The amount by which to change the Ranging Offset of the burst transmission sothat bursts arrive at the expected mini-slot time at the CMTS. The units are (1 / 10.24 MHz) = 97.65625 ns. Anegative value implies the Ranging Offset is to be decreased, resulting in later times of transmission at the CM.(See Table 6-8 and Section 6.2.19.1, “Ranging Offset," on page 81)1

Power Adjust Information Specifies the relative change in transmission power level that the CM is to makein order that transmissions arrive at the CMTS at the desired power.

Frequency Adjust Information Specifies the relative change in transmission frequency that the CM is tomake in order to better match the CMTS. (This is fine-frequency adjustment within a channel, not re-assignmentto a different channel)

CM Transmitter Equalization Information This provides the equalization coefficients for the pre-equalizer.

1. Timing Adjust Information changed to Timing Adjust, Integer Part per RFI2-N-02104by RKV on 10/28/02.


SID from request

Bit 0 8 16 24 31

~

~

~

~

TLV EncodedInformation

Upstreamchannel ID

145


Downstream Frequency Override An optional parameter. The downstream frequency with which the modemshould redo initial ranging. (See Section 8.3.6.3)

Upstream Channel ID Override An optional parameter. The identifier of the upstream channel with whichthe modem should redo initial ranging. (See Section 8.3.6.3)

Timing Adjust, Fractional Part Higher resolution timing adjust offset to be appended to Timing Adjust,Integer Part. The units are (1 / (256*10.24 MHz)) = 0.3814697265625 ns. This parameter provides finergranularity timing offset information for transmission in S-CDMA mode. This TLV MUST be presentfor S-CDMA channels.1

8.3.6.1 Encodings

The type values used MUST be those defined in Table 8-21 and Figure 8-23. These are unique within the rangingresponse message but not across the entire MAC message set. The type and length fields MUST each be 1 octetin length.

1. Fine Timing Adjust Extension changed to Timing Adjust, Fractional Part per RFI2-N-02104by RKV on 10/28/02.

146


Table 8-21 Ranging Response Message Encodings1 2 3 4

Figure 8-23 Generalized Decision Feedback Equalization Coefficients

The number of taps per modulation interval T MUST be either 1, 2, or 4. The main tap location refers to theposition of the zero delay tap, between 1 and N. For a T-spaced equalizer, the number of taps per modulation

NameType


Value(Variable Length)

Timing Adjust, Integer Part 1 4 TX timing offset adjustment (signed 32-bit, units of (6.25microsec/64))

Power Level Adjust 2 1 TX Power offset adjustment (signed 8-bit, 1/4-dB units)

Offset Frequency Adjust 3 2 TX frequency offset adjustment (signed 16-bit, Hz units)

Transmit Equalization Adjust 4 n TX equalization data to be convolved with current values(refer to Section 6.2.15, “Transmit Pre-Equalizer,” onpage 73). See Figure 8-23 for details aboutrepresentation. This TLV MUST NOT be included in aRNG-RSP that includes a type 9 TLV.

Ranging Status 5 1 1 = continue, 2 = abort, 3 = success

Downstream frequency override 6 4 Center frequency of new downstream channel in Hz

Upstream channel ID override 7 1 Identifier of the new upstream channel.

Timing Adjust, Fractional Part 8 1 TX timing fine offset adjustment. 8-bit unsigned valuespecifying the fine timing adjustment in unitsof 1/(256*10.24 MHz)

Transmit Equalization Set 9 n TX equalization data to be loaded in place of currentvalues (refer to Section 6.2.10, “Modulation Rates,” onpage 54). See Figure 8-23 for details aboutrepresentation. This TLV MUST NOT be included in aRNG-RSP to a DOCSIS 1.x CM, and MUST NOT beincluded in a RNG-RSP that includes a type 4 TLV.

Reserved 9-255 n Reserved for future use

1. “Timing Adjust Information” row changed to “Timing Adjust, Integer Part” per RFI2-N-02104 by RKV on10/28/02.

2. Replaced word “below” with “Figure 8-23”, per ECN RFI2-N-02210, by GO, on 11/21/023. “Fine Timing Adjust Extension” row changed to “Timing Adjust, Fractional Part” per RFI2-N-02104

by RKV on 10/28/02.4. Replaced word “below” with “Figure 8-23”, per ECN RFI2-N-02210, by GO, on 11/21/02.

last coefficient FN (imag)

first reverse coefficient D1(imag)

last coefficient FN (real)

first reverse coefficient D1(real)

type4

length number of forwardtaps per symbol

number offorward taps (N)

number ofreverse taps (M)

main taplocation

first coefficient F1 (real) first coefficient F1 (imag)

reserved

4 or 9

147


interval field MUST be set to “1”. The total number of taps MAY range up to 64. Each tap consists of a real andimaginary coefficient entry in the table.

If more than 255 bytes are needed to represent equalization information, then several type 4 or 9 elements MAYbe used. Data MUST be treated as if byte-concatenated, that is, the first byte after the length field of the secondtype 4 or 9 element is treated as if it immediately followed the last byte of the first type 4 or 9 element.

Figure 6-28, “Transmit Pre-Equalizer Structure,” on page 73 depicts the operation of the equalizer.

8.3.6.2 Example of TLV Data

An example of TLV data is given in Figure 8-24.

Figure 8-24 Example of TLV Data

8.3.6.3 Overriding Channels Prior to Registration

The RNG-RSP message allows the CMTS to instruct the modem to move to a new downstream and/or upstreamchannel and to repeat initial ranging. However, the CMTS may do this only in response to an initial rangingrequest from a modem that is attempting to join the network, or in response to any of the unicast ranging requeststhat take place immediately after this initial ranging and up to the point where the modem successfully completesperiodic ranging. If a downstream frequency override is specified in the RNG-RSP, the modem MUSTreinitialize its MAC (Section 9.2) using initial ranging with the specified downstream center frequency as thefirst scanned channel. For the upstream channel, the modem selects its channel based on received UCD messagesas per Section 11.2.2.

If an upstream channel ID override is specified in the RNG-RSP, the modem MUST reinitialize its MAC (seeSection 9.2) using initial ranging with the upstream channel specified in the RNG-RSP for its first attempt andthe same downstream frequency on which the RNG-RSP was received.

If both downstream frequency and upstream channel ID overrides are present in the RNG-RSP, the modemMUST reinitialize its MAC (refer to Section 9.2) using initial ranging with the specified downstream frequencyand upstream channel ID for its first attempt.

Note that when a modem with an assigned temporary SID is instructed to move to a new downstream and/orupstream channel and to redo initial ranging, the modem MUST consider the temporary SID to be deassigned.The modem MUST redo initial ranging using the Initialization SID.

Type1

Length4

Timing adjust

Type2

Length1

Power adjust

Type3

Length2

Frequency adjust information

Type4

Lengthx

x bytes of CM transmitter equalization information

Type5

Length1

Ranging status

148


Configuration file settings for upstream channel ID and downstream frequency are optional, but if specified inthe config file they take precedence over the ranging response parameters. Once ranging is complete, only theC.1.1.2, UCC-REQ, and DCC-REQ mechanisms are available for moving the modem to a new upstreamchannel, and only the C.1.1.1 and DCC-REQ mechanisms are available for moving the modem to a newdownstream channel.

8.3.7 Registration Request (REG-REQ)

A Registration Request MUST be transmitted by a CM at initialization after receipt of a CM parameter file,except as outlined in Sections 11.2.8 and 11.2.9.

To provide for flexibility, the message parameters following the SID MUST be encoded in a type/length/valueform.

Figure 8-25 Registration Request

A CM MUST generate Registration Requests in the form shown in Figure 8-25, including the followingparameters:

SID Temporary SID for this CM.

All other parameters are coded as TLV tuples as defined in Annex C.

Registration Requests can contain many different TLV parameters, some of which are set by the CM according toits configuration file and some of which are generated by the CM itself. If found in the Configuration File, thefollowing Configuration Settings MUST be included in the Registration Request.

Configuration File Settings:

• All configuration settings included in the CMTS MIC calculation as specified in Section D.3.1

• Enable 2.0 Mode

• CMTS MIC Configuration Setting

Note: The CM MUST forward the vendor specific configuration settings to the CMTS in the same order in which they werereceived in the configuration file to allow the message integrity check to be performed.


SID

Bit 0 8 16 24 31

~~

~~


149


The following registration parameter MUST be included in the Registration Request.

Vendor Specific Parameter:

• Vendor ID Configuration Setting (Vendor ID of CM)

The Modem Capabilities Encodings registration parameter MUST also be included in the Registration Request.1

The following registration parameters MAY also be included in the Registration Request.

• Modem IP Address

• Vendor Specific Capabilities

The Vendor Specific Capabilities field is for vendor specific information not included in the configuration file.

The following Configuration Settings MUST NOT be forwarded to the CMTS in the Registration Request.

• Software Upgrade Filename

• Software Upgrade TFTP Server IP Address

• SNMP Write-Access Control

• SNMP MIB Object

• SNMPv3 Kickstart Value

• CPE Ethernet MAC Address

• HMAC Digest

• End Configuration Setting

• Pad Configuration Setting

• Telephone Settings Option

• SNMPv3 Notification Receiver

8.3.8 Registration Response (REG-RSP)

A Registration Response MUST be transmitted by the CMTS in response to a received REG-REQ.

To provide for flexibility, the message parameters following the Response field MUST be encoded in a TLVformat.

1. The CM MUST specify all of its Modem Capabilities in its Registration Request subject to the restrictions inSection C.1.3.1, “Modem Capabilities Encoding,” on page 337. The CMTS MUST NOT assume any ModemCapability which is defined but not explicitly indicated in the CM’s Registration Request.

150


Figure 8-26 Registration Response Format

A CMTS MUST generate Registration Responses in the form shown in Figure 8-26, including both of thefollowing parameters:

SID from Corresponding REG-REQ SID from corresponding REG-REQ to which this response refers.(This acts as a transaction identifier)

Response For REG-RSP to a modem registering as a 1.0 modem (i.e., REG-REQ contains DOCSIS 1.0 Classof Service Encodings)

0 = Okay1 = Authentication Failure2 = Class of Service Failure

For REG-RSP to a modem registering as a 1.1 or 2.0 modem (i.e., REG-REQ contains Service FlowEncodings), this field MUST contain one of the Confirmation Codes in Section C.4 and C.4.2.

Note: Failures apply to the entire Registration Request. Even if only a single requested Service Flow or DOCSIS 1.0 ServiceClass is invalid or undeliverable the entire registration is failed.

If the REG-REQ was successful, and contained Service Flow Parameters, Classifier Parameters, or PayloadHeader Suppression Parameters, the REG-RSP MUST contain, for each of these:

Classifier Parameters All of the Classifier Parameters from the corresponding REG-REQ, plus the ClassifierIdentifier assigned by the CMTS.

Service Flow Parameters All the Service Flow Parameters from the REG-REQ, plus the Service Flow IDassigned by the CMTS. Every Service Flow that contained a Service Class Name that was admitted/activated1

MUST be expanded into the full set of TLVs defining the Service Flow. Every upstream Service Flow that wasadmitted/activated MUST have a Service Identifier assigned by the CMTS. A Service Flow that was only

1. The ActiveQoSParamSet or AdmittedQoSParamSet is non-null.


Bit 0 8 16 24 31

~

~

~

~


ResponseSID from correspondingREG-REQ

151


provisioned will include only those QoS parameters that appeared in the REG-REQ, plus the assigned ServiceFlow ID.

Payload Header Suppression Parameters All the Payload Header Suppression Parameters from the REG-REQ, plus the Payload Header Suppression Index assigned by the CMTS.

If the REG-REQ failed due to Service Flow Parameters, Classifier Parameters, or Payload Header SuppressionParameters, and the Response is not one of the major error codes in C.4.2, the REG-RSP MUST contain at leastone of the following:

Classifier Error Set A Classifier Error Set and identifying Classifier Reference and Service Flow ReferenceMUST be included for at least one failed Classifier in the corresponding REG-REQ. Every Classifier Error SetMUST include at least one specific failed Classifier Parameter of the corresponding Classifier.

Service Flow Error Set A Service Flow Error Set and identifying Service Flow Reference MUST be includedfor at least one failed Service Flow in the corresponding REG-REQ. Every Service Flow Error Set MUSTinclude at least one specific failed QoS Parameter of the corresponding Service Flow.

Payload Header Suppression Error Set A PHS Error Set and identifying Service Flow Reference andClassifier Reference pair MUST be included for at least one failed PHS Rule in the corresponding REG-REQ.Every PHS Error Set MUST include at least one specific failed PHS Parameter of the corresponding failed PHSRule.

Service Class Name expansion always occurs at admission time. Thus, if a Registration-Request contains aService Flow Reference and a Service Class Name for deferred admission/activation, the Registration-ResponseMUST NOT include any additional QoS Parameters except the Service Flow Identifier. (Refer to Section 10.1.3,“Service Classes,” on page 205)

If the corresponding Registration Request contains DOCSIS 1.0 Service Class TLV’s (refer to Section C.1.1.4),the Registration Response MUST contain the following TLV tuples:

DOCSIS 1.0 Service Class Data Returned when Response = Okay. This is a Service ID / service class tuplefor each class of service granted.

Note: Service class IDs MUST be those requested in the corresponding REG-REQ.

Service Not Available Returned when Response = Class of Service Failure. If a service class cannot besupported, this configuration setting is returned in place of the service class data.

All other parameters are coded TLV tuples.

Modem Capabilities The CMTS response to the capabilities of the modem (if present in the RegistrationRequest)

Vendor-Specific Data As defined in Annex C

• Vendor ID Configuration Setting (vendor ID of the CMTS)

• Vendor-specific extensions

8.3.8.1 Encodings

The type values used MUST be those shown below. These are unique within the Registration Response messagebut not across the entire MAC message set. The type and length fields MUST each be 1 octet.

152


8.3.8.1.1 Modem Capabilities

This field defines the CMTS response to the modem capability field in the Registration Request. The CMTSMUST respond to the modem capability to indicate whether they may be used. If the CMTS does not recognize amodem capability, it MUST return the TLV with the value zero (“off”) in the Registration Response.

Only capabilities set to “on” in the REG-REQ may be set “on” in the REG-RSP as this is the handshakeindicating that they have been successfully negotiated. Capabilities set to “off” in the REG-REQ MUST also beset to “off” in the REG-RSP.

Encodings are as defined for the Registration Request.

8.3.8.1.2 DOCSIS 1.0 Service Class Data

A DOCSIS 1.0 Service Class Data parameter MUST be present in the Registration Response for each DOCSIS1.0 Class of Service parameter (refer to Section C.1.1.4) in the Registration Request.

This encoding defines the parameters associated with a requested class of service. It is somewhat complex in thatit is composed from a number of encapsulated type/length/value fields. The encapsulated fields define theparticular class of service parameters for the class of service in question. Note that the type fields defined areonly valid within the encapsulated service class data configuration setting string. A single service class dataconfiguration setting MUST be used to define the parameters for a single service class. Multiple class definitionsMUST use multiple service class data configuration setting sets.

Each received DOCSIS 1.0 Class of Service parameter must have a unique Class ID in the range 1..16. If noClass ID is present for any single DOCSIS 1.0 Class-of-Service TLV in the REG-REQ, the CMTS MUST send aREG-RSP with a class-of-service failure response and no DOCSIS 1.0 Class-of-Service TLVs.

Class ID

The value of the field MUST specify the identifier for the class of service to which the encapsulatedstring applies. This MUST be a class which was requested in the associated REG-REQ, if present.

Valid Range: The class ID MUST be in the range 1 to 16.

Service ID: The value of the field MUST specify the SID associated with this service class.

8.3.9 Registration Acknowledge (REG-ACK)

A Registration Acknowledge MUST be transmitted by the CM in response to a REG-RSP from the CMTS with

a confirmation code of ok (0).1 It confirms acceptance by the CM of the QoS parameters of the flow as reported

Type Length Value

1 n Encoded service class data

Type Length Value

1.1 1 from REG-REQ

Type Length Value

1.2 2 SID

153


by the CMTS in its REG-RSP. The format of a REG-ACK MUST be as shown in Figure 8-27.

Figure 8-27 Registration Acknowledgment

The parameter MUST be as follows:

SID from Corresponding:

REG-RSP SID from corresponding REG-RSP to which this acknowledgment refers. (This acts as atransaction identifier)

Confirmation Code The appropriate Confirmation Code (refer to Section C.4) for the entire correspondingRegistration Response.

The CM is required to send all provisioned Classifiers, Service Flows and Payload Header Suppression Rules tothe CMTS in the REG-REQ (see Section 6.3.7). The CMTS will return them with Identifiers, expanding ServiceClass Names if present, in the REG-RSP (see Section 6.3.8). Since the CM may be unable to support one or moreof these provisioned items, the REG-ACK includes Error Sets for all failures related to these provisioned items.

If there were any failures of provisioned items, the REG-ACK MUST include the Error Sets corresponding tothose failures. The Error Set identification is provided by using Service Flow ID and Classifier ID fromcorresponding REG-RSP. If a Classifier ID or SFID was omitted in the REG-RSP, the CM MUST use theappropriate Reference (Classifier Reference, SF Reference) in the REG-ACK.

Classifier Error Set A Classifier Error Set and identifying Classifier Reference/Identifier and Service FlowReference/Identifier pair MUST be included for at least one failed Classifier in the corresponding REG-RSP.Every Classifier Error Set MUST include at least one specific failed Classifier Parameter of the correspondingClassifier. This parameter MUST be omitted if the entire REG-REQ/RSP is successful.

Service Flow Error Set A Service Flow Error Set of the REG-ACK message encodes specifics of failedService Flows in the REG-RSP message. A Service Flow Error Set and identifying Service Flow Reference/Identifier MUST be included for at least one failed QoS Parameter of at least one failed Service Flow in thecorresponding REG-RSP message. This parameter MUST be omitted if the entire REG-REQ/RSP is successful.

1. The Registration-Acknowledge is a DOCSIS 1.1/2.0 message. Refer to Annex G for details of registrationinteroperability issues.


Bit 0 8 16 24 31

~

~

~

~


ConfirmationCode

SID from correspondingREG-RSP

154


Payload Header Suppression Error Set A PHS Error Set and identifying Service flow Reference/Identifierand Classifier Reference/Identifier pair MUST be included for at least one failed PHS Rule in the correspondingREG-RSP. Every PHS Error Set MUST include at least one specific failed PHS of the failed PHS Rule. Thisparameter MUST be omitted if the entire REG-REQ/RSP is successful.

Per Service Flow acknowledgment is necessary not just for synchronization between the CM and CMTS, butalso to support use of the Service Class Name. (Refer to Section 10.1.3, “Service Classes,” on page 205) Sincethe CM may not know all of the Service Flow parameters associated with a Service Class Name when makingthe Registration Request, it may be necessary for the CM to NAK a Registration Response if it has insufficientresources to actually support this Service Flow.

8.3.10 Upstream Channel Change Request (UCC-REQ)

An Upstream Channel Change Request MAY be transmitted by a CMTS to cause a CM to change the upstreamchannel on which it is transmitting. The format of an UCC-REQ message is shown in Figure 8-28.

Figure 8-28 Upstream Channel Change Request1


Upstream Channel ID The identifier of the upstream channel to which the CM is to switch for upstreamtransmissions. This is an 8-bit field.

Upon receipt of a UCC-REQ message, the CM MUST perform ranging with broadcast initial maintenance.

8.3.11 Upstream Channel Change Response (UCC-RSP)

An Upstream Channel Change Response MUST be transmitted by a CM in response to a received UpstreamChannel Change Request message to indicate that it has received and is complying with the UCC-REQ. Theformat of an UCC-RSP message is shown in Figure 8-29.

Before it begins to switch to a new upstream channel, a CM MUST transmit a UCC-RSP on its existing upstreamchannel. A CM MAY ignore an UCC-REQ message while it is in the process of performing a channel change.When a CM receives a UCC-REQ message requesting that it switch to an upstream channel that it is alreadyusing, the CM MUST respond with a UCC-RSP message on that channel indicating that it is already using thecorrect channel.

After switching to a new upstream channel, a CM MUST re-range using broadcast initial ranging, and thenMUST proceed without re-performing registration. The full procedure for changing channels is described inSection 11.3.3.

1. Revise Figure 8-28 to match Figure 8-29, per ECN RFI2-N-02210, by GO, on 11/21/02.


Bit 0 8 16 24 31

~~

~~

Upstreamchannel ID

155


Figure 8-29 Upstream Channel Change Response


Upstream Channel ID The identifier of the upstream channel to which the CM is to switch for upstreamtransmissions. This MUST be the same Channel ID specified in the UCC-REQ message. This MUST be an 8-bitfield.

8.3.12 Dynamic Service Addition — Request (DSA-REQ)

A Dynamic Service Addition Request MAY be sent by a CM or CMTS to create a new Service Flow.

Figure 8-30 Dynamic Service Addition — Request

A CM or CMTS MUST generate DSA-REQ messages in the form shown in Figure 8-30 including the followingparameter:


Bit 0 8 16 24 31

~~

~~

Upstreamchannel ID


Transaction ID

Bit 0 8 16 24 31

~

~

~

~


156


Transaction ID Unique identifier for this transaction assigned by the sender.

All other parameters are coded as TLV tuples as defined in Annex C. A DSA-REQ message MUST NOT containparameters for more than one Service Flow in each direction, i.e., a DSA-REQ message MUST containparameters for either a single upstream Service Flow, or for a single downstream Service Flow, or for oneupstream and one downstream Service Flow.

The DSA-REQ message MUST contain:

Service Flow Parameters Specification of the Service Flow’s traffic characteristics and schedulingrequirements.

The DSA-REQ message MAY contain classifier parameters and payload header suppression parametersassociated with the Service Flows specified in the message:

Classifier Parameters Specification of the rules to be used to classify packets into a specific Service Flow.

Payload Header Suppression Parameters Specification of the payload header suppression rules to be usedwith an associated classifier.

If Privacy is enabled, the DSA-REQ message MUST contain:

Key Sequence Number The key sequence number of the Auth Key, which is used to calculate the HMAC-Digest. (Refer to Section C.1.4.3)

HMAC-Digest The HMAC-Digest Attribute is a keyed message digest (to authenticate the sender). TheHMAC-Digest Attribute MUST be the final Attribute in the Dynamic Service message’s Attribute list. (Refer toSection C.1.4.1)

8.3.12.1 CM-Initiated Dynamic Service Addition

CM-initiated DSA-Requests MUST use the Service Flow Reference to link Classifiers to Service Flows. Valuesof the Service Flow Reference are local to the DSA message; each Service Flow within the DSA-Request MUSTbe assigned a unique Service Flow Reference. This value need not be unique with respect to the other serviceflows known by the sender.

CM-initiated DSA-Request MUST use the Classifier Reference and Service Flow Reference to link PayloadHeader Suppression Parameters to Classifiers and Service Flows. A DSA-request MUST use the Service FlowReference to link Classifier to Service Flow. Values of the Classifier Reference are local to the DSA message;each Classifier within the DSA-request MUST be assigned a unique Classifier Reference.

CM-initiated DSA-Requests MAY use the Service Class Name (refer to Section C.2.2.3.4) in place of some, orall, of the QoS Parameters.

8.3.12.2 CMTS-Initiated Dynamic Service Addition

CMTS-initiated DSA-Requests MUST use the Service Flow ID to link Classifiers to Service Flows. ServiceFlow Identifiers are unique within the MAC domain. CMTS-initiated DSA-Requests for Upstream ServiceFlows MUST also include a Service ID.

CMTS-initiated DSA-Requests which include Classifiers, MUST assign a unique Classifier Identifier on a perService Flow basis.

157


CMTS-initiated DSA-Requests for named Service Classes MUST include the QoS Parameter Set associated withthat Service Class.

8.3.13 Dynamic Service Addition — Response (DSA-RSP)

A Dynamic Service Addition Response MUST be generated in response to a received DSA-Request. The formatof a DSA-RSP MUST be as shown in Figure 8-31.

Figure 8-31 Dynamic Service Addition — Response


Transaction ID Transaction ID from corresponding DSA-REQ.

Confirmation Code The appropriate Confirmation Code (refer to Section C.4) for the entire correspondingDSA-Request.


If the transaction is successful, the DSA-RSP MAY contain one or more of the following:

Classifier Parameters The CMTS MUST include the complete specification of the Classifier in the DSA-RSP, including a newly assigned Classifier Identifier. The CM MUST NOT include the specification of theClassifier in the DSA-RSP.

Service Flow Parameters The CMTS MUST include the complete specification of the Service Flow in theDSA-RSP, including a newly assigned Service Flow Identifier and an expanded service class name if applicable.The CM MUST NOT include the specification of the Service Flow in the DSA-RSP.

Payload Header Suppression Parameters The CMTS MUST include the complete specification of the PHSParameters in the DSA-RSP, including a newly assigned PHS Index, a Classifier Identifier, and a Service FlowIdentifier. The CM MUST NOT include the specification of the PHS Parameters.


Transaction ID

Bit 0 8 16 24 31

~

~

~

~

ConfirmationCode


158


If the transaction is unsuccessful due to Service Flow Parameters, Classifier Parameters, or Payload HeaderSuppression Parameters, and the Confirmation Code is not one of the major error codes in Section C.4.2, theDSA-RSP MUST contain at least one of the following:

Service Flow Error Set A Service Flow Error Set and identifying Service Flow Reference/Identifier MUSTbe included for at least one failed Service Flow in the corresponding DSA-REQ. Every Service Flow Error SetMUST include at least one specific failed QoS Parameter of the corresponding Service Flow. This parameterMUST be omitted if the entire DSA-REQ is successful.

Classifier Error Set A Classifier Error Set and identifying Classifier Reference/Identifier and Service FlowReference/Identifier pair MUST be included for at least one failed Classifier in the corresponding DSA-REQ.Every Classifier Error Set MUST include at least one specific failed Classifier Parameter of the correspondingClassifier. This parameter MUST be omitted if the entire DSA-REQ is successful.

Payload Header Suppression Error Set A PHS Error Set and identifying Classifier Reference/Identifier andService Flow Reference/Identifier pair MUST be included for at least one failed PHS Rule in the correspondingDSA-REQ. Every PHS Error Set MUST include at least one specific failed PHS Parameter of the correspondingfailed PHS Rule. This parameter MUST be omitted if the entire DSA-REQ is successful.

If Privacy is enabled, the DSA-RSP message MUST contain:



8.3.13.1 CM-Initiated Dynamic Service Addition

The CMTS’s DSA-Response for Service Flows that are successfully added MUST contain a Service Flow ID.The DSA-Response for successfully Admitted or Active upstream QoS Parameter Sets MUST also contain aService ID.

If the corresponding DSA-Request uses the Service Class Name (refer to Section C.2.2.3.4) to request serviceaddition, a DSA-Response MUST contain the QoS Parameter Set associated with the named Service Class. If theService Class Name is used in conjunction with other QoS Parameters in the DSA-Request, the CMTS MUSTaccept or reject the DSA-Request using the explicit QoS Parameters in the DSA-Request. If these Service FlowEncodings conflict with the Service Class attributes, the CMTS MUST use the DSA-Request values as overridesfor those of the Service Class.

If the transaction is successful, the CMTS MUST assign a Classifier Identifier to each requested Classifier and aPHS Index to each requested PHS Rule. The CMTS MUST use the original Classifier Reference(s) and ServiceFlow Reference(s) to link the successful parameters in the DSA-RSP.

If the transaction is unsuccessful, the CMTS MUST use the original Classifier Reference(s) and Service FlowReference(s) to identify the failed parameters in the DSA-RSP.

8.3.13.2 CMTS-Initiated Dynamic Service Addition

If the transaction is unsuccessful, the CM MUST use the Classifier Identifier(s) and Service Flow Identifier(s) toidentify the failed parameters in the DSA-RSP.

159


8.3.14 Dynamic Service Addition — Acknowledge (DSA-ACK)

A Dynamic Service Addition Acknowledge MUST be generated in response to a received DSA-RSP. The formatof a DSA-ACK MUST be as shown in Figure 8-32.

Figure 8-32 Dynamic Service Addition — Acknowledge


Transaction ID Transaction ID from corresponding DSA-Response.

Confirmation Code The appropriate Confirmation Code (refer to Section C.4) for the entire correspondingDSA-Response.1


Service Flow Error Set The Service Flow Error Set of the DSA-ACK message encodes specifics of failedService Flows in the DSA-RSP message. A Service Flow Error Set and identifying Service Flow Reference/Identifier MUST be included for at least one failed QoS Parameter of at least one failed Service Flow in thecorresponding DSA-REQ. This parameter MUST be omitted if the entire DSA-REQ is successful.

If Privacy is enabled, the DSA-RSP message MUST contain:



1. The confirmation code is necessary particularly when a Service Class Name (refer to Section 10.1.3) is usedin the DSA-Request. In this case, the DSA-Response could contain Service Flow parameters that the CM isunable to support (either temporarily or as configured).


Transaction ID

Bit 0 8 16 24 31

~

~

~

~

ConfirmationCode


160


8.3.15 Dynamic Service Change — Request (DSC-REQ)

A Dynamic Service Change Request MAY be sent by a CM or CMTS to dynamically change the parameters ofan existing Service Flow. DSCs changing classifiers MUST carry the entire classifier TLV set for that newclassifier.

Figure 8-33 Dynamic Service Change — Request

A CM or CMTS MUST generate DSC-REQ messages in the form shown in Figure 8-33 including the followingparameters:


All other parameters are coded as TLV tuples as defined in Annex C. A DSC-REQ message MUST NOT carryparameters for more than one Service Flow in each direction, i.e., a DSC-REQ message MUST containparameters for either a single upstream Service Flow, or for a single downstream Service Flow, or for oneupstream and one downstream Service Flow. A DSC-REQ MUST contain at least one of the following:

Classifier Parameters Specification of the rules to be used to classify packets into a specific service flow -this includes the Dynamic Service Change Action TLV which indicates whether this Classifier should be added,replaced or deleted from the Service Flow (refer to C.2.1.3.7). If included, the Classifier Parameters MUSTcontain the Dynamic Change Action TLV, a Classifier Reference/Identifier and a Service Flow Identifier:

Service Flow Parameters Specification of the Service Flow’s new traffic characteristics and schedulingrequirements. The Admitted and Active Quality of Service Parameter Sets in this message replace the Admittedand Active Quality of Service Parameter Sets currently in use by the Service Flow. If the DSC message issuccessful and it contains Service Flow parameters, but does not contain replacement sets for both Admitted andActive Quality of Service Parameter Sets, the omitted set(s) MUST be set to null. If included, the Service FlowParameters MUST contain a Service Flow Identifier.

Payload Header Suppression Parameters Specification of the rules to be used for Payload HeaderSuppression to suppress payload headers related to a specific Classifier—this includes the Dynamic ServiceChange Action TLV which indicates whether this PHS Rule should be added, set or deleted from the ServiceFlow or whether all the PHS Rules for the Service Flow specified should be deleted (refer to Section C.2.2.8.5).If included, the PHS parameters MUST contain the Dynamic Service Change Action TLV, a Classifier


Transaction ID

Bit 0 8 16 24 31

~

~

~

~


161


Reference/Identifier, and a Service Flow Identifier, unless the Dynamic Service Change Action is “Delete allPHS Rules”. If the Dynamic Service Change Action is “Delete all PHS Rules”, the PHS Parameters MUSTcontain a Service Flow Identifier along with the Dynamic Service Change Action, and no other PHS parametersneed be present in this case. However, if other PHS parameters are present, in particular Payload HeaderSuppression Index, they MUST be ignored by the receiver of the DSC-REQ message.

If Privacy is enabled, a DSC-REQ MUST also contain:



8.3.16 Dynamic Service Change — Response (DSC-RSP)

A Dynamic Service Change Response MUST be generated in response to a received DSC-REQ. The format of aDSC-RSP MUST be as shown in Figure 8-34

Figure 8-34 Dynamic Service Change — Response


Transaction ID Transaction ID from corresponding DSC-REQ

Confirmation Code The appropriate Confirmation Code (refer to Section C.4) for the corresponding DSC-Request.


If the transaction is successful, the DSC-RSP MAY contain one or more of the following:


Transaction ID

Bit 0 8 16 24 31

~

~

~

~

ConfirmationCode


162


Classifier Parameters The CMTS MUST include the complete specification of the Classifier in the DSC-RSP, including a newly assigned Classifier Identifier for new Classifiers. The CM MUST NOT include thespecification of the Classifier in the DSC-RSP.

Service Flow Parameters The CMTS MUST include the complete specification of the Service Flow in theDSC-RSP, including an expanded service class name if applicable. The CMTS MUST include a SID in the DSC-RSP if a Service Flow Parameter Set contained an upstream Admitted QoS Parameter Set and this Service Flowdoes not have an associated SID. If a Service Flow Parameter set contained a Service Class Name and anAdmitted QoS Parameter Set, the CMTS MUST include the QoS Parameter Set corresponding to the namedService Class in the DSC-RSP. If specific QoS Parameters were also included in the classed Service Flowrequest, the CMTS MUST include these QoS Parameters in the DSC-RSP instead of any QoS Parameters of thesame type of the named Service Class. The CM MUST NOT include the specification of the Service Flow in theDSC-RSP.

Payload Header Suppression Parameters The CMTS MUST include the complete specification of the PHSParameters in the DSC-RSP, including a newly assigned PHS Index for new PHS rules, a Classifier Identifier anda Service Flow Identifier. The CM MUST NOT include the specification of the PHS Parameters.

If the transaction is unsuccessful due to Service Flow Parameters, Classifier Parameters, or Payload HeaderSuppression Parameters, and the Confirmation Code is not one of the major error codes in C.4.2, the DSC-RSPMUST contain at least one of the following:

Classifier Error Set A Classifier Error Set and identifying Classifier Reference/Identifier and Service FlowReference/Identifier pair MUST be included for at least one failed Classifier in the corresponding DSC-REQ.Every Classifier Error Set MUST include at least one specific failed Classifier Parameter of the correspondingClassifier. This parameter MUST be omitted if the entire DSC-REQ is successful.

Service Flow Error Set A Service Flow Error Set and identifying Service Flow ID MUST be included for atleast one failed Service Flow in the corresponding DSC-REQ. Every Service Flow Error Set MUST include atleast one specific failed QoS Parameter of the corresponding Service Flow. This parameter MUST be omitted ifthe entire DSC-REQ is successful.

Payload Header Suppression Error Set A PHS Error Set and identifying Service Flow Reference/Identifierand Classifier Reference/Identifier pair MUST be included for at least one failed PHS Rule in the correspondingDSC-REQ, unless the Dynamic Service Change Action is “Delete all PHS Rules.” If the Dynamic ServiceChange Action is “Delete all PHS Rules” the PHS Error Set(s) MUST include an identifying Service Flow ID.Every PHS Error Set MUST include at least one specific failed PHS Parameter of the corresponding failed PHSRule. This parameter MUST be omitted if the entire DSC-REQ is successful.”

Regardless of success or failure, if Privacy is enabled for the CM the DSC-RSP MUST contain:



163


8.3.17 Dynamic Service Change — Acknowledge (DSC-ACK)

A Dynamic Service Change Acknowledge MUST be generated in response to a received DSC-RSP. The formatof a DSC-ACK MUST be as shown in Figure 8-35.

Figure 8-35 Dynamic Service Change — Acknowledge


Transaction ID Transaction ID from the corresponding DSC-REQ

Confirmation Code The appropriate Confirmation Code (refer to Section C.4) for the entire correspondingDSC-Response.1


Service Flow Error Set The Service Flow Error Set of the DSC-ACK message encodes specifics of failedService Flows in the DSC-RSP message. A Service Flow Error Set and identifying Service Flow IdentifierMUST be included for at least one failed QoS Parameter of at least one failed Service Flow in the correspondingDSC-REQ. This parameter MUST be omitted if the entire DSC-REQ is successful.

If Privacy is enabled, the DSC-ACK message MUST contain:



1. The Confirmation Code and Service Flow Error Set are necessary particularly when a Service Class Name is(refer to Section 10.1.3) used in the DSC-Request. In this case, the DSC-Response could contain Service Flowparameters that the CM is unable to support (either temporarily or as configured).


Transaction ID

Bit 0 8 16 24 31

~

~

~

~

ConfirmationCode


164


8.3.18 Dynamic Service Deletion — Request (DSD-REQ)

A DSD-Request MAY be sent by a CM or CMTS to delete a single existing Upstream Service Flow and/or asingle existing Downstream Service Flow. The format of a DSD-Request MUST be as shown in Figure 8-36.

Figure 8-36 Dynamic Service Deletion — Request


Service Flow Identifier If this value is non-zero, it is the SFID of a single Upstream or single DownstreamService Flow to be deleted. If this value is zero, the Service Flow(s) to be deleted will be identified by SFID(s) inthe TLVs. If this value is non-zero, any SFIDs included in the TLVs MUST be ignored.



Service Flow Identifier The SFID(s) to be deleted, which MUST be encoded per Section C.2.2.3.2. TheService Flow Identifier TLV MUST be the only Service Flow Encoding sub-TLV used.

If Privacy is enabled, the DSD-REQ MUST include:




Transaction ID

Bit 0 8 16 24 31

~

~

~

~

SFID


Reserved

165


8.3.19 Dynamic Service Deletion – Response (DSD-RSP)

A DSD-RSP MUST be generated in response to a received DSD-REQ. The format of a DSD-RSP MUST be asshown in Figure 8-37.

Figure 8-37 Dynamic Service Deletion — Response


Transaction ID Transaction ID from corresponding DSD-REQ.

Confirmation Code The appropriate Confirmation Code (refer to Section C.4) for the corresponding DSD-Request.

8.3.20 Dynamic Channel Change – Request (DCC-REQ)

A Dynamic Channel Change Request MAY be transmitted by a CMTS to cause a CM to change the upstreamchannel on which it is transmitting, the downstream channel it is receiving, or both.

A CMTS MUST generate DCC-REQ message in the form shown in Figure 8-38 including the followingparameter:

Figure 8-38 Dynamic Channel Change Request

~~

~~

ReservedConfirmationCode

Transaction ID

Bit 0 8 16 24 31




Bit 0 8 16 24 31

Transaction ID

166


Transaction ID A 16-bit unique identifier for this transaction assigned by the sender.

The following parameters are optional and are coded as TLV tuples.

Upstream Channel ID The identifier of the upstream channel to which the CM is to switch for upstreamtransmissions

Downstream Parameters The frequency of the downstream channel to which the CM is to switch fordownstream reception

Initialization Technique Directions for the type of initialization, if any, that the CM should perform oncesynchronized to the new channel(s)

UCD Substitution Provides a copy of the UCD for the new channel. This TLV occurs as many times asnecessary to contain one UCD.

SAID Substitution A pair of Security Association Identifiers (SAID) which contain the current SAID and thenew SAID for the new channel. This TLV occurs once if the SAID requires substitution.

Service Flow Substitution A group of sub-TLVs which allows substitution in a Service Flow of the ServiceFlow Identifier and Service Identifier. This TLV is repeated for every Service Flow which has parametersrequiring substitution.

If Privacy is enabled, a DCC-REQ MUST also contain:


HMAC-Digest The HMAC-Digest Attribute is a keyed message digest (to authenticate the sender). TheHMAC-Digest Attribute MUST be the final Attribute in the Dynamic Channel Change message’s Attribute list.(Refer to Section C.1.4.1)

8.3.20.1 Encodings

The type values used MUST be those shown below. These are unique within the Dynamic Channel ChangeRequest message, but not across the entire MAC message set.

If a CM performs a channel change without performing a re-initialization (as defined in Section 8.3.20.1.3), thenall the configuration variables of the CM MUST remain constant, with the exception of the configurationvariables which are explicitly changed below. The CM will not be aware of any configuration changes other thanthe ones that have been supplied in the DCC command, so consistency in provisioning between the old and newchannels is important.

8.3.20.1.1 Upstream Channel ID

When present, this TLV specifies the new upstream channel ID that the CM MUST use when performing aDynamic Channel Change. It is an override for the current upstream channel ID. The CMTS MUST ensure thatthe Upstream Channel ID for the new channel is different than the Upstream Channel ID for the old channel.This TLV MUST be included if the upstream channel is changed, even if the UCD substitution TLV is included.

Type Length Value

1 1 0-255: Upstream Channel ID

167


If this TLV is missing, the CM MUST NOT change its upstream channel ID. The CMTS MAY include this TLV.The CM MUST observe this TLV.

8.3.20.1.2 Downstream Parameters

When present, this TLV specifies the operating parameters of the new downstream channel. The value field ofthis TLV contains a series of sub-types.

The CMTS MUST include this TLV when specifying a downstream channel change. If this TLV is missing, theCM MUST NOT change its downstream parameters.

8.3.20.1.2.1 Downstream Frequency

This TLV specifies the new receive frequency that the CM MUST use when performing a Dynamic ChannelChange. It is an override for the current downstream channel frequency. This is the center frequency of thedownstream channel in Hz and is stored as a 32-bit binary number. The downstream frequency MUST be amultiple of 62,500 Hz.

The CMTS MUST include this sub-TLV. The CM MUST observe this sub-TLV.

8.3.20.1.2.2 Downstream Modulation Type

This TLV specifies the modulation type that is used on the new downstream channel.

The CMTS SHOULD include this sub-TLV. The CM SHOULD observe this sub-TLV.

8.3.20.1.2.3 Downstream Symbol Rate

This TLV specifies the symbol rate that is used on the new downstream channel.


Type Length Value

2 n

Subtype Length Value

2.1 4 Rx Frequency


2.2 1 0 = 64 QAM

1 = 256 QAM

2 - 255: reserved


2.3 1 0 = 5.056941 Msym/sec

1 = 5.360537 Msym/sec

2 = 6.952 Msym/sec

3 - 255: reserved

168


8.3.20.1.2.4 Downstream Interleaver Depth

This TLV specifies the parameters “I” and J of the downstream interleaver.


8.3.20.1.2.5 Downstream Channel Identifier

This TLV specifies the 8 bit downstream channel identifier of the new downstream channel.


8.3.20.1.2.6 SYNC Substitution

When present, this TLV allows the CMTS to inform the CM to wait or not wait for a SYNC message beforeproceeding. The CMTS MUST have synchronized timestamps between the old and new channel(s) if it instructsthe CM not to wait for a SYNC message before transmitting on the new channel. Synchronized timestampsimplies that the timestamps are derived from the same clock and contain the same value.

If this TLV is absent, the CM MUST wait for a SYNC message on the new channel before proceeding. If the CMhas to wait for a new SYNC message when changing channels, then operation may be suspended for a time up tothe “SYNC Interval” (see Annex B) or longer, if the SYNC message is lost or is not synchronized with the oldchannel(s).

An alternative approach is to send SYNC messages more frequently (every 10 ms for example), and continue torequire the CM to wait for a SYNC message before proceeding. This approach has slightly more latency, butprovides an additional check to prevent the CM from transmitting at an incorrect time interval.

The CMTS MUST include this TLV for initialization technique of option two, option three, or option four. TheCM MUST observe this TLV.

8.3.20.1.3 Initialization Technique

When present, this TLV allows the CMTS to direct the CM as to what level of re-initialization, if any, it MUSTperform before it can commence communications on the new channel(s). The CMTS can make this decisionbased upon its knowledge of the differences between the old and new MAC domains and the PHY characteristicsof their upstream and downstream channels.

Typically, if the move is between upstream and/or downstream channels within the same MAC domain, then theconnection profile values may be left intact. If the move is between different MAC domains, then a completeinitialization may be performed.


2.4 2 I: 0-255

J: 0-255


2.5 1 0-255: Downstream Channel ID.

Type Length Value

2.6 1 0 = acquire SYNC message on the new downstream channel before proceeding

1 = proceed without first obtaining the SYNC message

2 - 255: reserved

169


If a complete re-initialization is not required, some re-ranging may still be required. For example, areas ofupstream spectrum are often configured in groups. A DCC-REQ to an adjacent upstream channel within a groupmay not warrant re-ranging. Alternatively, a DCC-REQ to a non-adjacent upstream channel might requireunicast initial ranging whereas a DCC-REQ from one upstream channel group to another might require broadcastinitial ranging. Re-ranging may also be required if there is any difference in the PHY parameters between the oldand new channels.

The CM MUST first select the new upstream and downstream channels based upon the Upstream Channel IDTLV (refer to Section 8.3.20.1.1) and the Downstream Frequency TLV (refer to Section 8.3.20.1.2.1). Then theCM MUST follow the directives of this TLV. For option 0, the CM MUST begin with the Initialization SID. Foroptions 1 to 4 the CM MUST continue to use the primary SID for ranging. A SID Substitution TLV (see Section8.3.20.1.6.2) may specify a new primary SID for use on the new channel (refer to Section 8.3.20.1.6.2).

In order for the CMTS to send a DCC-REQ with downstream channel change and with initialization technique ofoption 2, option 3, or option 4, the CMTS MUST synchronize timestamps (and downstream symbol clocks for S-CDMA support) across the downstream channels involved and specify SYNC substitution sub-TLV with a valueof 1.

In order for the CMTS to send a DCC-REQ with upstream channel change and initialization technique of option2, option 3, or option 4, the CMTS MUST include the UCD substitution in the DCC message.

The CMTS MUST specify initialization technique option zero or option 1 in a DCC-REQ message requiring amodem to switch between S-CDMA and TDMA (and vice versa).

Type Length Value

3 1 0 = Reinitialize the MAC

1 = Perform broadcast initial ranging on new channel before normal operation

2 = Perform unicast initial ranging on new channel before normal operation

3 = Perform either broadcast initial ranging or unicast initial ranging on newchannel before normal operation

4 = Use the new channel(s) directly without re-initializing or initial ranging

5 - 255: reserved

Option 0: This option directs the CM to perform all the operations associated with initializing the CM(refer to Section 11.2). This includes all the events after acquiring downstream QAM, FEC,and MPEG lock and before Standard Operation (refer to Section 11.3), including obtaining aUCD, ranging, establishing IP connectivity, establishing time of day, transfer of operationalparameters, registration, and baseline privacy initialization. When this option is used, the onlyother TLVs in DCC-REQ that are relevant are the Upstream Channel ID TLV and theDownstream Parameters TLV. All other DCC-REQ TLVs are irrelevant.

Option 1: If broadcast initial ranging is specified, operation on the new channel could be delayed by sev-eral Ranging Intervals (see Annex B).

Option 2: If unicast initial ranging is specified, operation on the new channel could be delayed by the val-ue of T4 (see Annex B).

Option 3: This value authorizes a CM to use an initial maintenance or station maintenance region, which-ever the CM selects. This value might be used when there is uncertainty when the CM may ex-ecute the DCC command and thus a chance that it might miss station maintenance slots.

Option 4: This option provides for the least interruption of service, and the CM may continue its normaloperation as soon as it has achieved synchronization on the new channel. This option isintended for use with a near-seamless channel change (refer to Section 11.4.5.4).

Note: This option should not be used in physical plants where upstream transmission characteristics arenot consistent.

170


If this TLV is absent, the CM MUST re-initialize the MAC. The CMTS MAY include this TLV. The CM MUSTobserve this TLV.

8.3.20.1.4 UCD Substitution

When present, this TLV allows the CMTS to send an Upstream Channel Descriptor message to the CM. ThisUCD message is intended to be associated with the new upstream and/or downstream channel(s). The CM storesthis UCD message in its cache, and uses it after synchronizing to the new channel(s).

This TLV includes all parameters for the UCD message as described in Section 8.3.3 except for the MACManagement Message Header. The CMTS MUST ensure that the change count in the UCD matches the changecount in the UCDs of the new channel(s). The CMTS MUST ensure that the Upstream Channel ID for the newchannel is different than the Upstream Channel ID for the old channel. The Ranging Required parameter in thenew UCD does not apply in this context, since the functionality is covered by the Initialization Technique TLV.

If the length of the UCD exceeds 254 bytes, the UCD MUST be fragmented into two or more successive Type 4elements. Each fragment, except the last, MUST be 254 bytes in length. The CM reconstructs the UCDSubstitution by concatenating the contents (Value of the TLV) of successive Type 4 elements in the order inwhich they appear in the DCC-REQ message. For example, the first byte following the length field of the secondType 4 element is treated as if it immediately follows the last byte of the first Type 4 element.

If the CM has to wait for a new UCD message when changing channels, then operation may be suspended for atime up to the “UCD Interval” (see Annex B) or longer, if the UCD message is lost.

The CMTS MUST include this TLV when specifying an initialization technique of option 2, option 3, or option4. The CM MUST observe this TLV.

8.3.20.1.5 Security Association Identifier (SAID) Substitution

When present, this TLV allows the CMTS to replace the Security Association Identifier (SAID) in the currentService Flow with a new Security Association Identifier. The baseline privacy keys associated with the SAIDMUST remain the same. The CM does not have to simultaneously respond to the old and new SAID.

If this TLV is absent, the current Security Association Identifier assignment is retained. The CMTS MAY includethis TLV. The CM MUST observe this TLV.

8.3.20.1.6 Service Flow Substitutions

When present, this TLV allows the CMTS to replace specific parameters within the current Service Flows on thecurrent channel assignment with new parameters for the new channel assignment. One TLV is used for eachService Flow that requires changes in parameters. The CMTS may choose to do this to help facilitate setting upnew QoS reservations on the new channel before deleting QoS reservations on the old channel. The CM does nothave to simultaneously respond to the old and new Service Flows.

Type Length Value

4 n UCD for the new upstream channel

Type Length Value

6 4 current SAID (lower-order 14 bits of a 16-bit field), new SAID (lower-order 14 bitsof a 16-bit field)

171


This TLV allows resource assignments and services to be moved between two independent ID value spaces andscheduling entities by changing the associated IDs and indices. ID value spaces that may differ between the twochannels include the Service Flow Identifier and the Service ID. This TLV does not allow changes to ServiceFlow QoS parameters.

The Service Class Names used within the Service Flow ID should remain identical between the old and newchannels.

If this TLV is absent for a particular Service Flow, then current Service Flow and its attributes are retained. TheCMTS MAY include this TLV. The CM MUST observe this TLV.

8.3.20.1.6.1 Service Flow Identifier Substitution

This TLV allows the CMTS to replace the current Service Flow Identifier (SFID) with a new Service FlowIdentifier. Refer to Section C.2.2.3.2 for usage details.

This TLV MUST be present if any other Service Flow subtype substitutions are made. If this TLV is included andthe Service Flow ID is not changing, then the current and new Service Flow ID will be set to the same value.

The CMTS MUST include this Sub-TLV. The CM MUST observe this Sub-TLV.

8.3.20.1.6.2 Service Identifier Substitution

When present, this TLV allows the CMTS to replace the Service Identifier (SID) in the current upstream ServiceFlow with a new Service Identifier. Refer to Section C.2.2.3.3 for usage details.

If this TLV is absent, the current Service Identifier assignments are retained. The CMTS MAY include this TLV.The CM MUST observe this TLV.

8.3.20.1.6.3 Unsolicited Grant Time Reference Substitution

When present, this TLV allows the CMTS to replace the current Unsolicited Grant Time Reference with a newUnsolicited Grant Time Reference. Refer to Section C.2.2.6.11 for usage details.

This TLV is useful if the old and new upstream use different time bases for their time stamps. This TLV is alsouseful if the Unsolicited Grant transmission window is moved to a different point in time. Changing this valuemay cause operation to temporarily exceed the jitter window specified by Section C.2.2.6.8.

If this TLV is absent, the current Unsolicited Grant Time Reference is retained. The CMTS MAY include thisTLV. The CM MUST observe this TLV.

Type Length Value

7 n list of subtypes


7.1 8 current Service Flow ID, new Service Flow ID


7.2 4 current SID (lower-order 14 bits of a 16-bit field), new SID (lower-order 14 bits ofa 16-bit field)


7.5 4 new reference

172


8.3.20.1.7 CMTS MAC Address

When present, this TLV allows the current CMTS to send the MAC address of the destination CMTScorresponding to the target downstream frequency. This TLV MUST be specified if the CM is changingdownstream channels and UCD substitution is specified or if the CM is changing downstream channels andusing initialization technique 4, use the new channel(s) directly.

The CMTS SHOULD include the CMTS MAC address TLV. The CM SHOULD observe the CMTS MACaddress TLV.

8.3.21 Dynamic Channel Change – Response (DCC-RSP)

A Dynamic Channel Change Response MUST be transmitted by a CM in response to a received DynamicChannel Change Request message to indicate that it has received and is complying with the DCC-REQ. Theformat of a DCC-RSP message MUST be as shown in Figure 8-39.

Before it begins to switch to a new upstream or downstream channel, a CM MUST transmit a DCC-RSP on itsexisting upstream channel. When a CM receives a DCC-REQ message requesting that it switch to an upstreamand downstream channel that it is already using or requesting that it switch to only an upstream or downstreamchannel that it is already using, the CM MUST respond with a DCC-RSP message on that channel indicating thatit is already using the correct channel.

A CM MAY ignore a DCC-REQ message while it is in the process of performing a channel change.

After switching to a new channel, if the MAC was not re-initialized per DCC-REQ Initialization TLV, option 0,the CM MUST send a DCC-RSP message to the CMTS. A DCC-RSP MUST NOT be sent if the CM reinitializesits MAC.

The full procedure for changing channels is described in Section 11.4.5.


Transaction ID A 16-bit Transaction ID from corresponding DCC-REQ

Type Length Value

8 6 MAC Address of Destination CMTS

Figure 8-39 Dynamic Channel Change Response


Bit 0 8 16 24 31

Transaction IDConfirmation

Code


173


Confirmation Code An 8-bit Confirmation Code as described in Section C.4.1

The following parameters are optional and are coded as TLV tuples.

CM Jump Time Timing parameters describing when the CM will make the jump

Regardless of success or failure, if Privacy is enabled for the CM the DCC-RSP MUST contain:

Key Sequence Number The key sequence number of the Auth Key, which is used to calculate the HMAC-Digest (refer to Section C.1.4.3)


8.3.21.1 Encodings

The type values used MUST be those shown below. These are unique within the Dynamic Channel ChangeResponse message, but not across the entire MAC message set.

8.3.21.1.1 CM Jump Time

When present, this TLV allows the CM to indicate to the CMTS when the CM plans to perform its jump and bedisconnected from the network. With this information, the CMTS MAY take preventative measures to minimizeor to eliminate packet drops in the downstream due to the channel change.

The time reference and units of time for these sub-TLVs is based upon the same 32-bit time base used in theSYNC message on the current downstream channel. This timestamp is incremented by a 10.24 MHz clock

The CM SHOULD include this TLV. The CMTS SHOULD observe this TLV.

8.3.21.1.1.1 Length of Jump

This TLV indicates to the CMTS the length of the jump from the previous channel to the new channel.Specifically, it represents the length of time that the CM will not be able to receive data in the downstream.

The CM MUST include this sub-TLV.

8.3.21.1.1.2 Start Time of Jump

When present, this TLV indicates to the CMTS the time in the future that the CM is planning on making thejump.

Type Length Value

1 n


1 4 length (based upon timestamp)


2 8 start time (based upon timestamp), accuracy of start time (based upon timestamp)

174


The 32-bit, 10.24 MHz time base rolls over approximately every 7 minutes. If the value of the start time is lessthan the current timestamp, the CMTS will assume one roll-over of the timestamp counter has elapsed. Theaccuracy of the start time is an absolute amount of time before and after the start time.

The potential jump window is from (start time - accuracy) to (start time + accuracy + length).

The CM SHOULD include this TLV.

8.3.22 Dynamic Channel Change – Acknowledge (DCC-ACK)

A Dynamic Channel Change Acknowledge MUST be transmitted by a CMTS in response to a received DynamicChannel Change Response message on the new channel with its Confirmation Code set to arrive(1). The formatof a DCC-ACK message MUST be as shown in Figure 8-40.


Transaction ID A 16 bit Transaction ID from corresponding DCC-RSP.

If Privacy is enabled, the DCC-ACK message MUST contain:



Figure 8-40 Dynamic Channel Change Acknowledge


Bit 0 8 16 24 31

Transaction ID


175


8.3.23 Device Class Identification Request (DCI-REQ)

A CM MAY implement the DCI-REQ message.

When implemented, a CM MUST transmit a DCI-REQ immediately following receipt of a ranging completeindication from the CMTS. A CM MUST NOT continue with initialization until a DCI-RSP message is receivedfrom the CMTS. Timeout and retry information is provided in Annex B.

The DCI-REQ MUST be formatted as shown in Figure 8-41.

Figure 8-41 Device Class Identification Request


SID The temporary SID assigned during Ranging

Device Class This is a 32-bit field where individual bits represent individual attributes of the CM. Bit #0 is theLSB of the field. Bits are set to 1 to select the attributes defined below.

bit #0 CPE Controlled Cable Modem (CCCM)

bits #1-31 reserved and must be set to zero

8.3.24 Device Class Identification Response (DCI-RSP)

A DCI-RSP MUST be transmitted by a CMTS in response to a received DCI-REQ.

The DCI-RSP MUST be formatted as shown in Figure 8-42.


Bit 0 8 16 24 31

~

~

~

~


SID Device Class

Device Class (con't)

176


Figure 8-42 Device Class Identification Response


SID The SID received in the associated DCI-REQ

Device Class The device class field as received in the associated DCI-REQ

Confirmation Code Refer to Section C.4, “Confirmation Code,” on page 367).

The CMTS MUST use only one of 3 confirmation codes in the DCI-RSP.

• If the response is reject-temporary(3), the CM MUST reset its DCI-REQ retry counter to zero and MUSTresend the DCI-REQ and wait for the DCI-RSP before proceeding.

• If the response is reject-permanent(4), the CM MUST abort this registration attempt and MUST begin rescan-ning for a different downstream channel. The CM MUST NOT retry this channel until it has tried all otherDOCSIS downstream channels on the network.

• If the response is success(0), the CM MUST continue with registration.

The CMTS MUST retain the device class information for use in the DHCP Process. The CMTS MUST create aDHCP Agent Option 82 tuple with the device class information and MUST insert this tuple in theDHCPDISCOVER from the corresponding CM before forwarding that DHCPDISCOVER to the DHCP server.

8.3.25 Upstream Transmitter Disable (UP-DIS) MAC Management Message

The UP-DIS message provides additional functionality to permanently or temporarily disable the modem, as wellas to disable the modem for a specified period of time. It is used to control the admission of certain modem typesand groups to the network as early as immediately before registration. It can also be used for networktroubleshooting, disabling modems that violate network policies, or for avoiding request floods in a largenetwork when the CMTS goes on-line.


Bit 0 8 16 24 31

~

~

~

~


SID Device Class

Device Class (con't)Confirmation

Code

177


This message is stateless and can be issued by the CMTS at any time. The UP-DIS message is sent from a CMTSto a CM; there is no response from the CM transmitted back to the CMTS. UP-DIS messages may be unicast, inwhich case the destination address in the MAC header is the address of the selected CM, or multicast, in whichcase the destination address is a well-known MAC multicast address (see Annex A for details on well-knownaddresses).

The CMTS MUST be capable of transmitting the UP-DIS message. The CMTS can transmit UP-DIS messageseither as a result of a triggering event detected by the CMTS internally, or in response to a remote managementcommand. Mechanisms for setting up, detecting, and reporting situations where the transmission of an UP-DISmessage might be appropriate are implementation dependent. Similarly, signaling, which remotely instructs theCMTS to transmit a UP-DIS message, is outside the scope of this specification. One of the possibleimplementations may be SNMP commands sent to the CMTS over the network.

CMs SHOULD support the UP-DIS message in order to ease network management.

Since the UP-DIS mechanism at the CM is stateless and the CMs do not retain disabled status after a powercycle, the CMTS MAY incorporate mechanisms to track disabled CMs by their MAC addresses. The CMTSwould resend an UP-DIS message as appropriate to the modems that were permanently disabled by the networkoperator, and then power cycled by the user in an attempt to re-register. However, the same function may also beimplemented by the provisioning infrastructure on modem registration; therefore, if the CMTS is unable to trackdisabled modems autonomously, it SHOULD be able to send a UP-DIS in response to an external command.

The UP-DIS message MUST be formatted as shown in Figure 8-43.

Figure 8-43 UP-DIS message format

The only parameter is UP-DIS TimeoutTST-REQ Interval, which MUST be encoded as follows.

UP-DIS Timeout Interval is a 32-bit, unsigned integer representing the disable timeout interval in milliseconds.There are two special values defined:

00000000 permanently disables the upstream of the modem, as described below.

FFFFFFFF remotely reinitializes the MAC, which resumes the normal operation of the modem.

The CM MUST autonomously disable its upstream transmitter immediately upon receipt of an UP-DIS messagewith UP-DIS Timeout Interval = 0, regardless of any other transaction state (refer to Section 11), or the state ofits control program. The modem stops all transmissions, but continues to listen to the MAC messages sent in thedownstream. Once disabled, the CM upstream transmitter MUST only be re-enabled by power cycling the CM,or by an UP-DIS message with UP-DIS Timeout Interval = FFFFFFFF. All other UP-DIS messages MUST beignored when the upstream is disabled.


Bit 0 8 16 24 31

UP-DIS Timeout Interval (0=Off Forever, FFFFFFFF=On)

178


If supported, the CM MUST autonomously reset its upstream transmitter upon receipt of an UP-DIS messagewith UP-DIS Timeout Interval = FFFFFFFF, regardless of any other transaction state (refer to Section 11), or thestate of its control program. Resetting allows the modem to resume transmissions.

Additional non-zero timeout values in the UP-DIS message SHOULD be supported. If supported, the CMMUST autonomously disable its upstream transmitter immediately upon receipt of an UP-DIS message with UP-DIS Timeout Interval T > 0 for a period of T milliseconds, regardless of any other transaction state (refer toSection 11), or the state of its control program. Although the timeout T is specified in milliseconds, the CMMAY extend the specified timeout by up to 100 msec. When timeout expires, the CM SHOULD reinitialize theMAC as appropriate, starting with the initial ranging process and registration, because there is no guarantee thatthe CMTS has not de-registered it. In the disabled state, all other UP-DIS messages MUST be ignored, except foran UP-DIS message with UP-DIS Timeout Interval = FFFFFFFF or 00000000.

8.3.26 Initial Ranging Request (INIT-RNG-REQ)

A Ranging Request MUST be transmitted by a CM at initialization to determine network delay and requestpower adjustment. This message MUST use an FC_TYPE = MAC Specific Header and FC_PARM = TimingMAC Header. This MUST be followed by a Packet PDU in the format shown in Figure 8-44.

The INIT-RNG-REQ differs from the RNG-REQ in that it is only transmitted in Broadcast Initial RangingOpportunities and MUST NOT be transmitted on a logical Upstream that is not a DOCSIS 2.0-only Upstream. Italso has an upstream channel ID in place of the Pending Till Complete field in a RNG-REQ.

Figure 8-44 Packet PDU Following the Timing Header


SID

• Initialization SID if modem is attempting to join the network

• Initialization SID if modem has not yet registered and is changing downstream (or both downstreamand upstream) channels as directed by a downloaded parameter file

• Temporary SID if modem has not yet registered and is changing upstream (not downstream)channels as directed by a downloaded parameter file

• Registration SID (previously assigned in REG-RSP) if modem is registered and is changingupstream channels, or if the CM is redoing initial ranging because the upstream has changed to orfrom S-CDMA mode (refer to Section 11.3.2).

This is a 16-bit field of which the lower 14 bits define the SID with bits 14 and 15 defined to be 0.

Downstream Channel ID The identifier of the downstream channel on which the CM received the UCDwhich described this upstream. This is an 8-bit field.


SID

Bit 0 8 16 24 31

~

~

~

~

DownstreamChannel ID

UpsrtreamChannel ID

UpstreamChannel ID

179


Upstream Channel ID The Upstream Channel ID from the UCD the CM is using to transmit this INIT-RNG-REQ. In the case where multiple logical upstreams are sharing the same spectrum, and the Broadcast InitialRanging Opportunities of some of these logical channels are aligned, this allows the CMTS to know whichlogical channel the CM is using.

8.3.27 Test Request (TST-REQ)1

The Test Request is used to force a CM to enter or leave one of two test modes. The TST-REQ2 messagewith Mode != 0 MUST NOT be sent by the CMTS except in response to an explicit command from the operator.

Figure 8-45 Test Request


Mode 0 = Disable all test modes and reboot

1 = Transmit a continuous (non-bursted) upstream signal at the commanded modulation rate, carrierfrequency, and power level. The chip sequence at the spreader output is replaced with analternating binary sequence (1, -1, 1, -1, 1, -1, ...) at nominal amplitude, equal on I and Q. The CMtracks the downstream symbol clock and uses it to generate the upstream symbol clock as in normalsynchronous operation.

2 = Transmit a continuous (non-bursted), unmodulated (CW) upstream signal at the commandedcarrier frequency, modulation rate and power level. This is equivalent to replacing the chipsequence at the spreader output with the constant sequence (1, 1, 1, 1, 1, 1, ...) at nominalamplitude, equal on both I and Q. The CM tracks the downstream symbol clock and uses it togenerate the upstream symbol clock as in normal synchronous operation.

In normal operation, the CM MUST ignore any TST-REQ message it receives subsequent to receiving the firstSYNC message. Note that this makes it less convenient to use this test mode with a CMTS, since the CMTS maysend a SYNC message before the CM sees a TST-REQ message.

After acquiring a downstream signal, and prior to receiving a SYNC message, if the CM receives a TST-REQmessage (either unicast to the CM itself, or broadcast) with Mode != 0, the CM MUST begin the test modeindicated in the Mode parameter, using the channel parameters included in the TST-REQ message.

1. Section 8.3.27 added per RFI2-N-02102 by RKV on 10/28/02.2. Change “TEST” to “TST-REQ”, per ECN RFI2-N-02210, by GO, on 11/21/02.

Bit 8 16 24 310

TLV-EncodedInformation for the Channel

Mode


180


In test mode, if the CM receives a TST-REQ message (either unicast to the CM itself, or broadcast) with Mode =0, the CM MUST reboot. The CM MUST reboot after the expiration of the T16 timer, a 30 minute test modetimer.

The TST-REQ message MUST be generated in the format shown in Figure 8-45, including all of the parameterscoded as TLV multiples defined in Table 8-22.

Table 8-22 Channel TLV Parameters

NameType


Value(variable length)

Modulation Rate 1 1 Multiples of base rate of 160 kHzc. (Value is 1, 2, 4,8, 16, or 32.).

This TLV MUST be present if the test mode is 1.

Frequency 2 4 Upstream carrier frequency (Hz).

This TLV MUST be present if the test mode is 1 or 2.

Power 3 1 This TLV specifies the power (unsigned 8-bit, dBmVunits) at which the CM MUST transmit the TST-REQmessage.

This TLV MUST be present if the test mode is 1 or 2.

S-CDMA US ratio numerator ‘M’ 4 2 The numerator (M) of the M/N ratio relating thedownstream symbol clock to the upstreammodulation clock.

This TLV MUST be present if the test mode is 1. ThisTLV MUST be present if the test mode is 2 and theoperation is synchronous.

S-CDMA US ratio denominator‘N’

5 2 The denominator (N) of the M/N ratio relating thedownstream symbol clock to the upstreammodulation clock.

This TLV MUST be present if the test mode is 1. ThisTLV MUST be present if the test mode is 2 and theoperation is synchronous.

181



182


9 Media Access Control Protocol Operation

9.1 Upstream Bandwidth Allocation

The upstream channel is modeled as a stream of mini-slots. The CMTS MUST generate the time reference foridentifying these slots. It MUST also control access to these slots by the cable modems. For example, it MAYgrant some number of contiguous slots to a CM for it to transmit a data PDU. The CM MUST time itstransmission so that the CMTS receives it in the time reference specified. This section describes the elements ofprotocol used in requesting, granting, and using upstream bandwidth. The basic mechanism for assigningbandwidth management is the allocation MAP. Please refer to Figure 9-1.

The allocation MAP is a MAC Management message transmitted by the CMTS on the downstream channelwhich describes, for some interval, the uses to which the upstream mini-slots MUST be put. A given MAP MAYdescribe some slots as grants for particular stations to transmit data in, other slots as available for contentiontransmission, and other slots as an opportunity for new stations to join the link.

Many different scheduling algorithms MAY be implemented in the CMTS by different vendors; thisspecification does not mandate a particular algorithm. Instead, it describes the protocol elements by whichbandwidth is requested and granted.

Figure 9-1 Allocation Map

The bandwidth allocation includes the following basic elements:

• Each CM has one or more short (14-bit) service identifiers (SIDs) as well as a 48-bit address.

• Upstream bandwidth is divided into a stream of mini-slots. Each mini-slot is numbered relative to a masterreference maintained by the CMTS. The master reference is distributed to the CMs by means of SYNC andUCD packets (See Section 6.2.11.2, “Mini-slot Numbering,” on page 54).

• CMs may issue requests to the CMTS for upstream bandwidth.

CM tx opportunity CM tx opportunityrequest contention area

current mapprevious map

as-yetunmapped

time

mini-slots

maintenance

permitted use of the upstream channel

transmitted on downstream channel by the CMTSMap PDU

183


The CMTS MUST transmit allocation MAP PDUs on the downstream channel defining the allowed usage ofeach mini-slot. The MAP is described below.

9.1.1 The Allocation MAP MAC Management Message

The allocation MAP is a varying-length MAC Management message that is transmitted by the CMTS to definetransmission opportunities on the upstream channel. It includes a fixed-length header followed by a variablenumber of information elements (IEs) in the format shown in Section 8.3.4. Each information element definesthe allowed usage for a range of mini-slots.

Note: For TDMA channels, it should be understood by both CM and CMTS that the lower (26-M) bits of alloc start and acktimes MUST be used as the effective MAP start and ack times, where M is defined in Section 8.3.4. The relationship betweenalloc start/ack time counters and the timestamp counter is further described in Section 9.3.4. For DOCSIS 2.0 S-CDMAchannels the alloc start/ack time counters are defined in mini-slots which are related to the timestamp counter, frame counter,and S-CDMA timestamp snapshot as described in Section 6.2.11.2, “Mini-slot Numbering,” on page 54.

9.1.2 Information Elements

Each IE consists of a 14-bit Service ID, a 4-bit type code, and a 14-bit starting offset as defined in Section 8.3.4.Since all stations MUST scan all IEs, it is critical that IEs be short and relatively fixed format. IEs within theMAP are strictly ordered by starting offset. For most purposes, the duration described by the IE is inferred by thedifference between the IE’s starting offset and that of the following IE. For this reason, a Null IE MUSTterminate the list. Refer to Table 8-20.

Four types of Service IDs are defined:

1. 0x3FFF - broadcast, intended for all stations

2. 0x2000-0x3FFE - multicast, purpose is defined administratively. Refer to Annex A.

3. 0x0001-0x1FFF - unicast, intended for a particular CM or a particular service within that CM

4. 0x0000 - null address, addressed to no station

All of the Information Elements defined below MUST be supported by conformant CMs. Conformant CMTSesMAY use any of these Information Elements when creating Bandwidth Allocation Maps.

9.1.2.1 The Request IE

The Request IE provides an upstream interval in which requests MAY be made for bandwidth for upstream datatransmission. The character of this IE changes depending on the class of Service ID. If broadcast, this is aninvitation for CMs to contend for requests. Section 9.4 describes which contention transmit opportunity may beused. If unicast, this is an invitation for a particular CM to request bandwidth. Unicasts MAY be used as part of aQuality of Service scheduling scheme (refer to Section 10.2, “Upstream Service Flow Scheduling Services,” onpage 213). Packets transmitted in this interval MUST use the Request MAC Frame format (refer to Section8.2.5.3).

A small number of Priority Request SIDs are defined in Section A.2.3. These allow contention for Request IEs tobe limited to service flows of a given Traffic Priority. (Refer to Section C.2.2.5.1)

184


9.1.2.2 The Request/Data IE

The Request/Data IE provides an upstream interval in which requests for bandwidth or short data packets MAYbe transmitted. This IE is distinguished from the Request IE in that:

• It provides a means by which allocation algorithms MAY provide for “immediate” data contention underlight loads, and a means by which this opportunity can be withdrawn as network loading increases.

• Multicast Service IDs MUST be used to specify maximum data length, as well as allowed random startingpoints within the interval. For example, a particular multicast ID may specify a maximum of 64-byte datapackets, with transmit opportunities every fourth slot.

A small number of well-known multicast Service IDs are defined in Annex A. Others are available for vendor-specific algorithms.

Since data packets transmitted within this interval may collide, the CMTS MUST acknowledge any that aresuccessfully received. The data packet MUST indicate in the MAC Header that a data acknowledgment isdesired (see Table 8-13).

9.1.2.3 The Initial Maintenance IE

The Initial Maintenance IE, when used with the Broadcast SID, provides an interval in which new stations mayjoin the network. A long interval, equivalent to the maximum round-trip propagation delay plus the transmissiontime of a Ranging Request (RNG-REQ) message (see Section 9.3.3), MUST be provided to allow new stations toperform initial ranging. Packets transmitted in this interval MUST use the RNG-REQ or the INIT-RNG-REQMAC Management message format (refer to Section 8.3.5, “Ranging Request (RNG-REQ),” on page 143, andSection 8.3.26, “Initial Ranging Request (INIT-RNG-REQ),” on page 179).

On DOCSIS 2.0 Only Upstream Channels, the Initial Maintenance IE MAY be used with a unicast SID. This isdone to provide Unicast Initial Maintenance opportunities in place of Station Maintenance opportunities at thediscretion of the CMTS. This may be useful if the first unicast ranging opportunity on an S-CDMA channelneeds to have Spreader Off just like initial maintenance, but it is not desirable to impose the overhead of havingthe Spreader Off on routine Station Maintenance. Unicast Initial Maintenance Opportunities only need to belarge enough to allow transmission of the ranging request. The CMTS MUST NOT provide unicast InitialMaintenance opportunities on any logical upstream which is not a DOCSIS 2.0 Only Upstream.

9.1.2.4 The Station Maintenance IE

The Station Maintenance IE provides an interval in which stations are expected to perform some aspect ofroutine network maintenance, such as ranging or power adjustment. The CMTS MAY request that a particularCM perform some task related to network maintenance, such as periodic transmit power adjustment. In this case,the Station Maintenance IE is unicast to provide upstream bandwidth in which to perform this task. Packetstransmitted in this interval MUST use the RNG-REQ MAC Management message format (see Section 8.3.5).

9.1.2.5 Short and Long Data Grant IEs

The Short and Long Data Grant IEs provide an opportunity for a CM to transmit one or more upstream PDUs.These IEs are issued either in response to a request from a station, or because of an administrative policyproviding some amount of bandwidth to a particular station (see class-of-service discussion below). These IEsMAY also be used with an inferred length of zero mini slots (a zero length grant), to indicate that a request hasbeen received and is pending (a Data Grant Pending).

185


Short Data Grants are used with intervals less than or equal to the maximum burst size for this usage specified inthe Upstream Channel Descriptor. If Short Data burst profiles are defined in the UCD, then all Long Data GrantsMUST be for a larger number of mini-slots than the maximum for Short Data. The distinction between Long andShort Data Grants may be exploited in physical-layer forward-error-correction coding; otherwise, it is notmeaningful to the bandwidth allocation process.

If this IE is a Data Grant Pending (a zero length grant), it MUST follow the NULL IE. This allows cable modemsto process all actual allocations first, before scanning the Map for data grants pending and dataacknowledgments.

9.1.2.6 Data Acknowledge IE

The Data Acknowledge IE acknowledges that a data PDU was received. The CM MUST have requested thisacknowledgment within the data PDU (normally this would be done for PDUs transmitted within a contentioninterval in order to detect collisions).

This IE MUST follow the NULL IE. This allows cable modems to process all actual interval allocations first,before scanning the Map for data grants pending and data acknowledgments.

9.1.2.7 Expansion IE

The Expansion IE provides for extensibility, if more than 16 code points or 32 bits are needed for future IEs.

9.1.2.8 Null IE

A Null IE terminates all actual allocations in the IE list. It is used to infer a length for the last interval. All DataAcknowledge IEs and All Data Grant Pending IEs (Data Grants with an inferred length of 0) must follow theNull IE.

9.1.2.9 Advanced PHY Short and Long Data Grant IEs

These IEs are the Advanced PHY channel equivalent of the Short and Long Data Grant IEs in Section 9.1.2.5. Inaddition, these IEs allow DOCSIS 2.0 modems operating in DOCSIS 2.0 TDMA mode to share the sameupstream channel with DOCSIS 1.x modems. Modems registered in DOCSIS 1.x mode MUST NOT use theseintervals.

For upstream channels supporting a mixture of DOCSIS 1.x and DOCSIS 2.0 TDMA CMs, the CMTS MUSTuse the SID in the request and the operational state of the CM to distinguish between requests for IUC 5 & 6 datagrants and requests for IUC 9 & 10 data grants. (Refer to Section 11.2.9 for additional information). Once thisdistinction has been made, the CMTS then uses the request size to distinguish between a long grant and a shortgrant.

Once a CMTS has received a REG_ACK from a 2.0 CM on a type 2 channel, the CMTS MUST NOT send datagrants using IUCs 5 or 6 if either IUC 9 or 10 is defined for that upstream channel. This restriction allows theCM to support only 7 burst profiles simultaneously.

9.1.2.10 Advanced PHY Unsolicited Grant IE

This IE can be used by the CMTS to make unsolicited grants of bandwidth to DOCSIS 2.0 CMs. If a significantportion of the traffic for an upstream is going to consist of unsolicited grants of a particular size, this IE providesa way for the CMTS to provide a set of physical layer parameters (such as code word length and FEC length)well tailored to that traffic, without compromising the general usefulness of the Advanced Phy Short or

186


Advanced Phy Long Data Grant IEs. It is never used by the CM to calculate the size of a bandwidth request. TheCMTS MUST NOT use it to make grants to DOCSIS 1.x CMs.

9.1.3 Requests

Requests refer to the mechanism that CMs use to indicate to the CMTS that it needs upstream bandwidthallocation. A Request MAY come as a stand-alone Request Frame transmission (refer to Section 8.2.5.3) or itMAY come as a piggyback request in the EHDR of another Frame transmission (refer to Section 8.2.6).

The Request Frame MAY be transmitted during any of the following intervals:

• Request IE

• Request/Data IE

• Short Data Grant IE

• Long Data Grant IE

• Adv PHY Short Data Grant IE

• Adv PHY Long Data Grant IE

• Adv PHY Unsolicited Grant IE

A piggyback request MAY be contained in the following Extended Headers:

• Request EH element

• Upstream Privacy EH element

• Upstream Privacy EH element with Fragmentation

The request MUST include:

• The Service ID making the request

• The number of mini-slots requested

The CM MUST request the number of mini-slots needed to transmit an entire frame, or a fragment containing theentire remaining portion of a frame that a previous grant has caused to be fragmented. The frame may be a singleMAC frame, or a MAC frame that has been formed by the concatenation of multiple MAC frames (see Section8.2.5.5). The request from the CM MUST be large enough to accommodate the entire necessary physical layeroverhead (see Section 6.2) for transmitting the MAC frame or fragment. The CM MUST NOT make a requestthat would violate the limits on data grant sizes in the UCD message (see Section 8.3.3) or any limits establishedby QOS parameters associated with the Service Flow.1

The CM MUST NOT request more mini-slots than are necessary to transmit the MAC frame. This means that ifthe CM is using Short and Long Data IUCs to transmit data and the frame can fit into a Short Data Grant, the CMMUST use the Short Data Grant IUC attributes to calculate the amount of bandwidth to request and MUST makea request less than or equal to the Short Data maximum Burst size. If the CM is using Advanced PHY Short andLong Data IUCs to transmit data and the frame can fit into an Advanced PHY Short Data Grant, the CM MUSTuse the Advanced PHY Short Data Grant IUC attributes to calculate the amount of bandwidth to request andMUST make a request less than or equal to the Advanced PHY Short Data maximum Burst size.

1. This paragraph updated per RFI2-N-02090, superseding RFI2-N-02085 and RFI2-N-02111. This paragraphseparated from the paragraph after it by RKV, all on 10/29/02.

187


The CM MUST have only one request outstanding at a time per Service ID. If the CMTS does not immediatelyrespond with a Data Grant, the CM is able to unambiguously determine that its request is still pending becausethe CMTS MUST continue to issue a Data Grant Pending in every MAP that has an ACK Time indicating therequest has already been processed until the request is granted or discarded.

In MAPs, the CMTS MUST NOT make a data grant greater than 255 mini-slots to any assigned Service ID. Thisputs an upper bound on the grant size the CM has to support.

9.1.4 Information Element Feature Usage Summary

The following table summarizes what types of frames the CM can transmit using each of the MAP IE types thatrepresent transmit opportunities. A “MUST” entry in the table means that, if appropriate, a compliant CMimplementation has to be able to transmit that type of frame in that type of opportunity. A “MAY” entry meansthat compliant CM implementation does not have to be able to transmit that type of frame in that type ofopportunity but that it is legal for it to do so, if appropriate. A “MUST NOT” entry means that a compliant CMwill never transmit that type of frame in that type of opportunity.

Table 9-1 IE Feature Compatibility Summary

9.1.5 Map Transmission and Timing

The allocation MAP MUST be transmitted in time to propagate across the physical cable and be received andhandled by the receiving CMs. As such, it MAY be transmitted considerably earlier than its effective time. Thecomponents of the delay are:

• Worst-case round-trip propagation delay — may be network-specific, but on the order of hundreds of micro-seconds

• Queuing delays within the CMTS — implementation-specific

• Processing delays within the CMs — MUST allow a minimum processing time by each CM as specified inAnnex B (CM MAP Processing Time), which has to include any upstream delays caused by the DOCSIS 2.0TDMA

• Downstream delays caused by the PMD-layer framer and the FEC interleaver

Within these constraints, vendors may wish to minimize this delay so as to minimize latency of access to theupstream channel.

Information ElementTransmit

Request Frame

TransmitConcatenatedMAC Frame

TransmitFragmentedMAC Frame

Transmit RNG-REQ

Transmit Anyother MAC

Frame

Request IE MUST MUST NOT MUST NOT MUST NOT MUST NOT

Request/Data IE MUST MAY MUST NOT MUST NOT MAY

Initial Maintenance IE MUST NOT MUST NOT MUST NOT MUST MUST NOT

Station Maintenance IE MUST NOT MUST NOT MUST NOT MUST MUST NOT

Short Data Grant IE MAY MUST MUST MUST NOT MUST

Long Data Grant IE MAY MUST MUST MUST NOT MUST

Adv PHY Short DataGrant IE

MAY MUST MUST MUST NOT MUST

Adv PHY Long DataGrant IE


Adv PHY UnsolicitedGrant IE


188


The number of mini-slots described MAY vary from MAP to MAP. At minimum, a MAP MAY describe a singlemini-slot. This would be wasteful in both downstream bandwidth and in processing time within the CMs. Atmaximum, a MAP MAY stretch to tens of milliseconds. Such a MAP would provide poor upstream latency.Allocation algorithms MAY vary the size of the maps over time to provide a balance of network utilization andlatency under varying traffic loads.

At minimum, a MAP MUST contain two Information Elements: one to describe an interval and a null IE toterminate the list. At a maximum, a MAP MUST be bounded by a limit of 240 information elements. Maps arealso bounded in that they MUST NOT describe more than 4096 mini-slots into the future. The latter limit isintended to bound the number of future mini-slots that each CM is required to track. A CM MUST be able tosupport multiple outstanding MAPs. Even though multiple MAPs may be outstanding, the sum of the number ofmini-slots they describe MUST NOT exceed 4096.

The set of all MAPs, taken together, MUST describe every mini-slot in the upstream channel. If a CM fails toreceive a MAP describing a particular interval, it MUST NOT transmit during that interval.

9.1.6 Protocol Example

This section illustrates the interchange between the CM and the CMTS when the CM has data to transmit (Figure9-2). Suppose a given CM has a data PDU available for transmission.

Figure 9-2 Protocol Example

Description steps:

1. At time t1, the CMTS transmits a MAP whose effective starting time is t3. Within this MAP is a Request IEwhich will start at t5. The difference between t1 and t3 is needed to allow for all the delays discussed inSection 9.1.5.

2. At t2, the CM receives this MAP and scans it for request opportunities. In order to minimize requestcollisions, it calculates t6 as a random offset based on the Data Backoff Start value in the most recent Map(see Section 9.4, also the multicast SID definitions in Section A.2).

3. At t4, the CM transmits a request for as many mini-slots as needed to accommodate the PDU. Time t4 ischosen based on the ranging offset (see Section 9.3.3) so that the request will arrive at the CMTS at t6.

4. At t6, the CMTS receives the request and schedules it for service in the next MAP. (The choice of whichrequests to grant will vary with the class of service requested, any competing requests, and the algorithm usedby the CMTS.)

5. At t7, the CMTS transmits a MAP whose effective starting time is t9. Within this MAP, a data grant for theCM will start at t11.

slots mapped by first Map PDU

t3

Map PDU

t2

t1

Map PDU

t8

t7

data PDU

t11CMTS

CM

Request

t4

t6t5

second map

t9

t10

189


6. At t8, the CM receives the MAP and scans for its data grant.

7. At t10, the CM transmits its data PDU so that it will arrive at the CMTS at t11. Time t10 is calculated from theranging offset as in step 3.

Steps 1 and 2 need not contribute to access latency if CMs routinely maintain a list of request opportunities.

At Step 3, the request may collide with requests from other CMs and be lost. The CMTS does not directly detectthe collision. The CM determines that a collision (or other reception failure) occurred when the next MAP withan ACK time indicating that the request would have been received and processed fails to include anacknowledgment of the request. The CM MUST then perform a back-off algorithm and retry. (Refer to Section9.4.1)

At Step 4, the CMTS scheduler MAY fail to accommodate the request within the next MAP. If so, it MUST replywith a zero-length grant in that MAP or discard the request by giving no grant at all. It MUST continue to reportthis zero-length grant in all succeeding maps until the request can be granted or is discarded. This MUST signalto the CM that the request is still pending. So long as the CM is receiving a zero-length grant, it MUST NOTissue new requests for that service queue.

9.1.7 MAP Generation Example - Two Logical Upstreams

This section illustrates the timing requirements for scheduling an S-CDMA and a TDMA logical channel on thesame physical channel.

For simplicity it is assumed that:

• The duration of the S-CDMA frames is an integral multiple of the duration of the TDMA Mini-slots.

• Both TDMA and S-CDMA maps begin and end on frame boundaries.

• For the duration of the example there are no S-CDMA bursts with the Spreader Off, and there are noBroadcast Initial Ranging regions where both channels are active.

Figure 9-3 Logical S-CDMA TDMA channels

Description:

1. The example begins at T1 and the first MAP discussed takes effect at T3.

2. At time T1, the CMTS transmits a S-CDMA map whose effective starting time is T3 and end time is T7.

3. At time T2, the CMTS transmits a TDMA map whose effective starting time is T4 and end time is T8.

TDMA Mini-slots

CM TDMAlogical channel

T1 T2

Null SID

NullSID

NullSID

NullSID

S-CDMAlogical channel

T4

T3

T5 T6

T7

T8

Minislot count

null grant

TDMA grant

S-CDMA frame

Frame bounderies

Null SID

190


4. At time T3 the S-CDMA map has three frames of S-CDMA grants. The CMTS upstream scheduler must notallow TDMA transmissions to occur at the same time. To prevent the two channels from interfering with eachother the scheduler will mute the TDMA upstream (by granting mini-slots to the NULL SID for the TDMAchannel) during the time S-CMDA is active.

5. At time T4, on a frame boundary, the TDMA channel becomes active. In this example it has one empty mini-slot (NULL SID) to guarantee sufficient guard time for the following TDMA burst. Then it proceeds withusable TDMA grants. At the same time the S-CDMA upstream is muted by granting mini-slots to the NULLSID in every frame.

6. At T5 and T6 the TDMA logical channel and S-CDMA logical channel transmit the next map for theupstream. Note that the figure above does not continue to detail the complete maps beginning at T7 and T8.

7. At time T7 the S-CDMA map sends a group of S-CDMA grants in a frame. Note that when switching fromTDMA to S-CDMA there is no requirement for additional guard time.

9.2 Support for Multiple Channels

Vendors may choose to offer various combinations of upstream and downstream channels within one MACservice access point. The upstream bandwidth allocation protocol allows for multiple upstream channels to bemanaged via one or many downstream channels. Some or all of these multiple upstream channels may even co-exist on the same upstream transmit center frequency.

If multiple upstream channels are associated with a single downstream channel, then the CMTS MUST send oneallocation MAP per upstream channel. The MAP’s channel identifier, taken with the Upstream ChannelDescriptor Message (see Section 8.3.3), MUST specify to which channel each MAP applies. There is norequirement that the maps be synchronized across channels. Appendix III provides an example.

If multiple logical upstream channels are associated with the same upstream center frequency on the same cablesegment, then the CMTS MUST ensure that the MAP allocations to each logical upstream channel sharing thesame spectrum do not coincide with the potential transmit opportunities of the other logical upstream channelswith the possible exception of Broadcast Initial Ranging opportunities. When sharing the upstream between S-CDMA and TDMA channels, the CMTS MUST take into account the lack of guard time on the synchronousphysical layer upstreams. Annex G provides more information on the co-existence of DOCSIS 1.x and DOCSIS2.0 channels.

If multiple downstream channels are associated with a single upstream channel, the CMTS MUST ensure that theallocation MAP reaches all CMs. That is, if some CMs are attached to a particular downstream channel, then theMAP MUST be transmitted on that channel. This may necessitate that multiple copies of the same MAP betransmitted. The Alloc Start Time in the MAP header MUST always relate to the timebase reference on thedownstream channel on which it is transmitted.

If multiple downstream channels are associated with multiple upstream channels, the CMTS may need totransmit multiple copies of multiple maps to ensure both that all upstream channels are mapped and that all CMshave received their needed maps.

9.3 Timing and Synchronization

One of the major challenges in designing a MAC protocol for a cable network is compensating for the largedelays involved. These delays are an order of magnitude larger than the transmission burst time in the upstream.To compensate for these delays, the cable modem MUST be able to time its transmissions precisely to arrive atthe CMTS at the start of the assigned mini-slot.

191


To accomplish this, two pieces of information are needed by each cable modem:

• a global timing reference sent downstream from the CMTS to all cable modems.

• a timing offset, calculated during a ranging process, for each cable modem.

9.3.1 Global Timing Reference

For TDMA channels, the CMTS MUST create a global timing reference by transmitting the TimeSynchronization (SYNC) MAC management message downstream at a nominal frequency. The messagecontains a timestamp that exactly identifies when the CMTS transmitted the message. Cable modems MUSTthen compare the actual time the message was received with the timestamp and adjust their local clock referencesaccordingly.

For S-CDMA channels, the CMTS also creates a global timing reference by transmitting the TimeSynchronization (SYNC) and Upstream Channel Descriptor (UCD) MAC messages downstream at a nominalfrequency. See Section 6.2.11.2.

The Transmission Convergence sublayer must operate closely with the MAC sublayer to provide an accuratetimestamp for the SYNC message. As mentioned in the Ranging section below (Section 9.3.3), the modelassumes that the timing delays through the remainder of the PHY layer MUST be relatively constant with theexception of the timing offsets specified in Section 6.2.19.4 related to modulation rate changes to accommodatea legacy DOCSIS upstream receiver implementation. For TDMA, any variation in the PHY delays MUST beaccounted for in the guard time of the PHY overhead.1

It is intended that the nominal interval between SYNC messages be tens of milliseconds and the nominal intervalbetween UCD messages be no more than 2 seconds. This imposes very little downstream overhead while lettingcable modems acquire their global timing synchronization quickly.

9.3.2 CM Channel Acquisition

Any cable modem MUST NOT use the upstream channel until it has successfully synchronized to thedownstream.

First, the cable modem MUST establish PMD sublayer synchronization. This implies that it has locked onto thecorrect frequency, equalized the downstream channel, recovered any PMD sublayer framing and the FEC isoperational (refer to Section 11.2.2). At this point, a valid bit stream is being sent to the transmissionconvergence sublayer. The transmission convergence sublayer performs its own synchronization (see Section 7).On detecting the well-known DOCSIS PID, along with a payload unit start indicator per [ITU-T H.222.0], itdelivers the MAC frame to the MAC sublayer.

The MAC sublayer MUST now search for the Timing Synchronization (SYNC) MAC management messages.For TDMA channels, the cable modem achieves MAC synchronization once it has received at least two SYNCmessages and has verified that its clock tolerances are within specified limits. For S-CDMA channels, the cablemodem achieves MAC synchronization once it has received at least two SYNC messages, received one UCDmessage, and has locked to the downstream symbol clock and verified that its clock tolerances are withinspecified limits

A cable modem remains in “SYNC” as long as it continues to successfully receive the SYNC messages. If theLost SYNC Interval (refer to Annex B) has elapsed without a valid SYNC message, a cable modem MUST NOTuse the upstream and MUST try to re-establish synchronization again.

1. Section 9.3.1, third paragraph, last two sentences updated per RFI2-N-02178 by RKV on 10/30/03.

192


9.3.3 Ranging

Ranging is the process of acquiring the correct timing offset such that the cable modem’s transmissions arealigned to the correct mini-slot boundary. The timing delays through the PHY layer MUST be relatively constantwith the exception of the timing offsets specified in Section 6.2.19.4 related to modulation rate changes toaccommodate a legacy DOCSIS upstream receiver implementation. For TDMA, any variation in the PHY delaysMUST be accounted for in the guard time of the upstream PMD overhead.1

9.3.3.1 Broadcast Initial Ranging

First, a cable modem MUST synchronize to the downstream and learn the upstream channel characteristicsthrough the Upstream Channel Descriptor MAC management message. At this point, the cable modem MUSTscan the Bandwidth Allocation MAP message to find a Broadcast Initial Maintenance Region. Refer to Section9.1.2.4. The CMTS MUST make a Broadcast Initial Maintenance region large enough to account for thevariation in delays between any two CMs. On S-CDMA channels, the CMTS MUST schedule Broadcast InitialMaintenance transmit opportunities such that they align with S-CDMA frames and span an integral number of S-CDMA frames. Refer to Section 6.2.11.5, “Spreader-off Bursts for Maintenance on S-CDMA channel,” onpage 59.

The cable modem MUST put together either an Initial Ranging Request message or a Ranging Request messageto be sent in a Broadcast Initial Maintenance region. An INIT-RNG-REQ MUST be transmitted if the upstreamis a DOCSIS 2.0 Only Upstream, which can be determined from the UCD. Otherwise a RNG-REQ MUST betransmitted. The SID field MUST be set to the non-initialized CM value (zero), unless this initial ranging is aresult of a UCD ranging required TLV or a DCC or UCC request in which the CM has been instructed to retainits existing SIDs.

The CM MUST set its initial timing offset to the amount of internal fixed delay equivalent to putting this CMnext to the CMTS. This amount includes delays introduced through a particular implementation, and MUSTinclude the downstream PHY interleaving latency.When the Broadcast Initial Maintenance transmit opportunityoccurs, the cable modem MUST send the INIT-RNG-REQ or RNG-REQ message. Thus, the cable modem sendsthe message as if it was physically right at the CMTS.

Once the CMTS has successfully received the RNG-REQ OR INIT-RNG-REQ message, it MUST return aRanging Response message addressed to the individual cable modem. Within the Ranging Response messageMUST be a temporary SID assigned to this cable modem (unless the CM has retained a previous Primary SIDduring a UCC, DCC, or UCD change) until it has completed the registration process. The message MUST alsocontain information on RF power level adjustment and offset frequency adjustment as well as any timing offsetcorrections. Ranging adjusts each CM’s timing offset such that it appears to be located right next to the CMTS.

9.3.3.2 Unicast Initial Ranging

The cable modem MUST now wait for an individual Station Maintenance or Unicast Initial Maintenance regionassigned to its temporary SID (or previous primary SID if ranging as a result of a UCC, DCC, or UCD change).It MUST now transmit a ranging Request message at this time using the temporary SID (or previous primarySID) along with any power level and timing offset corrections.

The CMTS MUST return another Ranging Response message to the cable modem with any additional finetuning required. The ranging request/response steps MUST be repeated until the response contains a RangingSuccessful notification or the CMTS aborts ranging. Once successfully ranged, the cable modem MUST joinnormal data traffic in the upstream. See Section 11 for complete details on the entire initialization sequence. In

1. Section 9.3.3 updated per RFI2-N-02178 by RKV on 10/30/02.

193


particular, state machines and the applicability of retry counts and timer values for the ranging process aredefined in Section 11.2.4.

Note: The burst type to use for any transmission is defined by the Interval Usage Code (IUC). Each IUC is mapped to a bursttype in the UCD message.

9.3.4 Timing Units and Relationships

The SYNC message conveys a time reference with a resolution of 6.25/64 microseconds (10.24 MHz) to allowthe CM to track the CMTS clock with a small phase offset. Since this timing reference is decoupled fromparticular upstream channel characteristics, a single SYNC time reference may be used for all upstream channelsassociated with the downstream channel.

The bandwidth allocation MAP uses time units of “mini-slots.” A mini-slot represents the time needed fortransmission of a fixed number of symbols. For some modulations (ex QPSK) an integer number of bytes can betransmitted in a mini-slot. For these channels, the mini-slot is expected to represent 16 byte-times, although othervalues could be chosen.

A “mini-slot” is the unit of granularity for upstream transmission opportunities; there is no implication that anyPDU can actually be transmitted in a single mini-slot.

9.3.4.1 TDMA Timing Units and Relationships

9.3.4.1.1 Mini-Slot Capacity

On TDMA channels, the size of the mini-slot, expressed as a multiple of the SYNC time reference, is carried inthe Upstream Channel Descriptor. The example in Table 9-2 relates mini-slots to the SYNC time ticks (assumingQPSK modulation):

Table 9-2 Example Relating Mini-Slots to Time Ticks

Note that the symbols/byte is a characteristic of an individual burst transmission, not of the channel. A mini-slotin this instance could represent a minimum of 16 or a maximum of 48 bytes, depending on the modulationchoice.

In a channel allocated exclusively to DOCSIS 2.0 TDMA modems, the Mini-slot Size field of the UCD MAYtake on the value 0, in which case the Mini-slot size is 1 Timebase Tick. If a channel is to be accessible to bothDOCSIS 1.x and 2.0 TDMA Cable Modems, the UCD MUST follow the DOCSIS 1.x requirements for timingunits and relationships.

Parameter Example Value

Time tick 6.25 microseconds

Bytes per mini-slot 16 (nominal, when using QPSK modulation)

Symbols/byte 4 (assuming QPSK)

Symbols/second 2,560,000

Mini-slots/second 40,000

Microseconds/mini-slot 25

Ticks/mini-slot 4

194


9.3.4.1.2 Mini-Slot Numbering

The MAP counts mini-slots in a 32-bit counter that normally counts to (232 - 1) and then wraps back to zero. Theleast-significant bits (i.e., bit 0 to bit 25-M) of the mini-slot counter MUST match the most-significant bits(i.e., bit 6+M to bit 31) of the SYNC timestamp counter. That is, mini-slot N begins at timestamp reference

(N*T*64), where T = 2M is the UCD multiplier that defines the mini-slot (i.e., the number of timeticks per mini-slot). Note: The unused upper bits of the 32-bit mini-slot counter (i.e., bit 26-M to bit 31) are not needed by theCM and MAY be ignored.

Note: The constraint that the UCD multiplier be a power of two has the consequence that the number of bytes per mini-slotmust also be a power of two.

9.3.4.2 S-CDMA Timing Units and Relationships

9.3.4.2.1 Mini-Slot Capacity

On S-CDMA channels, the size of the mini-slot is dependent on the modulation rate, the codes per mini-slot, andthe spreading intervals per frame, which are all carried in the Upstream Channel Descriptor. The timing units andrelationships for S-CDMA are covered in detail in Section 6.2.11, “S-CDMA Framer and Interleaver,” onpage 54. An example of the timing relationships (assuming 64QAM modulation) is shown in Table 9-3:

Table 9-3 Example of Mini-Slot Capacity in S-CDMA mode

9.3.4.2.2 Mini-Slot Numbering

Mini-slot numbering in S-CDMA mode is described in detail in Section 6.2.11.2, “Mini-slot Numbering,” onpage 54.

9.4 Upstream Transmission and Contention Resolution

The CMTS controls assignments on the upstream channel through the MAP and determines which mini-slots aresubject to collisions. The CMTS MAY allow collisions on either Requests or Data PDUs.

This section provides an overview of upstream transmission and contention resolution. For simplicity, it refers tothe decisions a CM makes, however, this is just a pedagogical tool. Since a CM can have multiple upstreamService Flows (each with its own SID) it makes these decisions on a per service queue or per SID basis. Refer toAppendix IV for a state transition diagram and more detail.

Parameter Example Value

Spreading intervals per frame 10

Active code length 128

Codes per mini-slot 4

Mini-slots per frame 32

Symbols per mini-slot 40

Bytes per mini-slot 30 (nominal, when using 64QAM modulation)

Bits/symbol 6 (assuming 64QAM)

Symbols/second 5,120,000

Mini-slots/second 128,000

Microseconds/mini-slot 7.8125

195


9.4.1 Contention Resolution Overview

The mandatory method of contention resolution which MUST be supported is based on a truncated binaryexponential back-off, with the initial back-off window and the maximum back-off window controlled by theCMTS. The values are specified as part of the Bandwidth Allocation Map (MAP) MAC message and represent apower-of-two value. For example, a value of 4 indicates a window between 0 and 15; a value of 10 indicates awindow between 0 and 1023.

Every time a CM wants to transmit in a contention region, it MUST enter the contention resolution process by

setting its internal backoff window equal to the Data Backoff Start defined in the MAP1 currently in effect.2

The CM MUST randomly select a number within its back-off window. This random value indicates the numberof contention transmit opportunities which the CM MUST defer before transmitting. A CM MUST only considercontention transmit opportunities for which this transmission would have been eligible. These are defined byeither Request IEs or Request/Data IEs in the MAP.

Note: Each IE can represent multiple transmission opportunities.

As an example, consider a CM whose initial back-off window is 0 to 15 and it randomly selects the number 11.The CM must defer a total of 11 contention transmission opportunities. If the first available Request IE is for 6requests, the CM does not use this and has 5 more opportunities to defer. If the next Request IE is for 2 requests,the CM has 3 more to defer. If the third Request IE is for 8 requests, the CM transmits on the fourth request, afterdeferring for 3 more opportunities.

After a contention transmission, the CM waits for a Data Grant (Data Grant Pending) or Data Acknowledge in asubsequent MAP. Once either is received, the contention resolution is complete. The CM determines that thecontention transmission was lost when it finds a MAP without a Data Grant (Data Grant Pending) or Data

Acknowledge for it and with an Ack time more recent than the time of transmission.3 The CM MUST nowincrease its back-off window by a factor of two, as long as it is less than the maximum back-off window. The CMMUST randomly select a number within its new back-off window and repeat the deferring process describedabove.

This re-try process continues until the maximum number of retries (16) has been reached, at which time the PDUMUST be discarded.

Note: The maximum number of retries is independent of the initial and maximum back-off windows that are defined by theCMTS.

If the CM receives a unicast Request or Data Grant at any time while deferring for this SID, it MUST stop thecontention resolution process and use the explicit transmit opportunity.

The CMTS has much flexibility in controlling the contention resolution. At one extreme, the CMTS may chooseto set up the Data Backoff Start and End to emulate an Ethernet-style back-off with its associated simplicity anddistributed nature, but also its fairness and efficiency issues. This would be done by setting Data Backoff Start =

1. The MAP currently in effect is the MAP whose allocation start time has occurred but which includes IEs thathave not occurred.

2. Revised paragraph per ECN RFI2-N-02215, chg #1, by GO, on 12/02/02.3. Data Acknowledge IEs are intended for collision detection only and is not designed for providing reliable

transport (that is the responsibility of higher layers). If a MAP is lost or damaged, a CM waiting for a DataAcknowledge MUST assume that its contention data transmission was successful and MUST NOT retransmitthe data packet. This prevents the CM from sending duplicate packets unnecessarily.

196


0 and End = 10 in the MAP. At the other end, the CMTS may make the Data Backoff Start and End identical andfrequently update these values in the MAP so all cable modems are using the same, and hopefully optimal, back-off window.

A CM transmitting a RNG-REQ in the Initial Maintenance IE MUST perform truncated binary exponentialbackoff using the Ranging Backoff Start and Ranging Backoff End to control the backoff window. The algorithmworks similarly to data transmissions, except of the calculation of transmit opportunities which is described in

the next section.1

9.4.2 Transmit Opportunities

A Transmit Opportunity is defined as any mini-slot in which a CM may be allowed to start a transmission.Transmit Opportunities typically apply to contention opportunities and are used to calculate the proper amount todefer in the contention resolution process.

The number of Transmit Opportunities associated with a particular IE in a MAP is dependent on the total size ofthe region as well as the allowable size of an individual transmission. As an example, assume a contention REQIE defines a region of 12 mini-slots. If the UCD defines a REQ Burst Size that fits into a single mini-slot thenthere are 12 Transmit Opportunities associated with this REQ IE, i.e., one for each mini-slot. If the UCD definesa REQ that fits in two mini-slots, then there are six Transmit Opportunities and a REQ can start on every othermini-slot.2

As another example, assume a REQ/Data IE that defines a 24 mini-slot region. If it is sent with an SID of 0x3FF4(refer to Annex A), then a CM can potentially start a transmit on every fourth mini-slot; so this IE contains a totalof six Transmit Opportunities (TX OP). Similarly, a SID of 0x3FF6 implies four TX OPs; 0x3FF8 implies threeTX OPs; and 0x3FFC implies two TX OPs.

For a Broadcast Initial Maintenance IE, a CM MUST start its transmission in the first mini-slot of the region;therefore it has a single Transmit Opportunity. The remainder of the region is used to compensate for the round-trip delays since the CM has not yet been ranged.

Station Maintenance IEs, Short/Long Data Grant IEs, Adv PHY Short/Long Data Grant IEs, Adv PHYUnsolicited Grant IEs, unicast Initial Maintenance, and unicast Request IEs are unicast and thus are not typicallyassociated with contention Transmit Opportunities. They represent a single dedicated, or reservation based,Transmit Opportunity.

In summary:

Table 9-4 Transmit Opportunity

Note: Transmit Opportunity should not be confused with Burst Size. Burst Size requirements are specified in Table 6-1.3

1. Added this paragraph per ECN RFI2-N-02215, chg #2, by GO, on 12/02/02.2. This paragraph updated per RFI2-N-02135 by RKV on 10/29/02.

Interval SID Type Transmit Opportunity

Request Broadcast # mini-slots required for a Request

Request Multicast # mini-slots required for a Request

Request/Data Broadcast Not allowed

Request/Data Well-known Multicast As defined by SID in Annex A

Request/Data Multicast Vendor specific algorithms

Initial Maint. Broadcast Entire interval is a single tx opp.

197


9.4.3 CM Bandwidth Utilization

The following rules govern the response a CM makes when processing maps.

Note: These standard behaviors can be overridden by the CM’s Request/Transmission Policy (refer to Section C.2.2.6.3):

1. A CM MUST first use any Grants assigned to it. Next, the CM MUST use any unicast REQ for it. Finally, theCM MUST use the next available broadcast/multicast REQ or REQ/Data IEs for which it is eligible.

2. A CM MUST NOT have more than one Request outstanding at a time for a particular Service ID.

3. If a CM has a Request pending, it MUST NOT use intervening contention intervals for that Service ID.

9.5 Data Link Encryption Support

The procedures to support data link encryption are defined in [DOCSIS8]. The interaction between the MAClayer and the security system is limited to the items defined below.

9.5.1 MAC Messages

MAC Management Messages (Section 8.3) MUST NOT be encrypted, except for certain cases where such aframe is included in a fragmented concatenated burst on the upstream. (Refer to Section 8.2.7.1)

9.5.2 Framing

The following rules MUST be followed when encryption is applied to a data PDU:

• Privacy EH element of [DOCSIS8] MUST be in the extended header and MUST be the first EH element ofthe Extended Header field (EHDR).

• Encrypted data are carried as Data PDUs to the Cable MAC transparently.

3. This Note added per RFI2-N-02135 by RKV on 10/29/02.

198


10 Quality of Service and Fragmentation

This specification introduces several new Quality of Service (QoS) related concepts not present in [DOCSIS9].These include:

• Packet Classification & Flow Identification

• Service Flow QoS Scheduling

• Dynamic Service Establishment

• Fragmentation

• Two-Phase Activation Model

10.1 Theory of Operation

The various DOCSIS protocol mechanisms described in this document can be used to support Quality of Service(QoS) for both upstream and downstream traffic through the CM and the CMTS. This section provides anoverview of the QoS protocol mechanisms and their part in providing end-to-end QoS.

The requirements for Quality of Service include:

• A configuration and registration function for pre-configuring CM-based QoS Service Flows and trafficparameters.

• A signaling function for dynamically establishing QoS-enabled Service Flows and traffic parameters

• A traffic-shaping and traffic-policing function for Service Flow-based traffic management, performed ontraffic arriving from the upper layer service interface and outbound to the RF.

• Utilization of MAC scheduling and traffic parameters for upstream Service Flows.

• Utilization of QoS traffic parameters for downstream Service Flows.

• Classification of packets arriving from the upper layer service interface to a specific active Service Flow.

• Grouping of Service Flow properties into named Service Classes, so upper layer entities and external appli-cations (at both the CM and CMTS) can request Service Flows with desired QoS parameters in a globallyconsistent way.

The principal mechanism for providing enhanced QoS is to classify packets traversing the RF MAC interfaceinto a Service Flow. A Service Flow is a unidirectional flow of packets that is provided a particular Quality ofService. The CM and CMTS provide this QoS by shaping, policing, and prioritizing traffic according to the QoSParameter Set defined for the Service Flow.

The primary purpose of the Quality of Service features defined here is to define transmission ordering andscheduling on the Radio Frequency Interface. However, these features often need to work in conjunction withmechanisms beyond the RF interface in order to provide end-to-end QoS or to police the behavior of cablemodems. For example, the following behaviors are permitted:

• Policies may be defined by CM MIBs which overwrite the TOS byte. Such policies are outside thescope of the RFI specification. In the upstream direction the CMTS polices the TOS byte settingregardless of how the TOS byte is derived or by whom it is written (originator or CM policy).

• The queueing of Service Flow packets at the CMTS in the downstream direction may be based onthe TOS byte.

• Downstream Service Flows can be reclassified by the CM to provide enhanced service onto thesubscriber-side network.

199


Service Flows exist in both the upstream and downstream direction, and may exist without actually beingactivated to carry traffic. Service Flows have a 32-bit Service Flow Identifier (SFID) assigned by the CMTS.All Service Flows have an SFID; active and admitted upstream Service Flows also have a 14-bit ServiceIdentifier (SID).

At least two Service Flows must be defined in each configuration file: one for upstream and one for downstreamservice. The first upstream Service Flow describes the Primary Upstream Service Flow, and is the defaultService Flow used for otherwise unclassified traffic, including both MAC Management messages and DataPDUs. The first downstream Service Flow describes service to the Primary Downstream Service Flow.Additional Service Flows defined in the Configuration file create Service Flows that are provided QoS services.

Conceptually, incoming packets are matched to a Classifier that determines to which QoS Service Flow thepacket is forwarded. The Classifier can examine the LLC header of the packet, the IP/TCP/UDP header of thepacket or some combination of the two. If the packet matches one of the Classifiers, it is forwarded to the ServiceFlow indicated by the SFID attribute of the Classifier. If the packet is not matched to a Classifier, it is forwardedon the Primary Service Flow.

10.1.1 Concepts

10.1.1.1 Service Flows

A Service Flow is a MAC-layer transport service that provides unidirectional transport of packets either to

upstream packets transmitted by the CM or to downstream packets transmitted by the CMTS1. A Service Flow ischaracterized by a set of QoS Parameters such as latency, jitter, and throughput assurances. In order tostandardize operation between the CM and CMTS, these attributes include details of how the CM requestsupstream mini-slots and the expected behavior of the CMTS upstream scheduler.

A Service Flow is partially characterized by the following attributes2:

• ServiceFlowID: exists for all service flows

• ServiceID: only exists for admitted or active upstream service flows

• ProvisionedQosParamSet: defines a set of QoS Parameters which appears in the configuration fileand is presented during registration. This MAY define the initial limit for authorizations allowed bythe authorization module. The ProvisionedQosParamSet is defined once when the Service Flow is

created via registration.3

• AdmittedQosParamSet: defines a set of QoS parameters for which the CMTS (and possibly theCM) are reserving resources. The principal resource to be reserved is bandwidth, but this alsoincludes any other memory or time-based resource required to subsequently activate the flow.

• ActiveQosParamSet: defines set of QoS parameters defining the service actually being provided tothe Service Flow. Only an Active Service Flow may forward packets.

1. A Service Flow, as defined here, has no direct relationship to the concept of a “flow” as defined by the IETF’sIntegrated Services (intserv) Working Group [RFC-2212]. An intserv flow is a collection of packets sharingtransport-layer endpoints. Multiple intserv flows can be served by a single Service Flow. However, the Clas-sifiers for a Service Flow may be based on 802.1P/Q criteria, and so may not involve intserv flows at all.

2. Some attributes are derived from the above attribute list. The Service Class Name is an attribute of the Provi-sionedQoSParamSet. The activation state of the Service Flow is determined by the ActiveQoSParamSet. Ifthe ActiveQoSParamSet is null then the service flow is inactive.

3. The ProvisionedQoSParamSet is null when a flow is created dynamically.

200


A Service Flow exists when the CMTS assigns a Service Flow ID (SFID) to it. The SFID serves as the principalidentifier in the CM and CMTS for the Service Flow. A Service Flow which exists has at least an SFID, and anassociated Direction.

The Authorization Module is a logical function within the CMTS that approves or denies every change to QoSParameters and Classifiers associated with a Service Flow. As such it defines an “envelope” that limits thepossible values of the AdmittedQoSParameterSet and ActiveQoSParameterSet.

The relationship between the QoS Parameter Sets is as shown in Figure 10-1 and Figure 10-2. The

ActiveQoSParameterSet is always a subset1 of the AdmittedQoSParameterSet which is always a subset of theauthorized “envelope.” In the dynamic authorization model, this envelope is determined by the AuthorizationModule (labeled as the AuthorizedQoSParameterSet). In the provisioned authorization model, this envelope isdetermined by the ProvisionedQoSParameterSet. (Refer to Section 10.1.4 for further information on theauthorization models)

Figure 10-1 Provisioned Authorization Model “Envelopes”

1. To say that QoS Parameter Set A is a subset of QoS Parameter Set B, the following MUST be true for all QoSParameters in A and B:

If a smaller QoS parameter value indicates less resources (e.g., Maximum Traffic Rate), A is a subset of B ifthe parameter in A less than or equal to the same parameter in B.

If a larger QoS parameter value indicates less resources (e.g., Tolerated Grant Jitter), A is a subset of B if theparameter in A is greater than or equal to the same parameter in B.

If the QoS parameter specifies a periodic interval (e.g., Nominal Grant Interval), A is a subset of B if theparameter in A is an integer multiple of the same parameter in B.

If the QoS parameter is not quantitative (e.g., Service Flow Scheduling Type), A is a subset of B if the param-eter in A is equal to the same parameter in B.

AuthQosParamSet = ProvisionedQosParamSet(SFID)

AdmittedQosParamSet(SFID & SID)

ActiveQosParamSet(SFID & Active SID)

201


Figure 10-2 Dynamic Authorization Model “Envelopes”

It is useful to think of three types of Service Flows:

• Provisioned: this type of Service Flow is known via provisioning through the configuration file, its Admit-tedQoSParamSet and ActiveQoSParamSet are both null. A Provisioned Service Flow may or may not haveassociated Classifiers. If a Provisioned Service Flow has associated Classifiers, the Classifiers MUST NOTbe used to classify packets onto the flow, regardless of the Classifier’s Activation State.

• Admitted: this type of Service Flow has resources reserved by the CMTS for its AdmittedQoSParamSet, butthese parameters are not active (its ActiveQoSParamSet is null). Admitted Service Flows may have beenprovisioned or may have been signalled by some other mechanism. Generally, Admitted Service Flows haveassociated Classifiers, however, it is possible for Admitted Service Flows to use policy-based classification.If Admitted Service Flows have associated Classifiers, the classifiers MUST NOT be used to classify packetsonto the flow, regardless of the classifier’s activation state.

• Active: this type of Service Flow has resources committed by the CMTS for its QoS Parameter Set, (e.g., isactively sending MAPs containing unsolicited grants for a UGS-based service flow). Its ActiveQoSParamSetis non-null. Generally, Active Service Flows have associated Classifiers, however, it is possible for ActiveService Flows to use policy-based classification. Primary Service Flows may have associated Classifiers(s),but in addition to any packets matching such Classifiers, all packets that fail to match any Classifier will besent on the Primary Service Flow for that direction.

10.1.1.2 Classifiers

A Classifier is a set of matching criteria applied to each packet entering the cable network. It consists of somepacket matching criteria (destination IP address, for example), a classifier priority, and a reference to a serviceflow. If a packet matches the specified packet matching criteria, it is then delivered on the referenced serviceflow.

Several Classifiers may all refer to the same Service Flow. The classifier priority is used for ordering theapplication of Classifiers to packets. Explicit ordering is necessary because the patterns used by Classifiers mayoverlap. The priority need not be unique, but care must be taken within a classifier priority to prevent ambiguityin classification. (Refer to Section 10.1.6.1) Downstream Classifiers are applied by the CMTS to packets it istransmitting, and Upstream Classifiers are applied at the CM and may be applied at the CMTS to police theclassification of upstream packets. Figure 10-3 illustrates the mappings discussed above.

AuthQosParamSet(CMTS only, not known by CM)

AdmitQosParamSet(SFID & SID)

ActiveQosParamSet(SFID & Active SID)

ProvQosParamSet(SFID)

202


Figure 10-3 Classification within the MAC Layer

CM and CMTS Packet Classification consists of multiple Classifiers. Each Classifier contains a priority fieldwhich determines the search order for the Classifier. The highest priority Classifier MUST be applied first. If aClassifier is found that has at least one relevant parameter and all relevant parameters match the packet, theClassifier MUST forward the packet to the corresponding Service Flow (irrelevant parameters - as defined inC.2.1 - have no impact on packet classification decisions). If a Classifier contains no relevant parameters for agiven packet (i.e., all parameters are irrelevant), then that packet cannot match the Classifier, and the ClassifierMUST NOT forward the packet to the corresponding Service Flow. If a packet does not match any Classifier and

as a result has not been classified to any other flow, then it MUST be classified to the Primary Service Flow.1

The packet classification table contains the following fields:

• Priority — determines the search order for the table. Higher priority Classifiers are searched before lower pri-ority Classifiers.

• IP Classification Parameters — zero or more of the IP classification parameters (IP TOS Range/Mask, IPProtocol, IP Source Address/Mask, IP Destination Address/Mask, TCP/UDP Source Port Start, TCP/UDPSource Port End, TCP/UDP Destination Port Start, TCP/UCP Destination Port End)

• LLC Classification Parameters — zero or more of the LLC classification parameters (Destination MACAddress, Source MAC Address, Ethertype/SAP)

• IEEE 802.1P/Q Parameters — zero or more of the IEEE classification parameters (802.1P Priority Range,802.1Q VLAN ID)

• Service Flow Identifier — identifier of a specific flow to which this packet is to be directed

1. Replaced this paragraph per ECN RFI2-N-02200, change #1, by GO, on 11/21/02.

Upper Layer Entity (e.g. bridge, router) Upper Layer Entity (e.g. bridge,router, client)

RF

(Optional)Ingress

Classifier

UpstreamClassifier

CM

DownstreamClassifier

CMTS

UpstreamClassifier

DownstreamService Flows

MACMgmtMsgs

Primary SFID

SFID n

Downstream

MACMgmtMsgs

Primary SID

SID n

Upstream Service Flows

...

SFID 2

UpstreamSID 2

...

203


Classifiers can be added to the table either via management operations (configuration file, registration) or viadynamic operations (dynamic signaling, DOCSIS MAC sublayer service interface). SNMP-based operations canview Classifiers that are added via dynamic operations, but can not modify or delete Classifiers that are createdby dynamic operations. The format for classification table parameters defined in the configuration file,registration message, or dynamic signaling message is contained in Annex C.

Classifier attributes include an activation state (see Section C.2.1.3.6). The ‘inactive’ setting may be used toreserve resources for a classifier which is to be activated later. The actual activation of the classifier depends bothon this attribute and on the state of its service flow. If the service flow is not active then the classifier is not used,regardless of the setting of this attribute.

10.1.2 Object Model

The major objects of the architecture are represented by named rectangles in Figure 10-4. Each object has anumber of attributes; the attribute names which uniquely identify the object are underlined. Optional attributesare denoted with brackets. The relationship between the number of objects is marked at each end of theassociation line between the objects. For example, a Service Flow may be associated with from 0 to 65535Classifiers, but a Classifier is associated with exactly one Service flow.

The Service Flow is the central concept of the MAC protocol. It is uniquely identified by a 32-bit Service FlowID (SFID) assigned by the CMTS. Service Flows may be in either the upstream or downstream direction. Aunicast Service Identifier (SID) is a 14-bit index, assigned by the CMTS, which is associated with one and onlyone Admitted Upstream Service Flow.

Typically, an outgoing user data Packet is submitted by an upper layer protocol (such as the forwarding bridge ofa CM) for transmission on the Cable MAC interface. The packet is compared against a set of Classifiers. Thematching Classifier for the Packet identifies the corresponding Service Flow via the Service Flow ID (SFID). Inthe case where more than one Classifier matches the packet, the highest Priority Classifier is chosen.

The Classifier matching a packet may be associated with a Payload Header Suppression Rule. A PHS Ruleprovides details on how header bytes of a Packet PDU can be omitted, replaced with a Payload HeaderSuppression Index for transmission and subsequently regenerated at the receiving end. PHS Rules are indexed bythe combination of {SFID, PHSI} (refer to Section 10.4). When a Service Flow is deleted, all Classifiers and anyassociated PHS Rules referencing it MUST also be deleted.

The Service Class is an optional object that MAY be implemented at the CMTS. It is referenced by an ASCIIname which is intended for provisioning purposes. A Service Class is defined in the CMTS to have a particularQoS Parameter Set. A Service Flow may contain a reference to the Service Class Name that selects all of the QoSparameters of the Service Class. The Service Flow QoS Parameter Sets may augment and even override the QoSparameter settings of the Service Class, subject to authorization by the CMTS. (Refer to Section C.2.2.5)

If a Packet has already been determined by upper layer policy mechanisms to be associated with a particularService Class Name/Priority combination, that combination associates the packet with a particular Service Flowdirectly (refer to Section 10.1.6.1). The upper layer may also be aware of the particular Service Flows in theMAC Sublayer, and may have assigned the Packet directly to a Service Flow. In these cases, a user data Packet isconsidered to be directly associated with a Service Flow as selected by the upper layer. This is depicted with thedashed arrow in Figure 10-4. (Refer to Appendix I)

204


Figure 10-4 Theory of Operation Object Model

10.1.3 Service Classes

The QoS attributes of a Service Flow may be specified in two ways: either by explicitly defining all attributes, orimplicitly by specifying a Service Class Name. A Service Class Name is a string which the CMTS associateswith a QoS Parameter Set. It is described further below.

The Service Class serves the following purposes:

1. It allows operators, who so wish, to move the burden of configuring service flows from the provisioningserver to the CMTS. Operators provision the modems with the Service Class Name; the implementation ofthe name is configured at the CMTS. This allows operators to modify the implementation of a given serviceto local circumstances without changing modem provisioning. For example, some scheduling parametersmay need to be tweaked differently for two different CMTSes to provide the same service. As anotherexample, service profiles could be changed by time of day.

2. It allows CMTS vendors to provide class-based-queuing if they choose, where service flows compete withintheir class and classes compete with each other for bandwidth.

3. It allows higher-layer protocols to create a Service Flow by its Service Class Name. For example, telephonysignaling may direct the CM to instantiate any available Provisioned Service Flow of class “G711”.

4. It allows packet classification policies to be defined which refer to a desired service class, without having torefer to a particular service flow instance of that class.

Packet Classifier

Service Class

Service Flow

PayloadHeaderSuppression (PHS)

LlcHeader[lp Header][SCase][RulePriority][SFID]

SFIDClassifierId

LlcPacketPatternlpPacketPatternRulePriority

SFIDDirection

[SID][ProvQosParamSet][AdmittedQosParamSet]ActiveQosParamSet]

SFIDPHSIClassifierldPHSFPHSMPHSSPHSV

Service Class NameQosParamSet

0,1

0,3

0..255

N1

10..65535matches

205


Note: The Service Class is optional: the flow scheduling specification may always be provided in full; a service flow maybelong to no service class whatsoever. CMTS implementations MAY treat such “unclassed” flows differently from “classed”flows with equivalent parameters.

Any Service Flow MAY have each of its QoS Parameter Sets specified in any of three ways:

• By explicitly including all traffic parameters

• By indirectly referring to a set of traffic parameters by specifying a Service Class Name

• By specifying a Service Class Name along with modifying parameters

The Service Class Name is “expanded” to its defined set of parameters at the time the CMTS successfully admitsthe Service Flow. The Service Class expansion can be contained in the following CMTS-originated messages:Registration Response, DSA-REQ, DSC-REQ, DSA-RSP and DSC-RSP. In all of these cases, the CMTS MUSTinclude a Service Flow Encoding that includes the Service Class Name and the QoS Parameter Set of the ServiceClass. If a CM-initiated request contained any supplemental or overriding Service Flow parameters, a successfulresponse MUST also include these parameters.

When a Service Class name is given in an admission or activation request, the returned QoS Parameter Set maychange from activation to activation. This can happen because of administrative changes to the Service Class’QoS Parameter Set at the CMTS. If the definition of a Service Class Name is changed at the CMTS (e.g., itsassociated QoS Parameter Set is modified), it has no effect on the QoS Parameters of existing Service Flowsassociated with that Service Class. A CMTS MAY initiate DSC transactions to existing Service Flows whichreference the Service Class Name to affect the changed Service Class definition.

When a CM uses the Service Class Name to specify the Admitted QoS Parameter Set, the expanded set of TLVencodings of the Service Flow will be returned to the CM in the response message (REG-RSP, DSA-RSP, orDSC-RSP). Use of the Service Class Name later in the activation request may fail if the definition of the ServiceClass Name has changed and the new required resources are not available. Thus, the CM SHOULD explicitlyrequest the expanded set of TLVs from the response message in its later activation request.

10.1.4 Authorization

Every change to the Service Flow QoS Parameters MUST be approved by an authorization module. Thisincludes every REG-REQ or DSA-REQ message to create a new Service Flow, and every DSC-REQ message tochange a QoS Parameter Set of an existing Service Flow. Such changes include requesting an admission controldecision (e.g., setting the AdmittedQoSParamSet) and requesting activation of a Service Flow (e.g., setting theActiveQoSParameterSet). Reduction requests regarding the resources to be admitted or activated are alsochecked by the authorization module, as are requests to add or change the Classifiers.

In the static authorization model, the authorization module receives all registration messages, and stores theprovisioned status of all “deferred” Service Flows. Admission and activation requests for these provisionedservice flows will be permitted, as long as the Admitted QoS Parameter Set is a subset of the Provisioned QoSParameter Set, and the Active QoS Parameter Set is a subset of the Admitted QoS Parameter Set. Requests tochange the Provisioned QoS Parameter Set will be refused, as will requests to create new dynamic ServiceFlows. This defines a static system where all possible services are defined in the initial configuration of eachCM.

In the dynamic authorization model, the authorization module not only receives all registration messages, butalso communicates through a separate interface to an independent policy server. This policy server may provideto the authorization module advance notice of upcoming admission and activation requests, and specifies theproper authorization action to be taken on those requests. Admission and activation requests from a CM are thenchecked by the Authorization Module to ensure that the ActiveQoSParameterSet being requested is a subset ofthe set provided by the policy server. Admission and activation requests from a CM that are signalled in advance

206


by the external policy server are permitted. Admission and activation requests from a CM that are not pre-signalled by the external policy server may result in a real-time query to the policy server, or may be refused.

During registration, the CM MUST send to the CMTS the authenticated set of TLVs derived from itsconfiguration file which defines the Provisioned QoS Parameter Set. Upon receipt and verification at the CMTS,these are handed to the Authorization Module within the CMTS. The CMTS MUST be capable of caching theProvisioned QoS Parameter Set, and MUST be able to use this information to authorize dynamic flows which area subset of the Provisioned QoS Parameter Set. The CMTS SHOULD implement mechanisms for overriding thisautomated approval process (such as described in the dynamic authorization model). For example:

• Deny all requests whether or not they have been pre-provisioned

• Define an internal table with a richer policy mechanism but seeded by the configuration file information

• Refer all requests to an external policy server

10.1.5 Types of Service Flows

It is useful to think about three basic types of Service Flows. This section describes these three types of ServiceFlows in more detail. However, it is important to note that there are more than just these three basic types. (Referto Section C.2.2.3.5)

10.1.5.1 Provisioned Service Flows

A Service Flow may be Provisioned but not immediately activated (sometimes called “deferred”). That is, thedescription of any such service flow in the TFTP configuration file contains an attribute which provisions butdefers activation and admission (refer to Section C.2.2.3.5). During Registration, the CMTS assigns a ServiceFlow ID for such a service flow but does not reserve resources. The CMTS MAY also require an exchange witha policy module prior to admission.

As a result of external action beyond the scope of this specification (e.g., [PKT-MGCP]), the CM MAY chooseto activate a Provisioned Service Flow by passing the Service Flow ID and the associated QoS Parameter Sets.The CM MUST also provide any applicable Classifiers. If authorized and resources are available, the CMTSMUST respond by assigning a unique unicast SID for the upstream Service Flow. The CMTS MAY deactivatethe Service Flow, but SHOULD NOT delete the Service Flow during the CM registration epoch.

As a result of external action beyond the scope of this specification (e.g., [PKT-MGCP]), the CMTS MAYchoose to activate a Service Flow by passing the Service Flow ID as well as the SID and the associated QoSParameter Sets. The CMTS MUST also provide any applicable Classifiers. The CMTS MAY deactivate theService Flow, but SHOULD NOT delete the Service Flow during the CM registration epoch. Such a ProvisionedService Flow MAY be activated and deactivated many times (through DSC exchanges). In all cases, the originalService Flow ID MUST be used when reactivating the service flow.

10.1.5.2 Admitted Service Flows

This protocol supports a two-phase activation model which is often utilized in telephony applications. In the two-phase activation model, the resources for a “call” are first “admitted,” and then once the end-to-end negotiation iscompleted (e.g., called party’s gateway generates an “off-hook” event) the resources are “activated.” Such a two-phase model serves the purposes of a) conserving network resources until a complete end-to-end connection hasbeen established, b) performing policy checks and admission control on resources as quickly as possible, and, inparticular, before informing the far end of a connection request, and c) preventing several potential theft-of-service scenarios.

207


For example, if an upper layer service were using unsolicited grant service, and the addition of upper-layer flowscould be adequately provided by increasing the Grants Per Interval QoS parameter, then the following might beused. When the first upper-layer flow is pending, the CM issues a DSA-Request with the Admit Grants PerInterval parameter equal one, and the Activate Grants Per Interval parameter equal zero. Later when the upper-layer flow becomes active, it issues a DSC-Request with the instance of the Activate Grants-per-Intervalparameter equal to one. Admission control was performed at the time of the reservation, so the later DSC-Request, having the Activate parameters within the range of the previous reservation, is guaranteed to succeed.Subsequent upper-layer flows would be handled in the same way. If there were three upper-layer flowsestablishing connections, with one flow already active, the Service Flow would have Admit(ted) Grants-per-Interval equal four, and Active Grants-per-Interval equal one.

An activation request of a Service Flow where the new ActiveQoSParamSet is a subset of the AdmittedQoS-ParamSet and no new classifiers are being added MUST be allowed (except in the case of catastrophic failure).An admission request where the AdmittedQoSParamSet is a subset of the previous AdmittedQoSParamSet, solong as the ActiveQoSParamSet remains a subset of the AdmittedQoSParameterSet, MUST succeed.

A Service Flow that has resources assigned to its AdmittedQoSParamSet, but whose resources are not yetcompletely activated, is in a transient state. A timeout value MUST be enforced by the CMTS that requiresService Flow activation within this period. (Refer to Section C.2.2.5.7) If Service Flow activation is notcompleted within this interval, the assigned resources in excess of the active QoS parameters MUST be releasedby the CMTS.

It is possible in some applications that a long-term reservation of resources is necessary or desirable. Forexample, placing a telephone call on hold should allow any resources in use for the call to be temporarilyallocated to other purposes, but these resources must be available for resumption of the call later. TheAdmittedQoSParamSet is maintained as “soft state” in the CMTS; this state must be refreshed periodically for itto be maintained without the above timeout releasing the non-activated resources. This refresh MAY be signalledwith a periodic DSC-REQ message with identical QoS Parameter Sets, or MAY be signalled by some internalmechanism within the CMTS outside of the scope of this specification (e.g., by the CMTS monitoring RSVPrefresh messages). Every time a refresh is signaled to the CMTS, the CMTS MUST refresh the “soft state.”

10.1.5.3 Active Service Flows

A Service Flow that has a non-NULL set of ActiveQoSParameters is said to be an Active Service Flow. It is

requesting1 and being granted bandwidth for transport of data packets. An admitted Service Flow may be madeactive by providing an ActiveQoSParameterSet, signaling the resources actually desired at the current time. Thiscompletes the second stage of the two-phase activation model. (Refer to Section 10.1.5.2)

A Service Flow may be Provisioned and immediately activated. This is the case for the Primary Service Flows. Itis also typical of Service Flows for monthly subscription services, etc. These Service Flows are established atregistration time and MUST be authorized by the CMTS based on the CMTS MIC. These Service Flows MAYalso be authorized by the CMTS authorization module.

Alternatively, a Service Flow may be created dynamically and immediately activated. In this case, two-phaseactivation is skipped and the Service Flow is available for immediate use upon authorization.

1. According to its Request/Transmission Policy (refer to Section C.2.2.6.3)

208


10.1.6 Service Flows and Classifiers

The basic model is that the Classifiers associate packets into exactly one Service Flow. The Service FlowEncodings provide the QoS Parameters for treatment of those packets on the RF interface. These encodings aredescribed in Section C.2.

In the upstream direction, the CM MUST classify upstream packets to Active Service Flows. The CMTS MUSTclassify downstream traffic to Active Downstream Service Flows. There MUST be a default downstream serviceflow for otherwise unclassified broadcast and multicast traffic.

The CMTS polices packets in upstream Service Flows to ensure the integrity of the QoS Parameters and thepacket’s TOS value. When the rate at which packets are sent is greater than the policed rate at the CMTS, thenthese packets MAY be dropped by the CMTS (refer to Section C.2.2.5.2). When the value of the TOS byte isincorrect, the CMTS (based on policy) MUST police the stream by overwriting the TOS byte (refer to SectionC.2.2.6.10).

It may not be possible for the CM to forward certain upstream packets on certain Service Flows. In particular, aService Flow using unsolicited grant service with fragmentation disabled cannot be used to forward packetslarger than the grant size. If a packet is classified to a Service Flow on which it cannot be transmitted, the CMMUST either transmit the packet on the Primary Service Flow or discard the packet depending on the Request/Transmission Policy of the Service Flow to which the packet was classified.

MAC Management messages may only be matched by a classifier that contains a C.2.1.6.3 “Ethertype/DSAP/MacType” parameter encoding and when the “type” field of the MAC Management Message Header (Section8.3.1) matches that parameter. One exception is that the Primary SID MUST be used for periodic ranging, asspecified in Section 8.1.2.3, even if a classifier matches the upstream RNG-REQ message of periodic ranging. Inthe absence of any classifier matching a MAC Management message, it SHOULD be transmitted on the PrimaryService Flow. Other than those MAC message types precluded from classification in Section C.2.1.6.3, a CM orCMTS MAY forward an otherwise unclassified MAC message on any Service Flow in an implementation-specific manner.

Although MAC Management messages are subject to classification, they are not considered part of any serviceflow. Transmission of MAC Management messages MUST NOT influence any QoS calculations of the ServiceFlow to which they are classified. Delivery of MAC Management messages is implicitly influenced by theattributes of the associated service flow.

10.1.6.1 Policy-Based Classification and Service Classes

As noted in Appendix I, there are a variety of ways in which packets may be enqueued for transmission at theMAC Service Interface. At one extreme are embedded applications that are tightly bound to a particular PayloadHeader Suppression Rule (refer to Section 10.4) and which forego more general classification by the MAC. Atthe other extreme are general transit packets of which nothing is known until they are parsed by the MACClassification rules. Another useful category is traffic to which policies are applied by a higher-layer entity andthen passed to the MAC for further classification to a particular service flow.

Policy-based classification is, in general, beyond the scope of this specification. One example might be thedocsDevFilterIpPolicyTable defined in the Cable Device MIB [RFC-2669]. Such policies may tend to be longer-lived than individual service flows and MAC classifiers and so it is appropriate to layer the two mechanisms,with a well-defined interface between policies and MAC Service Flow Classification.

The interface between the two layers is the addition of two parameters at the MAC transmission requestinterface. The two parameters are a Service Class Name and a Rule Priority that is applied to matching the

209


service class name. The Policy Priority is from the same number space as the Packet Classifier Priority of thepacket-matching rules used by MAC classifiers. The MAC Classification algorithm is now:

MAC_DATA.request( PDU, ServiceClassName, RulePriority )

TxServiceFlowID = FIND_FIRST_SERVICE_FLOW_ID (ServiceClassName)SearchID = SEARCH_CLASSIFIER_TABLE (All Priority Levels)IF (SearchID not NULL and Classifier.RulePriority >= MAC_DATA.RulePriority)

TxServiceFlowID = SearchID

IF (TxServiceFlowID = NULL)TRANSMIT_PDU (PrimaryServiceFlowID)

ELSETRANSMIT_PDU (TxServiceFlowID)

While Policy Priority competes with Packet Classifier Priority and its choice might in theory be problematic, it isanticipated that well-known ranges of priorities will be chosen to avoid ambiguity. In particular, dynamically-added classifiers MUST use the priority range 64-191. Classifiers created as part of registration, as well aspolicy-based classifiers, may use zero through 255, but SHOULD avoid the dynamic range.

Note: Classification within the MAC sublayer is intended to simply associate a packet with a service flow. If a packet isintended to be dropped it MUST be dropped by the higher-layer entity and not delivered to the MAC sublayer.

10.1.7 General Operation

10.1.7.1 Static Operation

Static configuration of Classifiers and Service Flows uses the Registration process. A provisioning serverprovides the CM with configuration information. The CM passes this information to the CMTS in a RegistrationRequest. The CMTS adds information and replies with a Registration Response. The CM sends a RegistrationAcknowledge to complete registration.

Figure 10-5 Registration Message Flow

A TFTP configuration file consists of one or more instances of Classifiers and Service Flow Encodings.Classifiers are loosely ordered by ‘priority’. Each Classifier refers to a Service Flow via a ‘service flow

Provisioning Server

CMTSRegistration-Ack

Registration-Request

Registration-Response

TFTP Configuration

CM

210


reference’. Several Classifiers may refer to the same Service Flow. Additionally, more than one Classifier mayhave the same priority, and in this case, the particular classifier used is not defined.

Table 10-1 TFTP File Contents

Service Flow Encodings contain either a full definition of service attributes (omitting defaultable items ifdesired) or a service class name. A service class name is an ASCII string which is known at the CMTS and whichindirectly specifies a set of QoS Parameters. (Refer to Sections 10.1.3 and C.2.2.3.4)

Note: At the time of the TFTP configuration file, Service Flow References exist as defined by the provisioning server. ServiceFlow Identifiers do not yet exist because the CMTS is unaware of these service flow definitions.

The Registration Request packet contains Downstream Classifiers (if to be immediately activated) and allInactive Service Flows. The configuration file, and thus, the Registration Request, generally does not contain aDownstream Classifier if the corresponding Service Flow is requested with deferred activation. This allows forlate binding of the Classifier when the Flow is activated.

Table 10-2 Registration Request Contents

The Registration Response sets the QoS Parameter Sets according to the Quality of Service Parameter Set Typein the Registration Request.

ItemsPoint To ServiceFlow Reference

Service FlowReference

ServiceFlow ID

Upstream ClassifiersEach containing a Service Flow Reference (pointer)

1..n

Downstream ClassifiersEach containing a Service Flow Reference (pointer)

(n+1)..q

Service Flow EncodingsImmediate activation requested, upstream

1..m None Yet

Service Flow EncodingsProvisioned for later activation requested, upstream

(m+1)..n None Yet

Service Flow EncodingsImmediate activation requested, downstream

(n+1)..p None Yet

Service Flow EncodingsProvisioned for later activation requested, downstream

(p+1)..q None Yet

ItemsPoint To ServiceFlow Reference

Service FlowReference

ServiceFlow ID

Upstream ClassifiersEach containing a Service Flow Reference (pointer)

1..n

Downstream ClassifiersEach containing a Service Flow Reference (pointer)

(n+1)..p

Service Flow EncodingsImmediate activation requested, upstreamMay specify explicit attributes or service class name

1..m None Yet

Service Flow EncodingsProvisioned for later activation requested, upstreamExplicit attributes or service class name

(m+1)..n None Yet

Service Flow EncodingsImmediate activation requested, downstreamExplicit attributes or service name

(n+1)..p None Yet

Service Flow EncodingsProvisioned for later activation requested, downstreamExplicit attributes or service name

(p+1)..q None Yet

211


The Registration Response preserves the Service Flow Reference attribute, so that the Service Flow Referencecan be associated with SFID and/or SID.

Table 10-3 Registration Response Contents

The SFID is chosen by the CMTS to identify a downstream or upstream service Flow that has been authorizedbut not activated. A DSC-Request from a modem to admit or activate a Provisioned Service Flow contains itsSFID. If it is a downstream Flow then the Downstream Classifier is also included.

10.1.7.2 Dynamic Service Flow Creation — CM Initiated

Service Flows may be created by the Dynamic Service Addition process, as well as through the Registrationprocess outlined above. The Dynamic Service Addition may be initiated by either the CM or the CMTS, and maycreate one upstream and/or one downstream dynamic Service Flow(s). A three-way handshake is used to createService Flows. The CM-initiated protocol is illustrated in Figure 10-6 and described in detail in Section 11.4.2.1.

Figure 10-6 Dynamic Service Addition Message Flow — CM Initiated

A DSA-Request from a CM contains Service Flow Reference(s), QoS Parameter set(s) (marked either foradmission-only or for admission and activation) and any required Classifiers.

10.1.7.3 Dynamic Service Flow Creation — CMTS Initiated

A DSA-Request from a CMTS contains Service Flow Identifier(s) for one upstream and/or one downstreamService Flow, possibly a SID, set(s) of active or admitted QoS Parameters, and any required Classifier(s). Theprotocol is as illustrated in Figure 10-7 and is described in detail in Section 11.4.2.2.

ItemsService Flow

ReferenceService Flow

IdentifierService

Identifier

Active Upstream Service FlowsExplicit attributes

1..m SFID SID

Provisioned Upstream Service FlowsExplicit attributes

(m+1)..n SFID Not Yet

Active Downstream Service FlowsExplicit attributes

(n+1)..p SFID N/A

Provisioned Downstream Service FlowsExplicit attributes

(p+1)..q SFID N/A

CMTSDSA-Acknowledge

DSA-Request

DSA-ResponseCM

212


Figure 10-7 Dynamic Service Addition Message Flow — CMTS Initiated

10.1.7.4 Dynamic Service Flow Modification and Deletion

In addition to the methods presented above for creating service flows, protocols are defined for modifying anddeleting service flows. Refer to Section 11.4.3 and Section 11.4.4.

Both provisioned and dynamically created Service flows are modified with the DSC message, which can changethe Admitted and Active QoS Parameter sets of the flow. The DSC can also add, replace, or delete classifiers,and add, add parameters to, or delete PHS rules.

A successful DSC transaction changes a Service Flow’s QoS parameters by replacing both the Admitted andActive QoS parameter sets. If the message contains only the Admitted set, the Active set is set to null and theflow is deactivated. If the message contains neither set (‘000’ value used for Quality of Service Parameter Settype, see Section C.2.2.3.5) then both sets are set to null and the flow is de-admitted. When the message containsboth QoS parameter sets, the Admitted set is checked first and, if admission control succeeds, the Active set inthe message is checked against the Admitted set in the message to ensure that it is a subset (see Section 10.1.1.1).If all checks are successful, the QoS parameter sets in the message become the new Admitted and Active QoSparameter sets for the Service Flow. If either of the checks fails, the DSC transaction fails and the Service FlowQoS parameter sets are unchanged.

10.2 Upstream Service Flow Scheduling Services

The following sections define the basic upstream Service Flow scheduling services and list the QoS parametersassociated with each service. A detailed description of each QoS parameter is provided in Annex C. The sectionalso discusses how these basic services and QoS parameters can be combined to form new services, such as,Committed Information Rate (CIR) service.

Scheduling services are designed to improve the efficiency of the poll/grant process. By specifying a schedulingservice and its associated QoS parameters, the CMTS can anticipate the throughput and latency needs of theupstream traffic and provide polls and/or grants at the appropriate times.

Each service is tailored to a specific type of data flow as described below. The basic services comprise:Unsolicited Grant Service (UGS), Real-Time Polling Service (rtPS), Unsolicited Grant Service with ActivityDetection (UGS-AD), Non-Real-Time Polling Service (nrtPS) and Best Effort (BE) service. Table 10-4 showsthe relationship between the scheduling services and the related QoS parameters.

CMTS

DSA-Acknowledge

DSA-Request

DSA-Response

CM

213


10.2.1 Unsolicited Grant Service

The Unsolicited Grant Service (UGS) is designed to support real-time service flows that generate fixed size datapackets on a periodic basis, such as Voice over IP. The service offers fixed size grants on a real-time periodicbasis, which eliminate the overhead and latency of CM requests and assure that grants will be available to meetthe flow’s real-time needs. The CMTS MUST provide fixed size data grants at periodic intervals to the ServiceFlow. In order for this service to work correctly, the Request/Transmission Policy (refer to Section C.2.2.6.3)setting MUST be such that the CM is prohibited from using any contention request or request/data opportunitiesand the CMTS SHOULD NOT provide any unicast request opportunities. The Request/Transmission PolicyMUST also prohibit piggyback requests. This will result in the CM only using unsolicited data grants forupstream transmission. All other bits of the Request/Transmission Policy are not relevant to the fundamentaloperation of this scheduling service and should be set according to network policy. The key service parametersare the Unsolicited Grant Size, the Nominal Grant interval, the Tolerated Grant Jitter and the Request/Transmission Policy. (Refer to Appendix VI)

The Unsolicited Grant Synchronization Header (UGSH) in the Service Flow EH Element (refer to Section8.2.6.3.2) is used to pass status information from the CM to the CMTS regarding the state of the UGS ServiceFlow. The most significant bit of the UGSH is the Queue Indicator (QI) bit. The CM MUST set this flag once itdetects that this Service Flow has exceeded its transmit queue depth. Once the CM detects that the ServiceFlow’s transmit queue is back within limits, it MUST clear the QI flag. The flag allows the CMTS to provide forlong term compensation for conditions such as lost maps or clock rate mismatch’s by issuing additional grants.

The CMTS MUST NOT allocate more grants per Nominal Grant Interval than the Grants Per Interval parameterof the Active QoS Parameter Set, excluding the case when the QI bit of the UGSH is set. In this case, the CMTSSHOULD grant up to 1% additional bandwidth for clock rate mismatch compensation. If the CMTS grantsadditional bandwidth, it MUST limit the total number of bytes forwarded on the flow during any time interval toMax(T), as described in the expression

Max(T) = T * (R*1.01) + 3B

Where Max(T) is the maximum number of bytes transmitted on the flow over a time T (in units of seconds), R =(grant_size * grants_per_interval)/nominal_grant_interval, and B = grant_size*grants_per_interval.

The active grants field of the UGSH is ignored with UGS service. The CMTS policing of the Service Flowremains unchanged.

10.2.2 Real-Time Polling Service

The Real-Time Polling Service (rtPS) is designed to support real-time service flows that generate variable sizedata packets on a periodic basis, such as MPEG video. The service offers real-time, periodic, unicast requestopportunities, which meet the flow’s real-time needs and allow the CM to specify the size of the desired grant.This service requires more request overhead than UGS, but supports variable grant sizes for optimum datatransport efficiency.

The CMTS MUST provide periodic unicast request opportunities. In order for this service to work correctly, theRequest/Transmission Policy setting (refer to Section C.2.2.6.3) SHOULD be such that the CM is prohibitedfrom using any contention request or request/data opportunities. The Request/Transmission Policy SHOULDalso prohibit piggyback requests. The CMTS MAY issue unicast request opportunities as prescribed by thisservice even if a grant is pending. This will result in the CM using only unicast request opportunities in order toobtain upstream transmission opportunities (the CM could still use unsolicited data grants for upstreamtransmission as well). All other bits of the Request/Transmission Policy are not relevant to the fundamentaloperation of this scheduling service and should be set according to network policy. The key service parametersare the Nominal Polling Interval, the Tolerated Poll Jitter and the Request/Transmission Policy.

214


10.2.3 Unsolicited Grant Service with Activity Detection

The Unsolicited Grant Service with Activity Detection (UGS/AD) is designed to support UGS flows that maybecome inactive for substantial portions of time (i.e., tens of milliseconds or more), such as Voice over IP withsilence suppression. The service provides Unsolicited Grants when the flow is active and unicast polls when theflow is inactive. This combines the low overhead and low latency of UGS with the efficiency of rtPS. ThoughUSG/AD combines UGS and rtPS, only one scheduling service is active at a time.

The CMTS MUST provide periodic unicast grants, when the flow is active, but MUST revert to providingperiodic unicast request opportunities when the flow is inactive. [The CMTS can detect flow inactivity bydetecting unused grants. However, the algorithm for detecting a flow changing from an active to an inactive stateis dependent on the CMTS implementation]. In order for this service to work correctly, the Request/Transmission Policy setting (refer to Section C.2.2.6.3) MUST be such that the CM is prohibited from using anycontention request or request/data opportunities. The Request/Transmission Policy MUST also prohibitpiggyback requests. This results in the CM using only unicast request opportunities in order to obtain upstreamtransmission opportunities. However, the CM will use unsolicited data grants for upstream transmission as well.All other bits of the Request/Transmission Policy are not relevant to the fundamental operation of this schedulingservice and should be set according to network policy. The key service parameters are the Nominal PollingInterval, the Tolerated Poll Jitter, the Nominal Grant Interval, the Tolerated Grant Jitter, the Unsolicited GrantSize and the Request/Transmission Policy.

In UGS-AD service, when restarting UGS after an interval of rtPS, the CMTS SHOULD provide additionalgrants in the first (and/or second) grant interval such that the CM receives a total of one grant for each grantinterval from the time the CM requested restart of UGS, plus one additional grant. (Refer to Appendix VI)Because the Service Flow is provisioned as a UGS flow with a specific grant interval and grant size, whenrestarting UGS, the CM MUST NOT request a different sized grant than the already provisioned UGS flow. Aswith any Service Flow, changes can only be requested with a DSC command. If the restarted activity requiresmore than one grant per interval, the CM MUST indicate this in the Active Grants field of the UGSHbeginning with the first packet sent.

The Service Flow Extended Header Element allows for the CM to dynamically state how many grants perinterval are required to support the number of flows with activity present. In UGS/AD, the CM MAY use theQueue Indicator Bit in the UGSH. The remaining seven bits of the UGSH define the Active Grants field. Thisfield defines the number of grants within a Nominal Grant Interval that this Service Flow currently requires.When using UGS/AD, the CM MUST indicate the number of requested grants per Nominal Grant Interval in thisfield. The Active Grants field of the UGSH is ignored with UGS without Activity Detection. This field allowsthe CM to signal to the CMTS to dynamically adjust the number of grants per interval that this UGS ServiceFlow is actually using. The CM MUST NOT request more than the number of Grants per Interval in theActiveQoSParameterSet.

If the CMTS allocates additional bandwidth in response to the QI bit, it MUST use the same rate limiting formulaas UGS, but the formula only applies to steady state periods where the CMTS has adjusted thegrants_per_interval to match the active_grants requested by the CM.

When the CM is receiving unsolicited grants and it detects no activity on the Service Flow, it MAY send onepacket with the Active Grants field set to zero grants and then cease transmission. Because this packet may notbe received by the CMTS, when the Service Flow goes from inactive to active the CM MUST be able to restarttransmission with either polled requests or unsolicited grants.

10.2.4 Non-Real-Time Polling Service

The Non-Real-Time Polling Service (nrtPS) is designed to support non real-time service flows that requirevariable size data grants on a regular basis, such as high bandwidth FTP. The service offers unicast polls on a

215


regular basis which assures that the flow receives request opportunities even during network congestion. TheCMTS typically polls nrtPS SIDs on an (periodic or non-periodic) interval on the order of one second or less.

The CMTS MUST provide timely unicast request opportunities. In order for this service to work correctly, theRequest/Transmission Policy setting (refer to Section C.2.2.6.2) SHOULD be such that the CM is allowed to usecontention request opportunities. This will result in the CM using contention request opportunities as well asunicast request opportunities and unsolicited data grants. All other bits of the Request/Transmission Policy arenot relevant to the fundamental operation of this scheduling service and should be set according to networkpolicy. The key service parameters are Nominal Polling Interval, Minimum Reserved Traffic Rate, MaximumSustained Traffic Rate, Request/Transmission Policy and Traffic Priority.

10.2.5 Best Effort Service

The intent of the Best Effort (BE) service is to provide efficient service to best effort traffic. In order for thisservice to work correctly, the Request/Transmission Policy setting SHOULD be such that the CM is allowed touse contention request opportunities. This will result in the CM using contention request opportunities as well asunicast request opportunities and unsolicited data grants. All other bits of the Request/Transmission Policy arenot relevant to the fundamental operation of this scheduling service and should be set according to networkpolicy. The key service parameters are the Minimum Reserved Traffic Rate, the Maximum Sustained TrafficRate, and the Traffic Priority.

10.2.6 Other Services

10.2.6.1 Committed Information Rate (CIR)

A Committed Information Rate (CIR) service can be defined a number of different ways. For example, it couldbe configured by using a Best Effort service with a Minimum Reserved Traffic Rate or a nrtPS with a MinimumReserved Traffic Rate.

10.2.7 Parameter Applicability for Upstream Service Scheduling

Table 10-4 summarizes the relationship between the scheduling services and key QoS parameters. A detaileddescription of each QoS parameter is provided in Annex C.

216


Table 10-4 Parameter Applicability for Upstream Service Scheduling1

a N/A means not applicable to this service flow scheduling type. If included in a request for a service flow of thisservice flow scheduling type, this request MUST be denied.

b Default is same as Nominal Grant Interval

* Default is CMTS-specific

10.2.8 CM Transmit Behavior

In order for these services to function correctly, all that is required of the CM in regards to its transmit behaviorfor a service flow, is for it to follow the rules specified in Section 9.4.3 and the Request/Transmission Policyspecified for the service flow.

10.3 Fragmentation

Fragmentation is an upstream CM “modem capability”. The CMTS MUST enable or disable this capability on aper-modem basis with a TLV in the Registration Response. The per-modem basis provides compatibility withDOCSIS1.0 CMs. Once fragmentation is enabled for a DOCSIS 1.1 modem, fragmentation is enabled on a per-Service Flow basis via the Request/Transmission Policy Configuration Settings. When enabled for a ServiceFlow, fragmentation is initiated by the CMTS when it grants bandwidth to a particular CM with a grant size thatis smaller than the corresponding bandwidth request from the CM. This is known as a Partial Grant.

1. Revised row nine of table “Dflt = 1522” to “Dflt = 3044”, per ECN RFI2-N-02210, by GO, on 11/21/02.

Service Flow Parameter Best Effort Non-Real-Time Polling

Real-TimePolling

UnsolicitedGrant

UnsolicitedGrant with

Activity Det.Miscellaneous• Traffic Priority Optional

Default = 0Optional

Default = 0N/Aa N/A N/A

• Max Concatenated Burst Optional Optional Optional N/A N/A• Upstream Scheduling

Service TypeOptional

Default = 2Mandatory Mandatory Mandatory Mandatory

• Request/TransmissionPolicy

OptionalDefault = 0

Mandatory Mandatory Mandatory Mandatory

Maximum Rate• Max Sustained Traffic Rate Optional

Default = 0Optional

Default = 0Optional

Default = 0N/A N/A

• Max Traffic Burst OptionalDflt = 3044

OptionalDflt = 3044

OptionalDflt = 3044

N/A N/A

Minimum Rate• Min Reserved Traffic Rate Optional

Default = 0Optional

Default = 0Optional

Default = 0N/A N/A

• Assumed Minimum …Packet Size

Optional* Optional* Optional* Optional* Optional*

Grants• Unsolicited Grant Size N/A N/A N/A Mandatory Mandatory• Grants per Interval N/A N/A N/A Mandatory Mandatory• Nominal Grant Interval N/A N/A N/A Mandatory Mandatory• Tolerated Grant Jitter N/A N/A N/A Mandatory MandatoryPolls• Nominal Polling Interval N/A Optional* Mandatory N/A Optionalb

• Tolerated Poll Jitter N/A N/A Optional* N/A Optional*

217


10.3.1 CM Fragmentation Support

Fragmentation is essentially encapsulation of a portion of a MAC Frame within a fixed size fragmentation headerand a fragment CRC. Concatenated PDUs, as well as single PDUs, are encapsulated in the same manner.Baseline Privacy, if enabled, is performed on each fragment as opposed to the complete original MAC frame.

The CM MUST perform fragmentation according to the flow diagram in Figure 10-8. The phrase “untransmittedportion of packet” in the flow diagram refers to the entire MAC frame when fragmentation has not been initiatedand to the remaining untransmitted portion of the original MAC frame when fragmentation has been initiated.

10.3.1.1 Fragmentation Rules:

1. Any time fragmentation is enabled and the grant size is smaller than the request, the CM MUST fill the partialgrant it receives with the maximum amount of data (fragment payload) possible accounting for fragmentationoverhead and physical layer overhead.

2. The CM MUST send up a piggyback request any time there is no later grant or grant pending for that SID inMAPs that have been received at the CM.

3. If the CM is fragmenting a frame,1 any piggyback request for the next fragment MUST be made in the BPIEHDR portion of the fragment header. Any piggyback request for a subsequent frame SHOULD be made inthe BPI EHDR portion of the last fragment, but MAY be made in one of the extended headers inside theoriginal frame. However, the same request MUST NOT be made in more than one place. Because the CMTScould ignore a request inside the original frame, making the request in the original frame may cause a loss ofthe request.2

4. In calculating bandwidth requests for the remainder of the frame (concatenated frame, if concatenated) thathas been fragmented, the CM MUST request enough bandwidth to transmit the entire remainder of the frameplus the 16-byte fragment overhead and all associated physical layer overhead.

5. If the CM does not receive a grant or grant pending within the ACK time of sending a request, the CM MUSTbackoff and re-request for the untransmitted portion of the frame until the bandwidth is granted or the CMexceeds its retry threshold.

6. If the CM exceeds its retry threshold while requesting bandwidth, the CM discards whatever portion of theframe was not previously transmitted.

7. The CM MUST set the F bit and clear the L bit in the first fragment of a frame.

8. The CM MUST clear the F and L bits in the fragment header for any fragments that occur between the firstand last fragments of a frame.

9. The CM MUST set the L bit and clear the F bit in the last fragment of a frame.

10.The CM MUST increment the fragment sequence number sequentially for each fragment of a frametransmitted.

11. If a frame is to be encrypted and the frame is fragmented, the frame is encrypted only at the fragment layerwith encryption beginning immediately after the fragment header HCS and continuing through the fragmentCRC.

12.Frames sent in immediate data (request/data) regions MUST NOT be fragmented.

1. ‘Frame’ always refers to either frames with a single Packet PDU or concatenated frames.2. Rule 3), last three sentences added per RFI2-N-02093 by RKV on 10/28/02.

218


Figure 10-8 CM Fragmentation Flowchart1

1. Revised Figure 10-8 per ECN RFI2-N-02215, chg #4, by GO, on 12/02/02.

RetriesExhausted?

Calculate amount tofragment and bandwidth

needed to transmitremainder (Request

Remainder)

Start

Grant smallerthan Request or

RequestRemainder?

Discarduntransmitted

portion of frame

No

Yes

Await FrameArrival

GrantPending?

Ack TimerExpired?

Grant forSid X?

Backoff ifnecessary and

request bandwidthfor Sid X

Process MAPInformationElements

Backoff andre-request foruntransmitted

portion of frame

No

Yes

Yes

No

Yes No No

Fragmentationallowed for this

SID?

Anotherframe inqueue?

Another Grant orGrant Pending in

MAP queue?

Send fragment withpiggyback field set to

request remainder

Discard Grant orSend up request in

granted slot

Send untransmittedportion of frame with

request for next framein piggyback field

Senduntransmitted

portion of frame withpiggyback field(s)=0

Send fragment withzero in the piggyback

field

No

No

Yes

Yes

Yes

No

Yes

219


10.3.2 CMTS Fragmentation Support

At the CMTS, the fragment is processed similarly to an ordinary packet with the exception that the baselineprivacy encryption starts just after the fragmentation header as opposed to being offset by 12 bytes.

The CMTS has two modes it can use to perform fragmentation. The Multiple Grant Mode assumes that theCMTS retains the state of the fragmentation. This mode allows the CMTS to have multiple partial grantsoutstanding for any given SID. The Piggybacking Mode assumes the CMTS does NOT retain any fragmentationstate. Only one partial grant is outstanding, so that the CM inserts the remaining amount into the Piggyback fieldof the fragment header. The type of mode being used is determined by the CMTS. In all cases, the CM operateswith a consistent set of rules.

10.3.2.1 Multiple Grant Mode

A CMTS MAY support Multiple Grant Mode for performing fragmentation.

Multiple Grant Mode allows the CMTS to break a request up into two or more grants in a single or oversuccessive maps and it calculates the additional overhead required in the remaining partial grants to satisfy therequest. In Multiple Grant Mode, if the CMTS cannot grant the remainder in the current MAP, it MUST send agrant pending (zero length grant) in the current MAP and all subsequent MAPs to the CM until it can grantadditional bandwidth. If there is no grant or grant pending in subsequent MAPs, the CM MUST re-request for theremainder. This re-request mechanism is the same as that used when a normal REQ does not receive a grant orgrant pending within the ACK time.

If a CM receives a grant pending IE along with a fragment grant, it MUST NOT piggyback a request in theextended header of the fragment transmitted in that grant.

In the case where the CM misses a grant and re-requests the remaining bandwidth, the CMTS MUST recoverwithout dropping the frame.

Due to the imprecision of the mini-slot to byte conversion process the CMTS may not be able to calculate exactlythe number of extra mini-slots needed to allow for fragmentation overhead. Also because it is possible for a CMto have missed a map with a partial grant, and thus to be requesting to send an unsent fragment rather than a newPDU, the CMTS can not be certain whether the CM has already accounted for fragmentation overhead in arequest. Therefore the CMTS MUST make sure that any fragment payload remainder is at least one mini-slotgreater than the number of mini-slots needed to contain the overhead for a fragment (16 bytes) plus the physicallayer overhead necessary to transmit a minimum sized fragment. Failure to do this may cause the CMTS to issuea grant that is not needed as the CM has completed transmission of the fragment payload remainder using theprevious partial grant. This may cause the CM to get out of sync with the CMTS by inadvertently starting a newfragmentation. Also the CMTS needs to deal with the fact that with certain sets of physical layer parameters, theCM may request one more mini-slot than the maximum size of a short data grant, but not actually need that manymini-slots. This happens in the case where the CM needs to push the request size beyond the short data grantlimit. The CMTS needs a policy to ensure that fragmenting such requests in multiple grant mode does not lead tounneeded fragmentary grants.

10.3.2.2 Piggyback Mode

A CMTS MAY support Piggyback Mode for performing fragmentation.

If the CMTS does not put another partial grant or a grant pending in the MAP in which it initiates fragmentationon a SID, the CM MUST automatically piggyback for the remainder. The CM calculates how much of a framecan be sent in the granted bandwidth and forms a fragment to send it. The CM utilizes the piggyback field in thefragment extended header to request the bandwidth necessary to transfer the remainder of the frame. Since the

220


CMTS did not indicate a multiple grant in the first fragment MAP, the CM MUST keep track of the remainder tosend. The request length, including physical-layer and fragmentation overhead, for the remainder of the originalframe is inserted into the piggyback request byte in the fragmentation header.

If the fragment HCS is correct, the piggybacked request, if present, is passed on to the bandwidth allocationprocess while the fragment itself is enqueued for reassembly. Once the complete MAC frame is reassembled andit has been determined that the HCS is correct, the CMTS processes the frame as though it had been receivedunfragmented except that the CMTS MUST ignore the decryption related portion of any privacy EHDRs.However, the bandwidth requests in privacy EHDRs and request EHDRs of such frame SHOULD be processed,but they MAY be ignored also.1

10.3.3 Fragmentation Example

10.3.3.1 Single Packet Fragmentation

Refer to Figure 10-8. Assume that fragmentation has been enabled for a given SID.

1. (Requesting State)- CM wants to transmit a 1018 byte packet. CM calculates how much physical layeroverhead (POH) is required and requests the appropriate number of mini-slots. CM makes a request in acontention region. Go to step 2.

2. (Waiting for Grant)- CM monitors MAPs for a grant or grant pending for this SID. If the CM’s ACK timeexpires before the CM receives a grant or grant pending, the CM retries requesting for the packet until theretry count is exhausted - then the CM gives up on that packet. Go to step 3.

3. (First Fragment)- Prior to giving up in step 2, the CM sees a grant for this SID that is less than the requestednumber of mini-slots. The CM calculates how much MAC information can be sent in the granted number ofmini-slots using the specified burst profile. In the example in Figure 10-9, the first grant can hold 900 bytesafter subtracting the POH. Since the fragment overhead (FRAG HDR, FHCS, and FCRC) is 16 bytes, 884bytes of the original packet can be carried in the fragment. The CM creates a fragment composed of theFRAG HDR, FHCS, 884 bytes of the original packet, and an FCRC. The CM marks the fragment as first andprepares to send the fragment. Go to step 4.

4. (First Fragment, multiple grant mode)- CM looks to see if there are any other grants or grant pendingsenqueued for this SID. If so, the CM sends the fragment with the piggyback field in the FRAG HDR set tozero and awaits the time of the subsequent grant to roll around. Go to step 6. If there are not any grants orgrant pendings, go to step 5.

5. (First Fragment, piggyback mode)- If there are no other grants or grant pendings for this SID in this MAP, theCM calculates how many mini-slots are required to send the remainder of the fragmented packet, includingthe fragmentation overhead, and physical layer overhead, and inserts this amount into the piggyback field ofthe FRAG HDR. The CM then sends the fragment and starts its ACK timer for the piggyback request. In theexample in Figure 10-9, the CM sends up a request for enough mini-slots to hold the POH plus 150 bytes(1018-884+16). Go to step 6.

6. (Waiting for Grant)- The CM is now waiting for a grant for the next fragment. If the CM’s ACK timer expireswhile waiting on this grant, the CM should send up a request for enough mini-slots to send the remainder ofthe fragmented packet, including the fragmentation overhead, and physical layer overhead. Go to step 7.

7. (Receives next fragment grant)- Prior to giving up in step 6, the CM sees another grant for this SID. The CMchecks to see if the grant size is large enough to hold the remainder of the fragmented packet, including thefragmentation overhead and physical layer overhead. If so, go to step 10. If not, go to step 8.

1. Last two sentences updated per RFI2-N-02093 by RKV on 10/28/02.

221


8. (Middle Fragment, multiple grant mode)- Since the remainder of the packet (plus overhead) will not fit in thegrant, the CM calculates what portion will fit. The CM encapsulates this portion of the packet as a middlefragment. The CM then looks for any other grants or grant pendings enqueued for this SID. If either arepresent, the CM sends the fragment with the piggyback field in the FRAG HDR set to zero and awaits thetime of the subsequent grant to roll around. Go to step 6. If there are not any grants or grant pendings, go tostep 9.

9. (Middle Fragment, piggyback mode) - The CM calculates how many mini-slots are required to send theremainder of the fragmented packet, including the fragmentation overhead and physical layer overhead, andinserts this amount into the piggyback field of the FRAG HDR. The CM then sends the fragment and starts itsACK timer for the piggyback request. Go to step 6.

10. (Last Fragment) - The CM encapsulates the remainder of the packet as a last fragment. If there is no otherpacket enqueued or there is a another grant or a grant pending enqueued for this SID, the CM places a zero inthe REQ field of the FRAG HDR. If there is another packet enqueued with no grant of grant pending, the CMcalculates the number of mini-slots required to send the next packet and places this number in the REQ fieldin the FRAG HDR. The CM then transmits the packet. Go to step 11. In the example in Figure 10-9, the grantis large enough to hold the remaining 150 bytes plus POH.

11. (Normal operation)- The CM then returns the normal operation of waiting for grants and requesting forpackets. If at any time fragmentation is enabled and a grant arrives that is smaller than the request, thefragmentation process starts again as in step 2.

222


Figure 10-9 Example of Fragmenting a Single Packet

10.3.3.2 Concatenated Packet Fragmentation

After the CM creates the concatenated packet, the CM treats the concatenated packet as a single PDU. Figure 10-10 shows an example of a concatenated packet broken into 3 fragments. Note that the packet is fragmentedwithout regard to the packet boundaries within the concatenated packet.

Fragment Payload

Original Packetwith BPI EHDR(1018 Bytes)

134 (1018-884) Bytes sent in last fragment

884 (900-16) Bytes sent in first fragment

1B 1000B4B1B 2B 2B

FC LENPARM

4B 4B

PRV other EHDRs HCS PDU payload PCRC

First Grant canfit 900 bytes of

MACinformation

FCRCFHCSFRAG HDR

10B 2B 1B 1B 2B 4B 4B 2B 870B 4B

Encrypted under Baseline Privacy

FC LENPARM PRV other EHDRs HCS PDU payload (first)

FCEHDR

LEN = 6 LEN BPI EHDR

1B 1B 2B 6B

0001111 11B 1B 2B 1B 1B

00100000

35 Ver E|T|OoS_SID RQ Frag Cntl

Request for enoughminislots to fit 150

(130+4+16) bytes of MACinfo. This field would be

zero in multiple grant mode.

10B 2B 130B 4B 4B

FRAG HDR FHCS FCRCPCRCPDU payload (cont)

FCEHDR


0001111 11B 2B 1B 1B

00010001

35 Ver E|T|OoS_SID RQ Frag Cntl

Piggyback request for nextPDU (if applicable)

Second Grant canfit 150 bytes of

MACinformation

Frag Cntl Bit DefinitionEncrypted under Baseline Privacy

XXFLSSSS

F - Set on First fragment, clear otherwiseL - Set on Last fragment, clear otherwiseSSSS - 4 bit sequence number,increments on each fragment of a frame,rolling over as necessaryXX - Reserved, set to 00

223


Figure 10-10 Fragmented Concatenated Packet Example

Original Concatenated Packet (287) Bytes

6B 70B4B15B 68B 100B6B 4B

PDU payload 3 PCRC3

First Grant canfit 125 bytes of

MACinformation

FCRCFHCSFRAG HDR

10B 2B 6B 68B 4B 6B 10B 4B


PDU payload 2 (part1)

FCEHDR


1B 1B 2B 6B

0001111 11B 1B 2B 1B 1B

00100000

35 01 E|T|QoS_SID RQ Frag Cntl

Request for enough minislots to fit162 (287-109+16) bytes of MAC info.

This field would be zero in multiplegrant mode.

10B 2B 90B 4B 10B

FRAG HDR FHCS FCRCPDU payld 3 (part)

FCEHDR


0001111 1

1B 2B 1B 1B

00000001


Request for enough minislots to fit 64(287-109-130+16) bytes of MAC info.

This field would be zero in multiplegrant mode.

Second Grant canfit 146 bytes of

MACinformation


4B 10B

MAC HDR3PCRC2PDU payload 2MAC HDR2PCRC1PDU payload 1MAC HDR1Concat. HDR

FCEHDR

LEN = 6 LEN HCS

1B 1B 2B 2B

FC PRV HCS

1B 1B 2B 2B

other EHDRs

5B4B

LENPARM

MAC HDR2PCRC1PDU payload 1MAC HDR1Concat. HDR

MAC HDR3PCRC2PDU payld 2 (part)

Third Grant canfit 64 bytes of

MACinformation

26B 4B

1B

1B 1B 2B 6B

10B 2B 44B 4B 4B

FRAG HDR FHCS FCRC

FCEHDR


0001111 1

1B 2B 1B 1B

00010010


Request for packet


PCRC3PDU payld 3 (part)

1B

1B 1B 2B 6B

15B

224


10.4 Payload Header Suppression

The overview section explains the principles of Payload Header Suppression. The subsequent sections explainthe signaling for initialization, operation, and termination. Finally, specific upstream and downstream examplesare given. The following definitions are used:

Table 10-5 Payload Header Suppression Definitions

10.4.1 Overview

In Payload Header Suppression, a repetitive portion of the payload headers following the Extended Header fieldis suppressed by the sending entity and restored by the receiving entity. In the upstream, the sending entity is theCM and the receiving entity is the CMTS. In the downstream, the sending entity is the CMTS and the receivingentity is the CM. The MAC Extended Header contains a Payload Header Suppression Index (PHSI) whichreferences the Payload Header Suppression Field (PHSF).

Although PHS may be used with any Service Flow Type, it has been designed for use with the Unsolicited GrantService (UGS) Scheduling Type. UGS works most efficiently with packets of a fixed length. PHS works wellwith UGS because, unlike other header compression schemes sometimes used with IP data, PHS alwayssuppresses the same number of bytes in each packet. PHS will always produce a fixed length compressed packetheader.

The sending entity uses Classifiers to map packets into a Service Flow. The Classifier uniquely maps packets toits associated Payload Header Suppression Rule. The receiving entity uses the Service Identifier (SID) and thePHSI to restore the PHSR.

Once the PHSF and PHSS fields of a rule are known, the rule is considered “fully defined” and none of its fieldscan be changed. If modified PHS operation is desired for packets classified to the flow, the old rule must beremoved from the Service Flow, and a new rule must be installed.

When a classifier is deleted, any associated PHS rule MUST also be deleted.

PHS Payload Header Suppression Suppressing an initial byte string at the sender and restor-ing the byte string at the receiver.

PHS Rule Payload Header Suppression Rule A set of TLV’s that apply to a specific PHS Index.

PHSF Payload Header Suppression Field A string of bytes representing the header portion of a PDUin which one or more bytes will be suppressed (i.e., a snap-shot of the uncompressed PDU header inclusive of sup-pressed and unsuppressed bytes).

PHSI Payload Header Suppression Index An 8-bit value which references the suppressed bytestring.

PHSM Payload Header Suppression Mask A bit mask which indicates which bytes in the PHSF tosuppress, and which bytes to not suppress.

PHSS Payload Header Suppression Size The length of the Suppressed Field in bytes. This value isequivalent to the number of bytes in the PHSF and also thenumber of valid bits in the PHSM

PHSV Payload Header Suppression Verify A flag which tells the sending entity to verify all byteswhich are to be suppressed.

225


PHS has a PHSV option to verify or not verify the payload before suppressing it. PHS also has a PHSM option toallow select bytes not to be suppressed. This is used for sending bytes which change such as IP sequencenumbers, and still suppressing bytes which do not change.

PHS rules are consistent for all scheduling service types. Requests and grants of bandwidth are specified aftersuppression has been accounted for. For Unsolicited Grant Services, the grant size is chosen with the UnsolicitedGrant Size TLV. The packet with its header suppressed may be equal to or less than the grant size.

The CMTS MUST assign all PHSI values just as it assigns all SID values. Either the sending or the receivingentity MAY specify the PHSF and PHSS. This provision allows for pre-configured headers, or for higher levelsignaling protocols outside the scope of this specification to establish cache entries. PHS is intended for unicastservice, and is not defined for multicast service.

It is the responsibility of the higher-layer service entity to generate a PHS Rule which uniquely identifies thesuppressed header within the Service Flow. It is also the responsibility of the higher-layer service entity toguarantee that the byte strings being suppressed are constant from packet to packet for the duration of the ActiveService Flow.

10.4.2 Example Applications

• A Classifier on an upstream Service Flow which uniquely defines a Voice-over-IP (VoIP) flow by specifyingProtocol Type of UDP, IP SA, IP DA, UDP Source Port, UDP Destination Port, the Service Flow Reference,and a PHS Size of 42 bytes. A PHS Rule references this Classifier providing a PHSI value which identifiesthis VoIP media flow. For the upstream case, 42 bytes of payload header are verified and suppressed, and a 2byte extended header containing the PHSI is added to every packet in that media flow.

• A Classifier which identifies the packets in a Service Flow, of which 90% match the PHSR. Verification isenabled. This may apply in a packet compression situation where every so often compression resets are doneand the header varies. In this example, the scheduling algorithm would allow variable bandwidth, and only90% of the packets might get their headers suppressed. Since the existence of the PHSI extended header willindicate the choice made, the simple SID/PHSI lookup at the receiving entity will always yield the correctresult.

• A Classifier on an upstream Service Flow which identifies all IP packets by specifying Ethertype of IP, theService Flow ID, a PHSS of 14 bytes, and no verification by the sending entity. In this example, the CMTShas decided to route the packet, and knows that it will not require the first 14 bytes of the Ethernet header,even though some parts such as the Source Address or Destination Address may vary. The CM removes 14bytes from each upstream frame (Ethernet Header) without verifying their contents and forwards the frame tothe Service Flow.

10.4.3 Operation

To clarify operational packet flow, this section describes one potential implementation. CM and CMTSimplementations are free to implement Payload Header Suppression in any manner as long as the protocolspecified in this section is followed. Figure 10-11 illustrates the following procedure.

A packet is submitted to the CM MAC Service Layer. The CM applies its list of Classifier rules. A match of therule will result in an Upstream Service Flow, SID, and a PHS Rule. The PHS Rule provides PHSF, PHSI, PHSM,PHSS, and PHSV. If PHSV is set to zero, or is not present, the CM will compare the bytes in the packet headerwith the bytes in the PHSF that are to be suppressed as indicated by the PHSM. If they match, the CM willsuppress all the bytes in the Upstream Suppression Field except the bytes masked by PHSM. The CM will theninsert the PHSI into the PHS_Parm field of the Service Flow EH Element, and queue the packet on the UpstreamService Flow.

226


When the packet is received by the CMTS, the CMTS will determine the associated SID either by internal meansor from other Extended Headers elements such as the BPI Extended Header. The CMTS uses the SID and thePHSI to look up PHSF, PHSM, and PHSS. The CMTS reassembles the packet and then proceeds with normalpacket processing. The reassembled packet will contain bytes from the PHSF. If verification was enabled, thenthe PHSF bytes will equal the original header byes. If verification was not enabled, then there is no guaranteethat the PHSF bytes will match the original header bytes.

227


Figure 10-11 Payload Header Suppression Operation

Sender PHS Start Receiver PHS Start

Packet Arrives

Classify Packet.Retrieve PHSF, PHSI,PHSM, PHSS, PHSV

Identify SID andextract PHSI

Verify?

Yes

Verify withPHSF

PassVerify?

Yes

Suppress withPHSM

Append PHSI

ForwardPacket

END

END

ForwardPacket

Retrieve PHSF,PHSM, PHSS

ReconstructHeader and

forward packet

No

No

Packet Arrives

228


A similar operation occurs in the downstream. The CMTS applies its list of Classifiers. A match of the Classifierwill result in a Downstream Service Flow and a PHS Rule. The PHS Rule provides PHSF, PHSI, PHSM, PHSS,and PHSV. If PHSV is set to zero, or is not present, the CMTS will verify the Downstream Suppression Field inthe packet with the PHSF. If they match, the CMTS will suppress all the bytes in the Downstream SuppressionField except the bytes masked by PHSM. The CMTS will then insert the PHSI into the PHS_Parm field of theService Flow EH Element, and queue the packet on the Downstream Service Flow.

The CM will receive the packet based upon the Ethernet Destination Address filtering. The CM then uses thePHSI to lookup PHSF, PHSM, and PHSS. The CM reassembles the packet and then proceeds with normal packetprocessing.

Figure 10-12 demonstrates packet suppression and restoration when using PHS masking. Masking allows onlybytes which do not change to be suppressed. Note that the PHSF and PHSM span the entire Suppression Field,including suppressed and unsuppressed bytes.

Figure 10-12 Payload Header Suppression with Masking

10.4.4 Signaling

Payload Header Suppression requires the creation of three objects:

• Service Flow

• Classifier

• Payload Header Suppression Rule

These three objects MAY be created in separate message flows, or MAY be created simultaneously.

Sender

CableNetwork

Receiver

PHSM

PHSF

PHSM

PHSF

A B C D E

1 0 01 1

A' X C' X E'

B D

1 0 01 1

A' X C' X E'

A' C' E'B D

= Verify

= Assign

A - E = current headerA' - E' = cached header

X = don't carePHSS = 5

229


PHS Rules are created with Registration, DSA, or DSC messages. The CMTS MUST define the PHSI when thePHS Rule is created. PHS Rules are deleted with the DSC or DSD messages. The CM or CMTS MAY define thePHSS and PHSF.

Figure 10-13 shows the two ways to signal the creation of a PHS Rule.

It is possible to partially define a PHS rule (in particular the size of the rule) at the time a Service Flow is created.

As an example, it is likely that when a Service Flow is first provisioned the size of the header field to besuppressed will be known. The values of some items within the field (e.g., IP addresses, UDP port numbers, etc.)may not be known and would be provided in a subsequent DSC as part of the activation of the Service Flow(using the “Set PHS Rule” DSC Action).

A PHS rule is partially defined when the PHSF and PHSS field values are not both known. Once both PHSF andPHSS are known, the rule is considered fully defined, and MUST NOT be modified via DSC signaling. PHSVand PHSM fields have default values, thus are not required to fully define a PHS rule. If PHSV and PHSM arenot known when the rule becomes fully defined, their default values are used, and MUST NOT be modified viaDSC signaling.

Each step of the PHS rule definition, whether it is a registration request, DSA or a DSC, MUST contain ServiceFlow ID (or reference), Classifier ID (or reference) to uniquely identify the PHS rule being defined. A PHSIndex and Service ID pair is used to uniquely identify the PHS rule during upstream packet transfer. A PHSIndex is enough to uniquely identify the PHS rule used in downstream packet transfer.

10.4.5 Payload Header Suppression Examples

10.4.5.1 Upstream Example

A Service Class with the Service Class Name of “G711-US-UGS-HS-42” is established which is intended forITU-T Recommendation G.711 VoIP traffic in the upstream with Unsolicited Grant Service. When Classifiersare added to the flow, a PHSS value of 42 is included which explicitly states that the first 42 bytes following theMAC Extended Header on all packets in that flow must be verified, suppressed, and restored. In this example,the Service Class is configured such that any packet which does not verify correctly will not have its headersuppressed and will be discarded since it will exceed the Unsolicited Grant Size. (Refer to Section C.2.2.6.3)

CMTS Initiated CM Initiated

Figure 10-13 Payload Header Suppression Signaling Example

CMTS CM

DSC-REQ

DSC-RSP

DSC-ACK

Classifier ID +

+ PHSI + PHSS + PHSF

Service Flow ID

CMTS CM

DSC-REQ

DSC-RSP

DSC-ACK

Classifier Reference/

+ PHSS + PHSF

PHSI

ID + Service Flow ID

230


Figure 10-14 shows the encapsulation used in the upstream with and without Payload Header Suppression. AnRTP Voice over IP Payload without IPsec is used as a specific example to demonstrate efficiency.

Figure 10-14a shows a normal RTP packet carried on an upstream channel. The beginning of the framerepresents the physical layer overhead (FGPS) of FEC, guard time, preamble, and stuffing bytes. Stuffing bytesoccur in the last code word and when mapping blocks to mini-slots. Next is the MAC layer overhead includingthe 6 byte MAC header with a 5 byte BPI Extended Header, the 14 byte Ethernet Header, and the 4 byte EthernetCRC trailer. The VoIP payload uses a 20 byte IP header, an 8 byte UDP header, and a 12 byte RTP header. Thevoice payload is variable and depends upon the sample time and the compression algorithm used.

Figure 10-14b shows the same payload with Payload Header Suppression enabled. In the upstream, PayloadHeader Suppression begins with the first byte after the MAC Header Checksum. The 14 byte Ethernet header,the 20 byte IP header, and the 8 byte UDP header have been suppressed, and a 2 byte PHS Extended Headerelement has been added, for a net reduction of 40 bytes. In this example of an established VoIP connection, thesefields remain constant from packet to packet, and are otherwise redundant.

10.4.5.2 Downstream Example

A Service Class with the Service Class Name of “G711-DS-HS-30” is established which is intended for G.711VoIP traffic in the downstream. When Classifiers are added to the Service Flow, a PHSS value of 30 is includedwhich explicitly indicates that 30 bytes of the payload header on all packets must be processed for suppressionand restoration according to the PHSM. Any packet which does not verify correctly will not have its headersuppressed but will be transmitted subject to the traffic shaping rules in place for that Service Flow.

Figure 10-14 Upstream Payload Header Suppression Example

a) VolP with Normal Encapsulation

14-34 4 5 2 14 20 8 12 10 to 160 4

14-34 4 5 2 2 12 10 to 160 4

b) VolP with Header Suppression

values in bytes

FGPS MAC OH BPI HCS Ethernet IP UDP RTP Voice Bytes CRC

FGPS MAC OH BPI P HCS RTP Voice Bytes CRC

231


Figure 10-15 shows the encapsulation used in the downstream with and without Payload Header Suppression. AnRTP Voice over IP Payload without IPsec is used as a specific example to demonstrate efficiency.

Figure 10-15a shows a normal RTP packet carried on a downstream channel. The Layer 2 overhead includes the6 byte MAC header with a 5 byte BPI Extended Header, the 14-byte Ethernet Header (6-byte DestinationAddress, 6-byte Source Address, and 2-byte EtherType field), and the 4-byte Ethernet CRC trailer. The Layer 3VoIP payload uses a 20-byte IP header, an 8 byte UDP header, and a 12-byte RTP header. The voice payload isvariable and depends upon the sample time and the compression algorithm used.

Figure 10-15b shows the same payload with Payload Header Suppression enabled. In the downstream, PayloadHeader Suppression begins with the thirteenth byte after the MAC Header Checksum. This retains the EthernetDestination Address and Source Address which is required so that the CM may filter and receive the packet. Theremaining 2 bytes of the Ethernet Header, the 20-byte IP header, and the 8-byte UDP header have beensuppressed, and a 2 byte PHS Extended Header element has been added, for a net reduction of 28-bytes. In thisexample of an established VoIP connection, these fields remain constant from packet to packet, and are thusredundant.

Figure 10-15 Downstream Payload Header Suppression Example

a) VolP with Normal Encapsulation

4 5 2 20 8 12 10 to 160 4

4 5 2 2 12 10 to 160 4

b) VolP with Header Suppression

values in bytes

MAC OH BPI HCS SA UDP RTP Voice Bytes CRC

MAC OH BPI P HCS RTP Voice Bytes CRC

DA T IP

6 6 2

DA SA

6 6

232


11 Cable Modem - CMTS Interaction

This section covers the key requirements for the interaction between a CM and a CMTS. It only coversinteraction between a CM and CMTS that are both compliant with this version of the specification, and only inthe case where the CM is using a configuration file with QOS parameters compliant with this version of thespecification. Issues involving interoperability with equipment and configuration files compliant with previousversions of this specification are discussed in Annex G. The interaction can be broken down into five basiccategories: initialization, authentication, configuration, authorization, and signaling.

11.1 CMTS Initialization

The mechanism utilized for CMTS initialization (local terminal, file download, SNMP, etc.) is described in[DOCSIS5]. It MUST meet the following criteria for system interoperability.

• The CMTS MUST be able to reboot and operate in a stand-alone mode using configuration data retained innon-volatile storage.

• If valid parameters are not available from non-volatile storage or via another mechanism such as the Spec-trum Management System (see [SMS]), the CMTS MUST NOT generate any downstream messages (includ-ing SYNC). This will prevent CMs from transmitting.

• The CMTS MUST provide the information defined in Section 8, “Media Access Control Specification,” onpage 107 to CMs for each upstream channel.

11.2 Cable Modem Initialization

The procedure for initialization of a cable modem MUST be as shown in Figure 11-1. This figure shows theoverall flow between the stages of initialization in a CM. This shows no error paths, and is simply to provide anoverview of the process. The more detailed finite state machine representations of the individual sections(including error paths) are shown in the subsequent figures. Timeout values are defined in Annex B.

The procedure for initializing a cable modem and for a CM to reinitialize its MAC can be divided into thefollowing phases:

• Scanning and synchronization to downstream

• Obtain upstream parameters

• Ranging and automatic adjustments

• Device Class Identification (optional)

• Establish IP connectivity

• Establish time of day

• Transfer operational parameters

• Registration

• Baseline Privacy initialization, if CM is provisioned to run Baseline Privacy

Each CM contains the following information when shipped from the manufacturer:

• A unique IEEE 802 48-bit MAC address which is assigned during the manufacturing process. This is used toidentify the modem to the various provisioning servers during initialization.

• Security information as defined in [DOCSIS8] (e.g., X.509 certificate) used to authenticate the CM to thesecurity server and authenticate the responses from the security and provisioning servers.

233


The SDL (Specification and Description Language) notation used in the following figures is shown in Figure 11-2 (refer to ITU-T Recommendation Z.100 [ITU-T Z.100]).

Figure 11-1 CM Initialization Overview

Scan forDownstream

Channel

DownstreamSync

Established

ObtainUpstream

Parameters

UpstreamParameters

Aquired

Ranging &Automatic

Adjustments

Ranging &Auto AdjComplete

Device ClassIdentification

(optional)

EstablishIP

Connectivity

IPComplete

EstablishTime of

Day

Time of DayEstablished

TransferOperationalParameters

TransferComplete

Registerwith

CMTS

RegistrationComplete

*1

BaselinePrivacy

Initialization

BaselinePrivacy

Initialized

Operational

*1: Baseline Privacy enabled

Yes

No

234


Figure 11-2 SDL Notation

11.2.1 Scanning and Synchronization to Downstream

On initialization or a “Reinitialize MAC” operation, the cable modem MUST acquire a downstream channel.The CM MUST have non-volatile storage in which the last operational parameters are stored and MUST first tryto re-acquire this downstream channel. If this fails, it MUST begin to continuously scan the 6-MHz channels ofthe downstream frequency band of operation until it finds a valid downstream signal.

A downstream signal is considered to be valid when the modem has achieved the following steps:

• synchronization of the QAM symbol timing

• synchronization of the FEC framing

• synchronization of the MPEG packetization

• recognition of SYNC downstream MAC messages

While scanning, it is desirable to give an indication to the user that the CM is doing so.

In order to support redundant CMTS architectures, when a CM in the Operational state detects that thedownstream signal is invalid (i.e., does not meet the four criteria above), the CM MUST NOT immediatelyperform a Reinitialize MAC operation. It must instead attempt to re-establish synchronization on the currentdownstream channel (see Section 11.5). Such re-establishment attempts MUST continue until the operation ofPeriodic Ranging as specified in Figure 11-17 of Section 11.3.1 calls for a “Re-initialize MAC” operation afterthe expiration of Timeout T4 or 16 expirations of Timeout T3. Figure 11-17 shows the procedure that MUST befollowed by a cable modem during standard operation.

State symbol

Input symbols Internal

External

Task symbol

Output symbols

Internal

External

Decision symbol

235


11.2.2 Obtain Upstream Parameters

Refer to Figure 11-3. After synchronization, the CM MUST wait for an upstream channel descriptor message(UCD) from the CMTS in order to retrieve a set of transmission parameters for a possible upstream channel.These messages are transmitted periodically from the CMTS for all available upstream channels and areaddressed to the MAC broadcast address. The CM MUST determine whether it can use the upstream channelfrom the channel description parameters.

The CM MUST collect all UCDs with different channel ID fields to build a set of usable channel IDs. If nochannel can be found after a suitable timeout period, the CM MUST continue scanning to find anotherdownstream channel.

The CM MUST determine whether it can use the upstream channel from the channel description parameters. Ifthe channel is not suitable, the CM MUST try other channels until it finds a usable channel.

Before attempting initial ranging on an upstream, the CM categorizes the available upstreams into the followingtypes based on the UCD for each channel:

1. With a UCD (MAC management message type 2) offering DOCSIS 1.x burst descriptors only.

2. With a UCD (MAC management message type 2) offering both DOCSIS 2.0 TDMA and DOCSIS 1.x burstdescriptors.

3. With a UCD (MAC management message type 29) for a DOCSIS 2.0 Only Upstream.

The CM MUST have non-volatile storage in which channel ID of the last upstream on which the CMsuccessfully completed registration is stored. If multiple upstreams are available, the CM MUST attempt to usethe one that matches this stored channel ID. If none of the available upstreams match that stored ID, or if the CMis unable to successfully complete initial ranging on the matching channel, then the CM MUST preferentiallyselect upstream channels in the following order. Type 3 channels are first, followed by type 2 channels, and type1 channels are last. The CM MUST NOT begin initial ranging on a type 1 or type 2 upstream until it has allowedsufficient time, at least the UCD Interval (refer to Annex B), to determine if a type 3 upstream is available. Ifinitial ranging fails on a type 3 upstream, the CM MUST ensure that it has allowed sufficient time to detect anyother type 3 upstreams that are available before moving on to a type 2 or type 1 upstream. Of course, once theCM has waited enough time to ensure that it knows about any available type 3 upstreams, it will also know aboutany available type 2 upstreams and it MUST try them in preference to any type 1 upstreams.

If the channel is suitable, the CM MUST extract the parameters for this upstream from the UCD. It then MUSTwait for the next SYNC message and extract the upstream mini-slot timestamp from this message.1 The CM thenMUST wait for a bandwidth allocation map for the selected channel. It may begin transmitting upstream inaccordance with the MAC operation and the bandwidth allocation mechanism.

The CM MUST perform initial ranging at least once, in accordance with Figure 11-6. If initial ranging is notsuccessful, the next channel ID is selected, and the procedure restarted from UCD extraction. When there are nomore channel IDs to try, the CM MUST continue scanning to find another downstream channel.

1. Alternatively, since the SYNC message applies to all upstream channels, the CM may have already acquired atime reference from previous SYNC messages. If so, it need not wait for a new SYNC.

236


Figure 11-3 Obtaining Upstream Parameters

Extract upstreamminislot timing

Good upstreamdescriptor

Wait for SYNC

SYNC

Wait for mapfor this channel

Map for selectedchannel

InitialRanging

InitialRanging

Successful?

StationMaintenance

TimeoutT1

Scanning

Collect UCDMessages

Wait for usableUCD

Build channel list

Select firstchannel

End ofchannel

list?

Select nextchannel

Yes

No

Yes

PeriodicRanging

237


11.2.3 Message Flows During Scanning and Upstream Parameter Acquisition

The CMTS MUST generate SYNC and UCD messages on the downstream at periodic intervals within the rangesdefined in Annex B. These messages are addressed to all CMs. Refer to Figure 11-4.

Figure 11-4 Message Flows During Scanning and Upstream Parameter Acquisition

CMTS CM

clock time to send SYNC ----------------SYNC--------------------> |

clock time to send UCD ----------------UCD----------------------> |

|


| Example of a UCD cycle

| prior to CM power-on

|


|

|

|


|

|

clock time to send SYNC ----------------SYNC-------------------->

clock time to send UCD ----------------UCD---------------------->


power on sequence complete


establish PHY synchronization

& wait for UCD



clock time to send UCD ----------------UCD---------------------->

obtain parameters for this upstreamchannel to use for initialization


extract slot info for upstream & wait fortransmit opportunity to perform ranging


clock time to send MAP ----------------MAP---------------------->

start ranging process

238


11.2.4 Ranging and Automatic Adjustments

The ranging and adjustment process is fully defined in Section 8 and in the following sections. The messagesequence chart and the finite state machines on the following pages define the ranging and adjustment processwhich MUST be followed by compliant CMs and CMTSes. Refer to Figure 11-5 through Figure 11-8.

Note: MAPs are transmitted as described in Section 8.

Figure 11-5 Ranging and Automatic Adjustments Procedure

Note: The CMTS MUST allow the CM sufficient time to have processed the previous RNG-RSP (i.e., to modify the transmitterparameters) before sending the CM a specific ranging opportunity. This is defined as CM Ranging Response Time in Annex B.

CMTS CM

[time to send the Initial Maintenanceopportunity]

send map containing InitialMaintenance information elementwith a broadcast/multicast Service ID

-----------MAP------------>

<---------RNG-REQ or INIT-RNG-REQ-------

transmit ranging packet in contention mode

with Service ID parameter = 0

[receive recognizable ranging packet]

allocate temporary Service ID

send ranging response ----------RNG-RSP------->

add temporary Service ID to poll list store temporary Service ID & adjust otherparameters

[time to send the next map]

send map with Station Maintenanceinformation element or Unicast InitialMaintenance element to modemusing temporary SID

-----------MAP------------> recognize own temporary Service ID in map

<---------RNG-REQ------- reply to Station Maintenance opportunity pollor Unicast Initial Maintenance opportunity poll

send ranging response ----------RNG-RSP------->

adjust local parameters

[time to send an Initial Maintenanceopportunity] send map containingInitial Maintenance informationelement with a broadcast/multicastService ID

send periodic transmit opportunity tobroadcast address

------------MAP----------->

239


Figure 11-6 Initial Ranging - CM1

1. Revised Figure 11-6 per ECN RFI2-N-02215, chg # 3, by GO, on 12/02/02.

Wait for broadcastmaintenanceopportunity

Backoffcompleted?

Adjust local power

Wait forbroadcast ranging

opportunity

Send RNG-REQ

Time out T2Map with

maintenanceopportunity

ErrorRe-initialize MAC

Wait forbroadcast ranging

opportunity

Wait for RNG-REQ

Time out T3 RNG-RSP

Retriesexhausted?

ErrorRe-initialize MAC

Wait forunicast maintenance

opportunity

Adjust localparameters per

RNG-RSP

Note: Timeout T3 may occur because the RNG-REQs from multiple modems collided.To avoid these modems repeating the loop in lockstep, a ramdom backoff is required.This is a backoff over the ranging window specified in the MAP. T3 timeouts can alsooccur during multi-channel operation. On a system with multiple upstream channels, theCM MUST attempt initial ranging on every suitable upstream channel, before moving tothe next available downstream channel.

No

No

Yes

240


1. Ranging Request is within the tolerance of the CMTS.

Figure 11-7 Unicast Initial Ranging - CM

SendRNG-REQ

RNG-RSP

Wait for unicastMaintenanceOpportunity

Error:Re-initialize MAC

Abort rangingfrom CMTS?

Timeout T3

RNG-REQretries exceeded?

No

Map withMaintenanceopportunity

Wait forRNG-RSP

Yes

Adjust transmitpower

Adjustparameters

perRNG-RSP

RangingSuccess(Note 1)

No

No

Yes

Enable datatransfer

Establish IPlayer

Timeout T4

241


Figure 11-8 Initial Ranging - CMTS1

1. Means ranging is within the tolerable limits of the CMTS.

2. RNG-REQ pending-till-complete was nonzero, the CMTS SHOULD hold off the station maintenance opportunityaccordingly unless needed, for example, to adjust the CM’s power level. If opportunities are offered prior to the pending-till-complete expiry, the “good-enough” test which follows receipt of a RNG-RSP MUST NOT judge the CM’s transmitequalization until pending-till-complete expires.

1. Added diagram block “Start T9” to Figure 11-8, per ECN RFI2-N-02210, by GO, on 11/21/02.

Yes

No

Wait forrecognizable

INIT-RNG-REQor RNG-REQ

RNG-REQ

Assign temporarySID

Add CM to polllist for future

maps

Send RNG-RSP(continue)

Reset retry countin poll list for this

CM

No

Wait for polledRNG-REQ

RNG-REQ

Good Enough?(Note 1)

No

RNG-REQ not

received

SendRNG-RSP(success)

Yes

No

Remove CM frompoll list

Done

SendRNG-RSP(continue)

SendRNG-RSP

(abort)

Yes



Wait forrecognizableRNG-REQ

Yes

Retries Exhausted?

Retries Exhausted?

SID assigned tothis CM already?

Map will be sent per allocationalgorithm and pending tillcomplete. (Note 2)

Start T9

242


11.2.4.1 Ranging Parameter Adjustment

Adjustment of local parameters (e.g., transmit power) in a CM as a result of the receipt (or non-receipt) of anRNG-RSP is considered to be implementation-dependent with the following restrictions (refer to Section 8.3.6):

• All parameters MUST be within the approved range at all times

• Power adjustment MUST start from the minimum value unless a valid power is available from non-volatilestorage, in which case this MUST be used as a starting point.

• Power adjustment MUST be capable of being reduced or increased by the specified amount in response toRNG-RSP messages.

• If, during initialization, power is increased to the maximum value (without a response from the CMTS) itMUST wrap back to the minimum.

• For multi-channel support, the CM MUST attempt initial ranging on every suitable upstream channel beforemoving to the next available downstream channel.

• For multi-channel support, the CM MUST use the upstream channel ID of the range response as specified inSection 8.3.6 and in Appendix III.

11.2.5 Device Class Identification

After Ranging is complete and before establishing IP connectivity, the CM MAY identify itself to the CMTS foruse in provisioning. Refer to Figure 11-9.

Figure 11-9 Device Class Identification

If implemented, the CM MUST use an adaptive timeout for device class identification based on binaryexponential backoff, similar to that used for TFTP. Refer to Section 11.2.8, “Transfer Operational Parameters,”on page 245 for details.

11.2.6 Establish IP Connectivity

At this point, the CM MUST invoke DHCP mechanisms [RFC-2131] in order to obtain an IP address and anyother parameters needed to establish IP connectivity (refer to Annex D). The DHCP response MUST contain thename of a file which contains further configuration parameters. Refer to Figure 11-10.

CM CMTS

Send identificationrequest to CMTS

DCI-REQ

Process request

DCI-RSP

Continue to establishing IPconnectivity

243


Figure 11-10 Establishing IP Connectivity

11.2.7 Establish Time of Day

The CM and CMTS need to have the current date and time. This is required for time-stamping logged eventswhich can be retrieved by the management system. This need not be authenticated and need only be accurate tothe nearest second.

The protocol by which the time of day MUST be retrieved is defined in [RFC-868]. Refer to Figure 11-11. Therequest and response MUST be transferred using UDP. The time retrieved from the server (UTC) MUST becombined with the time offset received from the DHCP response to create the current local time.

Figure 11-11 Establishing Time of Day

The DHCP server may offer a CM multiple Time of Day server IP addresses to attempt. The CM MUST attemptall Time of Day servers included in the DHCP offer until local time is established.

Successfully acquiring the Time of Day is not mandatory for a successful registration, but it is necessary forongoing operation. If a CM is unable to establish time of day before registration it MUST log the failure,generate an alert to management facilities, then proceed to an operational state and retry periodically.

The specific timeout for Time of Day Requests is implementation dependent. However, for each server definedthe CM MUST NOT exceed more than 3 Time of Day requests in any 5 minute period. At minimum, the CMMUST issue at least 1 Time of Day request per 5 minute period for each server specified until local time isestablished.

CM DHCP

send DHCP request tobroadcast address

----------------DHCP discover------------>

check CM MAC address & respond

<--------------DHCP offer -----------------

choose server

----------------DHCP request-------------->

process request

<--------------DHCP response--------------

set up IP parameters fromDHCP response

CM Time Server

send request to timeserver

----------------time of day request------------>

process request

<--------------time of day response--------------

set up / correct time ofday from response

244


11.2.8 Transfer Operational Parameters

After DHCP is successful, the modem MUST download the parameter file using TFTP, as shown in Figure 11-12. The TFTP configuration parameter server is specified by the “siaddr” field of the DHCP response. The CMMUST use an adaptive timeout for TFTP based on binary exponential backoff. Refer to [RFC-1123] and [RFC-2349].

The parameter fields required in the DHCP response and the format and content of the configuration file MUSTbe as defined in Annex D. Note that these fields are the minimum required for interoperability.

If a modem downloads a configuration file containing an upstream channel and/or downstream frequencydifferent from what the modem is currently using, the modem MUST NOT send a Registration Request messageto the CMTS. The modem MUST redo initial ranging using the configured upstream channel and/or downstreamfrequency per Section 8.3.6.3. The modem MAY reject a configuration file in the case of size limit errors (referto Section D.2.1).

If a modem downloads a configuration file containing the Enable 2.0 Mode TLV set to Disable (see sectionSection C.1.1.19), then it MUST NOT operate in 2.0 Mode until it registers again and downloads a configurationfile which does not have this TLV set to Disable. This is true no matter what type of upstream the CM is using atthe time it is attempting registration. If it is using a Type 3 channel (as described in Section 11.2.2), it MUSTNOT send a Registration Request message to the CMTS. The modem MUST redo initial ranging using a Type 1or Type 2 channel. If no such upstream channel is available (or if the modem is unable to range successfully onone) the modem MUST scan for a new downstream, at which point 2.0 mode is no longer disabled. If the modemdownloads a configuration file that does not disable 2.0 Mode, then, regardless of what kind of upstream it isusing at the time of registration it will continue to operate with 2.0 mode enabled until it is no longer registered.This means that if a modem registers on type 1 channel with a configuration file that enables 2.0 mode operation,and then ends up on a type 2 or type 3 upstream without going through re-registration, the CM wouldimmediately start operating in 2.0 mode.

11.2.9 Registration

A CM MUST be authorized to forward traffic into the network once it is initialized and configured. The CM isauthorized to forward traffic into the network via registration. To register with a CMTS, the CM MUST forwardits configured class of service and any other operational parameters in the configuration file (refer to Section8.3.7) to the CMTS as part of a Registration Request. The CM MUST perform the following operations beforeregistration (refer to Figure 11-12):

• Check configuration file mandatory items (refer to Section D.2.2). The CM MUST reject a configuration fileif it lacks any mandatory items.

• Calculate a MIC per Section D.2.3.1 and compare it to the CM MIC included in the configuration file. If theMIC is invalid, the CM MUST reject the configuration file.

• If the configuration file contains TLV-11 encoding, the CM MUST follow the configuration process definedin Section 3.4 of [DOCSIS5]. The CM MUST reject a configuration file in the case of TLV-11 processingfailure.

Figure 11-12 shows the procedure that MUST be followed by the CM.

The configuration parameters downloaded to the CM MUST include a network access control object (seeSection C.1.1.3). If this is set to “no forwarding,” the CM MUST NOT forward data from attached CPE to thenetwork, yet the CM MUST respond to network management requests. This allows the CM to be configured in amode in which it is manageable but will not forward data.

245


Figure 11-12 Registration — CM

Once the CM has sent a Registration Request to the CMTS it MUST wait for a Registration Response toauthorize it to forward traffic to the network. Figure 11-13 shows the waiting procedure that MUST be followedby the CM.

Time of DayResponse

Config FileReceived

TimeoutTime of Day Retries areasynchronous with registration

RequestConfig File

Time of DayRequest

Retriesexceeded?

Wait for Time ofDay Response

Wait forSuccessful TFTP

Scan forDowstream

ChannelYes

TimeoutIncrement

Retry Counter

Mandatoryitems present?

CM MIC valid?

No

Yes

No

No

AcquireOperationalParameters

Yes

Send Reg-Req

Wait for Reg-Rsp

TLV type 11errors?

No

Yes

246


Figure 11-13 Wait for Registration Response — CM1

Retriesexhausted?

Wait for Reg Rsp

Response =ok?

CM supportsall parametersin Reg-Rsp?

DOCSIS 2.0enabled AND

Type 2channel?

DOCSIS 2.0enabled AND

Type 2channel?

Reg-RspTimeout T6

SendReg-Req

Wait for Reg Rsp

No

Error: Re-initializeMAC

Yes Yes

ImplementationDependent

No

Send Reg-Ackwith error sets

No

OperationalReg-Rsp

SendReg-Ack

Switch to DOCSIS1.1 mode

Setup ServiceFlows & Activate

OperationalParameters

Switch to DOCSIS2.0 mode

No

NoYes

Yes

Yes

247


Note to Figure 11-12 and Figure 11-13: A type 2 upstream supports both DOCSIS 1.1 and DOCSIS 2.0 TDMAbursts (see Section 11.2.2). On such an upstream, it is necessary that the CMTS know whether the CM hascalculated a request to transmit data based on the DOCSIS 2.0 TDMA data IUCs (9, 10) or on the DOCSIS 1.xIUCs (5, 6). On these upstreams, the CM calculates all requests up to and including the request to transmit theREG-ACK based on the DOCSIS 1.x IUCs. If the CM is enabled to operate in 2.0 mode (see Section C.1.1.19),all requests to transmit data on such an upstream, subsequent to the transmission of the REG-ACK, arecalculated based on the DOCSIS 2.0 TDMA data IUCs. If the CMTS indicates that it did not receive the REG-ACK by retransmitting the REG-RSP, a CM using such an upstream MUST revert to the DOCSIS 1.x data IUCsto request bandwidth for retransmitting the REG-ACK.

The CMTS MUST perform the following operations to confirm the CM authorization (refer to Figure 11-14 andFigure 11-15):

• Calculate a MIC per Section D.3.1 and compare it to the CMTS MIC included in the Registration Request. Ifthe MIC is invalid, the CMTS MUST respond with an Authentication Failure.

• If present, check the TFTP Server Timestamp field. If the CMTS detects that the time is different from itslocal time by more than CM Configuration Processing Time (refer to Annex B), the CMTS MUST indicateauthentication failure in the REG-RSP. The CMTS SHOULD also make a log entry stating the CM MACaddress from the message.

• If present, check the TFTP Server Provisioned Modem Address field. If the Provisioned Modem Addressdoes not match the requesting modem’s actual address, the CMTS MUST indicate authentication failure inthe REG-RSP. The CMTS SHOULD also make a log entry stating the CM MAC address from the message.

• If the Registration Request contains DOCSIS 1.0 Class of Service encodings, verify the availability of theclass(es) of service requested. If unable to provide the class(es) of service, the CMTS MUST respond with aClass of Service Failure and the appropriate Service Not Available response code(s). (refer to SectionC.1.3.4)

• If the Registration Request contains Service Flow encodings, verify the availability of the Quality of Servicerequested in the provisioned Service Flow(s). If unable to provide the Service Flow(s), the CMTS MUSTrespond with either a reject-temporary or a reject-permanent (see App. C.4) and the appropriate Service FlowResponse(s).

• If the Registration Request contains DOCSIS 1.0 Class of Service encodings and Service Flow encodings, theCMTS MUST respond with a Class of Service Failure and a Service Not Available response code set to‘reject-permanent’ for all DOCSIS 1.0 Classes and Service Flows requested.

• Verify the availability of any Modem Capabilities requested. If unable or unwilling to provide the ModemCapability requested, the CMTS MUST turn that Modem Capability ‘off’ (refer to Section 8.3.8.1.1).

• Assign a Service Flow ID for each class of service supported.

• Reply to the modem in a Registration Response.

• If the Registration Request contains Service Flow encoding and the REG-RESP sent with a confirmationcode of ok (0), the CMTS MUST wait for a Registration Acknowledgment as shown in Figure 11-14. If theRegistration Request contains DOCSIS 1.0 Class of Service encodings, the CMTS MUST NOT wait for aRegistration Acknowledgment.

• In a channel that supports both DOCSIS 1.x and DOCSIS 2.0 TDMA burst types (see Section 11.2), theCMTS MUST change the operational state of the DOCSIS 2.0 enabled CM (see Section C.1.1.19) to DOC-SIS 2.0 TDMA after the Registration Acknowledgement message is received from the CM.

• If timer T9 expires, the CMTS MUST both de-assign the temporary SID from that CM and make some provi-sion for aging out that SID.

1. Refer to Section 11.2.2 for channel type definitions.

248


Figure 11-14 Registration — CMTS

Waiting for Reg-Req

Reg-Req

CMTS MICValid?

Calculate MICover Reg-Req

Wait for Reg-Req

Send Reg-Rsp withResponse =

Authentication Failure

TFTP Server IP and/or Timestamp Valid?

Yes

No

Send Reg-Rsp withResponse =

Authentication Failure &Should Log Failure

No

Can the requestedservice(s) ever be

supported?

Send Reg-Rsp withResponse = Class of

Service Failure & ServiceNot Available=Reason

Permanent

No

Can the requestedservice(s) currently

be supported?

Yes

Send Reg-Rsp withResponse = Class of

Service Failure & ServiceNot Available=Reason

Temporary

No

Send Reg-Rsp withResponse = ok

Waiting for Reg-Ack

Set modemcapabilities

supported inRegRsp

Yes

CreateRequested

Services

Stop T9

249


Figure 11-15 Registration Acknowledgment— CMTS

11.2.10 Baseline Privacy Initialization

Following registration, if the CM is provisioned to run Baseline Privacy, the CM MUST initialize BaselinePrivacy operations, as described in [DOCSIS8]. A CM is provisioned to run Baseline Privacy if the PrivacyEnable TLV (Section C.1.1.16) in the DOCSIS 1.1 style configuration file is explicitly/implicitly set to enable orthe Baseline Privacy Configuration Setting (Section C.3.2) is contained in the DOCSIS 1.0 style configurationfile as specified in Sections A.1.1 and C.2 of the BPI+ specification [DOCSIS8]. Note that the Secure SoftwareDownload is required regardless of whether the CM is provisioned to run Baseline Privacy or not as specified inappendix D of the BPI+ specification [DOCSIS8].

11.2.11 Service IDs During CM Initialization

After completion of the Registration process (Section 11.2.9), the CM will have been assigned Service Flow IDs(SFIDs) to match its provisioning. However, the CM must complete a number of protocol transactions prior tothat time (e.g., Ranging, DHCP, etc.), and requires a temporary Service ID in order to complete those steps.

On reception of an Initial Ranging Request, the CMTS MUST allocate a temporary SID and assign it to the CMfor initialization use. The CMTS MAY monitor use of this SID and restrict traffic to that needed for initialization.It MUST inform the CM of this assignment in the Ranging Response.

Send Reg-Rspwith Response =

OK

NoReg-Ackcontains

Error Sets?Retries

Exhausted?

Reg-Ack

No

Waiting for Reg-Ack

Adv. PHYactivatedAND

Type 2channel?

DestroyServices

Yes

Waiting for Reg-Ack

Waiting for Reg-Req

Operational

Switch CMoperational state

to Adv PHYNo

Yes

Timeout T6

250


On receiving a Ranging Response addressed to it, the CM MUST use the assigned temporary SID for furtherinitialization transmission requests until the Registration Response is received.

On receiving a Ranging Response instruction to move to a new downstream frequency and/or upstream channelID, the CM MUST consider any previously assigned temporary SID to be deassigned, and must obtain a newtemporary SID via initial ranging.

It is possible that the Ranging Response may be lost after transmission by the CMTS. The CM MUST recover bytiming out and re-issuing its Initial Ranging Request. Since the CM is uniquely identified by the source MACaddress in the Ranging Request, the CMTS MAY immediately re-use the temporary SID previously assigned. Ifthe CMTS assigns a new temporary SID, it MUST make some provision for aging out the old SID that wentunused (see Section 8.3.8).

When assigning provisioned SFIDs on receiving a Registration Request, the CMTS may re-use the temporarySID, assigning it to one of the Service Flows requested. If so, it MUST continue to allow initialization messageson that SID, since the Registration Response could be lost in transit. If the CMTS assigns all-new SIDs for class-of-service provisioning, it MUST age out the temporary SID. The aging-out MUST allow sufficient time tocomplete the registration process in case the Registration Response is lost in transit.

11.2.12 Multiple-Channel Support

In the event that more than one downstream signal is present in the system, the CM MUST operate using the firstvalid downstream signal that it encounters when scanning. It will be instructed via the parameters in theconfiguration file (see Annex C) to shift operation to different downstream and/or upstream frequencies ifnecessary.

Both upstream and downstream channels MUST be identified where required in MAC management messagesusing channel identifiers.

11.3 Standard Operation

11.3.1 Periodic Signal Level Adjustment

The CMTS MUST provide each CM a Periodic Ranging opportunity at least once every T4 seconds. The CMTSMUST send out Periodic Ranging opportunities at an interval sufficiently shorter than T4 that a MAP could bemissed without the CM timing out. The size of this “subinterval” is CMTS dependent.

The CM MUST reinitialize its MAC after T4 seconds have elapsed without receiving a Periodic Rangingopportunity.

Remote RF signal level adjustment at the CM is performed through a periodic ranging function using the RNG-REQ and RNG-RSP MAC messages. This is similar to initial ranging and is shown in Figure 11-16 and Figure11-17. On receiving a RNG-RSP, the CM MUST NOT transmit until the RF signal has been adjusted inaccordance with the RNG-RSP and has stabilized (refer to Section 6). The CM MUST NOT transmit anythingother than RNG-REQs, if it has been suspended by receiving a RNG-RESP with a ranging state of CONTINUE,until such time as it receives a RNG-RSP with a ranging state of SUCCESS.

251


Figure 11-16 Periodic Ranging - CMTS

Map will be sent per allocationalgorithm and pending till

complete (Note 2)

Yes

On periodic timeradd CM to poll list

for future maps

No


RNG-REQ

No

RNG-REQ notreceived

SendRNG-RSP(success)

Yes


Done

SendRNG-RSP(continue)

SendRNG-RSP

(abort)

Yes



Destroy SIDsassociated with

this CM

Done

No

Retries Exhausted?

Retries Exhausted? Good Enough?(Note 1)

Note 1: Means Ranging Request is within the tolerance limits of the CMTS for power and transmitequalization (if supported)Note 2: RNG-REQ pending-till-complete was nonzero, the CMTS SHOULD hold off the stationmaintenance opportunity accordingly unless needed, for example, to adjust the CM's power level. Ifopportunities are offered prior to the pending-till-complete expiry, the "good-enough" test which followsreceipt of a RNG-RSP MUST NOT judge the CM's transmit equalization until pending-till-complete expires.

252


Figure 11-17 Periodic Ranging - CM View

11.3.2 Changing Upstream Channel Descriptor Message Parameters

Whenever the CMTS is to change any of the upstream burst characteristics specified in the Upstream ChannelDescriptor (UCD) message (see Section 8.3.3), it must provide for an orderly transition from the old values to thenew values by all CMs. Whenever the CMTS is to change any of the upstream characteristics, it MUSTannounce the new values in an UCD message, and the Configuration Change Count field in that UCD messageMUST be incremented to indicate that a value has changed.

After transmitting one or more UCD messages with the new value, the CMTS transmits a MAP message with aUCD Change Count matching the new Configuration Change Count. The first interval in the MAP MUST be adata grant of at least 1 millisecond to the null Service ID (zero). In the case of S-CDMA channels, that grant tothe null Service ID MUST be at least the longer of 1ms or the duration of 2 S-CDMA frames to allow for thelatency of the S-CDMA framing, and the Start Time of the MAP with the new UCD Change Count MUSTcorrespond to the beginning of an S-CDMA frame. The CMTS MUST allow this time for cable modems to

SendRNG-REQ

Unicastmaintenanceopportunity

RNG-RSP

Operational

Error:Re-initialize MAC

Abort rangingfrom CMTS?

Timeout T4

IncrementRNG-REQ

Retry Counter

Timeout T3

RNG-REQretries exceeded?

Yes

Yes

Adjust localparameters per

RNG-RSP

Reset RNG-REQRetry Counter;Clear T3 Timer

StartT3 Timer

StartT4 Timer

No

T3 Timerstarted?

No

Yes

Success rangingfrom CMTS?

No

Suspendtransmission of

everything exceptRNG-REQs

Cleartransmission

suspend

253


change their PMD sublayer parameters to match the new set. This time is independent of the lead time the CMTSneeded to allow for in transmitting the MAP (see Section 9.1.5). The CMTS MUST transmit the new UCDmessage early enough that the CM receives the UCD message at least the UCD Processing Time (see Annex B)prior to the time the first MAP using the new UCD parameters arrives at the CM.

With the following exceptions the CM MUST be able to transmit normally on the first grant following the grantto the NULL SID. The exceptions are the case where the new UCD message has changed the S-CDMA Enableparameter, or the S-CDMA US Ratio Numerator or Denominator. In these cases the CM MAY redo initialranging to establish timing synchronization for the new mode of operation before it resumes normaltransmissions. If the CM was already registered with the CMTS, and it redoes initial ranging for this reason itMUST use its Primary SID instead of the initialization SID for the initial ranging process and it MUST NOT re-register. Using the Ranging Required parameter in the new UCD message, the CMTS can force the CM toperform ranging prior to making any other transmissions using the parameters in the new UCD message. Incertain cases, channel wide parameter changes (in particular, Modulation Rate or Center Frequency) mayinvalidate pre-equalization and synchronization parameters and normal operation may not be possible withoutre-ranging. If the CMTS changes the Modulation Rate or Center Frequency on an S-CDMA channel, it MUSTforce re-ranging using the Ranging Required parameter.

In the case of an S-CDMA channel, the first UCD message with a new Configuration Count and any subsequentUCD messages that may be sent prior to the first MAP with the new UCD Change Count MUST have an updatedtimestamp snapshot corresponding to the start time of that first MAP with the new UCD Change Count. Also onan S-CDMA channel the CMTS MUST maintain the continuity of the mini-slot and S-CDMA frame countersduring the change in UCD parameters even if the size of a mini-slot is changed.

The CMTS MUST NOT transmit MAPs with the old UCD Change Count after transmitting the new UCDmessage.

The CM MUST use the parameters from the UCD message corresponding to the MAP’s UCD Change Count forany transmissions it makes in response to that MAP. If the CM has, for any reason, not received thecorresponding UCD message, it cannot transmit during the interval described by that MAP.

It is possible for the change in upstream parameters to cause the upstream to change from a Type 1 upstream (seeSection 11.2.2) to a Type 2 upstream or a Type 3 upstream. If this happens, and the CM registered with aconfiguration file that enables 2.0 Mode (see Section 11.2.8), then the CM MUST operate in 2.0 Mode. If theupstream has changed to a Type 2 upstream this means that any request the CM transmits in an opportunity in theMAP with the new Configuration Change Count or any subsequent MAP MUST be calculated in terms of IUCs9 and 10, rather than IUCs 5 and 6, and the CMTS MUST issue grants using IUCs 9 and 10. However, if the CMregistered with a configuration file that disabled 2.0 Mode, then the CM MUST continue to calculate requests interms of IUCs 5 and 6, and the CMTS MUST issue grants using IUCs 5 and 6. If the CM registered with aconfiguration file that disables 2.0 Mode, and the new parameters have changed the upstream to a Type 3upstream, then the CM MUST immediately reinitialize the MAC layer and attempt registration. It should beunderstood by the network operator that changing a Type 1 upstream to a Type 3 upstream will cause asignificant disruption of service for any CMs with 2.0 Mode disabled as well as any DOCSIS 1.x CMs that areusing the channel. Also such CMs will only be able to resume operation if there is a Type 1 or Type 2 upstreamavailable to them.

11.3.3 Changing Upstream Channels

At any time after registration, the CMTS may direct the CM to change its upstream channel. This may be donefor traffic balancing, noise avoidance, or any of a number of other reasons which are beyond the scope of thisspecification. Figure 11-18 shows the procedure that MUST be followed by the CMTS. Figures 11-19 and 11-20show the corresponding procedure at the CM.

254


Figure 11-18 Changing Upstream Channels: CMTS View

Note that if the CMTS retries the UCC-REQ, the CM may have already changed channels (if the UCC-RSP waslost in transit). Consequently, the CMTS MUST listen for the UCC-RSP on both the old and the new channels.

Decide to switchCM to new

upstream channel

Wait for UCC-RSP

Done

CM isunreachable

No

Yes

Timeout T5 UCC-RSP

UCC-REQ

Retries Exhausted?

255


Figure 11-19 Changing Upstream Channels: CM View Part 1

CM Operational

UCC-REQ

UCC-RSP

Already using thischannel?

UCC-RSP(reject-

already-there)

Valid UCD fortarget upstream

stored?

No

Wait for valid UCDfor target

upstream channel(or expiry of T1)

Valid UCDacquired?

No

CM UCC FailedYes

Switch to newchannel

Perform broadcastinitial ranging

RangingSuccess?

No

CM UCC FailedYes

Yes No

CM Operational

1

Yes

22 The operational CM MUST base its

requests on IUCs 9 and 10 if available andif DOCSIS 2.0 is enabled.

11. If DOCSIS 2.0 is enabled, a valid UCD

describes either a type 1, 2, or 3channel.

2. If DOCSIS 2.0 is NOT enabled, a validUCD describes a type 1 or type 2channel.

256


Figure 11-20 Changing Upstream Channels: CM View Part 2

Upon synchronizing with the new upstream channel, the CM MUST perform broadcast initial ranging on thenew upstream channel.

If the CM has previously established ranging on the new channel, and if that ranging on that channel is stillcurrent (T4 has not elapsed since the last successful ranging), then the CM MAY use cached ranging informationand omit ranging.

The CM SHOULD cache UCD information from multiple upstream channels to eliminate waiting for a UCDcorresponding to the new upstream channel.

The CM MUST NOT perform re-registration, since its provisioning and MAC domain remain valid on the newchannel.

If a DOCSIS 2.0-enabled CM is moved from a Type 1 channel to a Type 2 channel via a UCC, the CM MUSToperate in 2.0 mode on the destination channel, basing its requests on IUCs 9 and 10 instead of IUCs 5 and 6. Ifa CM in which DOCSIS 2.0 is disabled in registration is moved from a Type 1 channel to a Type 2 channel via aUCC, the CM MUST continue to base its requests on the destination channel on IUCs 5 and 6.

11.4 Dynamic Service

Service Flows may be created, changed or deleted. This is accomplished through a series of MAC managementmessages referred to as Dynamic Service Addition (DSA), Dynamic Service Change (DSC) and DynamicService Deletion (DSD). The DSA messages create a new Service Flow. The DSC messages change an existingService Flow. The DSD messages delete a single existing Upstream and/or a single existing Downstream Service

Re-initialize MAC

Return to oldupstream

Reset the MAC

Obtain UpstreamParameters

CM UCC Failed

ERROR:UCC failed<reason>

The state “ObtainUpstream Parameters”links to the statemachine in Figure 11-1.

257


Flow. This is illustrated in Figure 11-21.

Figure 11-21 Dynamic Service Flow Overview

The Null state implies that no Service Flow exists that matches the SFID and/or TransactionID in a message.Once the Service Flow exists, it is operational and has an assigned SFID. In steady state operation, a ServiceFlow resides in a Nominal state. When Dynamic Service messaging is occurring, the Service Flow maytransition through other states, but remains operational. Since multiple Service Flows may exist, there may bemultiple state machines active, one for every Service Flow. Dynamic Service messages only affect those statemachines that match the SFID and/or Transaction ID. If privacy is enabled, both the CM and CMTS MUSTverify the HMAC digest on all dynamic service messages before processing them, and discard any messages thatfail.

Service Flows created at registration time effectively enter the SF_operational state without a DSA transaction.

TransactionIDs are unique per transaction and are selected by the initiating device (CM or CMTS). To helpprevent ambiguity and provide simple checking, the TransactionID number space is split between the CM andCMTS. The CM MUST select its TransactionIDs from the first half of the number space (0x0000 to 0x7FFF).The CMTS MUST select its TransactionIDs from the second half of the number space (0x8000 to 0xFFFF).

Each dynamic service message sequence is a unique transaction with an associated unique transaction identifier.The DSA/DSC transactions consist of a request/response/acknowledge sequence. The DSD transactions consistof a request/response sequence. The response messages MUST contain a confirmation code of okay unless someexception condition was detected. The acknowledge messages MUST include the confirmation code in theresponse unless a new exception condition arises. A more detailed state diagram, including transition states, isshown below. The detailed actions for each transaction will be given in the following sections.

11.4.1 Dynamic Service Flow State Transitions

The Dynamic Service Flow State Transition Diagram is the top-level state diagram and controls the generalService Flow state. As needed, it creates transactions, each represented by a Transaction state transition diagram,to provide the DSA, DSC, and DSD signaling. Each Transaction state transition diagram only communicateswith the parent Dynamic Service Flow State Transition Diagram. The top-level state transition diagram filtersDynamic Service messages and passes them to the appropriate transaction based on Service Flow Identifier(SFID), Service Flow Reference number, and TransactionID.

If a single Dynamic Service message affects a pair of service flows, a single transaction is initiated whichcommunicates with both parent Dynamic Service Flow State Transition Diagrams. In this case, both serviceflows MUST remain locked in the same state until they receive the DSx Succeeded or DSx Failed input from theDSx Transaction State Transition Diagram. During that “lock interval”, if a message is received which refers toonly one of the two service flows, it MUST be treated as if it refers to both service flows, so that both serviceflows stay in the same state. If a DSD-REQ message is received during the lock interval which refers to only oneof the two service flows, the device MUST handle the event normally, by sending the SF Delete-Remote to theongoing DSx Transaction and by initiating a DSD-Remote transaction, and in addition, it MUST initiate a DSD-Local transaction to delete the second service flow of the locked pair.

Null Operational

DSC

DSA

DSD

258


If a message is received which refers to two service flows locked in different transactions, or they are in differentstates, the device MUST reject the request without affecting the ongoing transaction(s).1

There are six different types of transactions: locally initiated or remotely initiated for each of the DSA, DSC andDSD messages. Most transactions have three basic states: pending, holding and deleting. The pending state istypically entered after creation and is where the transaction is waiting for a reply. The holding state is typicallyentered once the reply is received. the purpose of this state is to allow for retransmissions in case of a lostmessage, even though the local entity has perceived that the transaction has completed. The deleting state is onlyentered if the Service Flow is being deleted while a transaction is being processed.

The flow diagrams provide a detailed representation of each of the states in the Transaction state transitiondiagrams. All valid transitions are shown. Any inputs not shown should be handled as a severe error condition.

With one exception, these state diagrams apply equally to the CMTS and CM. In the Dynamic Service FlowChanging-Local state, there is a subtle difference in the CM and CMTS behaviors. This is called out in the statetransition and detailed flow diagrams.

Note: The ‘Num Xacts’ variable in the Dynamic Service Flow State Transition Diagram is incremented every time the top-levelstate diagram creates a transaction and is decremented every time a transaction terminates. A Dynamic Service Flow MUSTNOT return to the Null state until it’s deleted and all transactions have terminated.

The inputs for the state diagrams are identified below.

Dynamic Service Flow State Transition Diagram inputs from unspecified local, higher-level entities:

• Add

• Change

• Delete

Dynamic Service Flow State Transition Diagram inputs from DSx Transaction State Transition diagrams:

• DSA Succeeded

• DSA Failed

• DSA ACK Lost

• DSA Erred

• DSA Ended

• DSC Succeeded

• DSC Failed

• DSC ACK Lost

• DSC Erred

• DSC Ended

• DSD Succeeded

• DSD Erred

• DSD Ended

DSx Transaction State Transition diagram inputs from the Dynamic Service Flow State Transition Diagram:

• SF Add

1. Added sentence per ECN RFI2-N-02187, by GO, on 12/16/02.

259


• SF Change

• SF Delete

• SF Abort Add

• SF Change-Remote

• SF Delete-Local

• SF Delete-Remote

• SF DSA-ACK Lost

• SF-DSC-REQ Lost

• SF-DSC-ACK Lost

• SF DSD-REQ Lost

• SF Changed

• SF Deleted

The creation of DSx Transactions by the Dynamic Service Flow State Transition Diagram is indicated by thenotation

DSx-[ Local | Remote ] ( initial_input )

where initial_input may be SF Add, DSA-REQ, SF Change, DSC-REQ, SF Delete, or DSD-REQ depending onthe transaction type and initiator.

260


Figure 11-22 Dynamic Service Flow State Transition Diagram

Null

AddingLocal

Add FailedAddingRemote

Nominal

ChangingLocal

ChangingRemote

Deleting

Deleted

DSA-REQ /DSA-Remote( DSA-REQ )

DSA Ended /Add / DSA-Local( SF Add )

DSA Succeeded /DSA Succeeded /

( DSA Failed / )( Delete / SF Abort Add )(DSA Erred/)

DSA Failed /

DSC-REQ / SF DSA-ACK Lost

New DSC-REQ /SF DSC-ACK Lost

( DSC-REQ / )( DSA ACK Lost /SF DSD-REQ Lost )

( DSC ACK Lost /SF DSD-REQ Lost )

( DSC-REQ / [ CMTS Only ] )( DSA ACK Lost /SF DSC-REQ Lost )

( DSC ACK Lost /SF DSC-REQ Lost )

( DSD Succeeded / SF Deleted )( DSD Erred / SF Deleted )

DSD-REQ / SF Delete-Remote, DSD-Remote( DSD-REQ )

( DSA Erred /DSD-Local( SF Delete ) )

( Delete / SF Delete-Local,DSD-Local( SF Delete ) )

Delete /SF Delete-Local,DSD-Local( SF Delete )

DSD Ended &&Num Xacts == 0 /

( DSC Erred / SF Delete-Local,DSD-Local( SF Delete ) )


( DSC Erred /DSD-Local( SF Delete ) )


Change /DSC-Local(

SF Change )

( DSC Succeeded /SF Changed )

( DSC Failed /SF Changed )

( DSC Succeeded /SF Changed )

( DSC Failed /SF Changed )

DSC-REQ /SF Change-Remote,DSC-Remote( DSC-REQ )

DSC-REQ / SF Change-Remote,DSC-Remote( DSC-REQ ) [ CM Only ]

DSD Succeeded / SF Deleted

261


Figure 11-23 DSA—Locally Initiated Transaction State Transition Diagram

Begin

End

DSA-RSPPending

( Timeout T10 / DSA Ended )( SF Changed / DSA Ended )( SF Change-Remote / DSA Ended )

Timeout T7 && Retries Exhausted /

SF Delete-Local /

( Timeout T10 / DSA Ended )( SF Deleted / DSA Ended )

DSA-RSP / DSA-ACK, DSA ACK Lost

DeletingService Flow

DSA-RSP /DSA ACK Lost

HoldingDown

SF Add / DSA-REQ

Timeout T7 && Retries Available / DSA-REQ

( DSA-RSP / DSA Succeeded, DSA-ACK )( DSA-RSP / DSA Failed, DSA-ACK )( SF Abort Add / )

RetriesExhausted ( DSA-RSP / DSA Succeeded, DSA-ACK )

( DSA-RSP / DSA Failed, DSA-ACK )( SF Abort Add / )

Timeout T10 /DSA Erred, DSA Ended

SF Delete-Remote / DSA Ended

262


Figure 11-24 DSA—Remotely Initiated Transaction State Transition Diagram

Begin

End

( DSA-REQ / DSA-RSP )( DSA-REQ / DSA Failed, DSA-RSP )

( DSA-ACK / DSA Succeeded )( DSA-ACK / DSA Failed )

( Timeout T8 / DSA Ended )( SF Changed / DSA Ended )( SF Deleted / DSA Ended )( SF Delete-Remote / DSA Ended )

( Timeout T8 && Retries Available / DSA-RSP )( DSA-REQ && Retries Available / DSA-RSP )( DSA-REQ && Retries Exhausted / )( SF DSA-ACK Lost && Retries Available / DSA-RSP )( SF DSA-ACK Lost && Retries Exhausted / )

DSA-ACKPending

HoldingDown

SF Delete-Local /

( Timeout T10 / DSA Ended )( SF Deleted / DSA Ended )( SF Delete-Remote / DSA Ended )

( DSA-ACK / )( SF Delete-Local / )( SF Change-Remote / )


( DSA-REQ / )( DSA-ACK / )

( Timeout T8 && Retries Exhausted / DSA Erred, DSA Ended )( SF Delete-Remote / DSA Ended )

263


Figure 11-25 DSC—Locally Initiated Transaction State Transition Diagram

RetriesExhausted

Begin

End

SF Change / DSC-REQ

( DSC-RSP / DSC Succeeded, DSC-ACK )( DSC-RSP / DSC Failed, DSC-ACK )

( Timeout T7 && Retries Available / DSC-REQ )( SF DSC-REQ Lost && Retries Available / DSC-REQ )( SF DSC-REQ Lost && Retries Exhausted / )

DSC-RSPPending

( Timeout T10 / DSC Ended )( SF Changed / DSC Ended )( SF Change-Remote / DSC Ended )

( Timeout T10 / DSC Ended )( SF Deleted / DSC Ended )


DSC-RSP /DSC ACK Lost

HoldingDown

SF Delete-Local /

DSC-RSP /DSC-ACK, DSC ACK Lost

SF Delete-Remote / DSC Ended

SF Change-Remote / DSC Ended [ CM Only ]

Timeout T7 && Retries Exhausted /

Timeout T10 /DSC Erred, DSC Ended

( DSC-RSP / DSC Succeeded, DSC-ACK )( DSC-RSP / DSC Failed, DSC-ACK )

264


Figure 11-26 DSC—Remotely Initiated Transaction State Transition Diagram

Begin

End

DSC-REQ / DSC-RSP

( DSC-ACK / DSC Succeeded )( DSC-ACK / DSC Failed )

( Timeout T8 / DSC Ended )( SF Changed / DSC Ended )( SF Deleted / DSC Ended )( SF Delete-Remote / DSC Ended )

( Timeout T8 && Retries Available / DSC-RSP )( DSC-REQ && Retries Available / DSC-RSP )( DSC-REQ && Retries Exhausted / )( SF DSC-ACK Lost && Retries Available / DSC-RSP )( SF DSC-ACK Lost && Retries Exhausted / )

DSC-ACKPending

HoldingDown

SF Delete-Local /

( Timeout T10 / DSC Ended )( SF Deleted / DSC Ended )( SF Delete-Remote / DSC Ended )

( DSC-ACK / )( SF Delete-Local / )( SF Change-Remote / )


( DSC-REQ / )( DSC-ACK / )

( Timeout T8 && Retries Exhausted / DSC Erred, DSC Ended )( SF Delete-Remote / DSC Ended )

265


Figure 11-27 DSD—Locally Initiated Transaction State Transition Diagram

Begin

End

DSD-RSPPending

SF Delete / DSD-REQ

( Timeout T7 && Retries Available / DSD-REQ )( SF DSD-REQ Lost && Retries Available / DSD-REQ )( SF DSD-REQ Lost && Retries Exhausted / )

( DSD-RSP / DSD Succeeded )( SF Delete-Remote / )

Timeout T7 / DSD Ended

Timeout T7 && Retries Exhausted / DSD Erred, DSD EndedHoldingDown

( DSD-RSP / DSD Succeeded )( SF Deleted / )

266


Figure 11-28 Dynamic Deletion (DSD) - Remotely Initiated Transaction State Transition Diagram

11.4.2 Dynamic Service Addition

11.4.2.1 CM Initiated Dynamic Service Addition

A CM wishing to create an upstream and/or a downstream Service Flow sends a request to the CMTS using adynamic service addition request message (DSA-REQ). The CMTS checks the CM’s authorization for therequested service(s) and whether the QoS requirements can be supported and generates an appropriate responseusing a dynamic service addition response message (DSA-RSP). The CM concludes the transaction with anacknowledgment message (DSA-ACK).

HoldingDown

Begin

End

DSD-REQ / DSD Succeeded, DSD-RSP

( Timeout T10 / DSD Ended )( SF Deleted / DSD Ended )

DSD-REQ / DSD-RSP

267


In order to facilitate a common admission response, an upstream and a downstream Service Flow can be includedin a single DSA-REQ. Both Service Flows are either accepted or rejected together.

Figure 11-29 Dynamic Service Addition Initiated from CM

11.4.2.2 CMTS Initiated Dynamic Service Addition

A CMTS wishing to establish an upstream and/or a downstream dynamic Service Flow(s) with a CM performsthe following operations. The CMTS checks the authorization of the destination CM for the requested class ofservice and whether the QoS requirements can be supported. If the service can be supported the CMTS generatesnew SFID(s) with the required class of service and informs the CM using a dynamic service addition requestmessage (DSA-REQ). If the CM checks that it can support the service and responds using a dynamic serviceaddition response message (DSA-RSP). The transaction completes with the CMTS sending the acknowledgemessage (DSA-ACK).

CM CMTS

New Service Flow(s) needed

Check if resources are available

Send DSA-REQ ---DSA-REQ--> Receive DSA-REQ

Check if CM authorized for Service(s)1

1. Note: authorization can happen prior to the DSA-REQ being received by the CMTS. The details of CMTSsignalling to anticipate a DSA-REQ are beyond the scope of this specification.

Check Service Flow(s) QoS can besupported

Create SFID(s)

If upstream AdmittedQoSParamSet isnon-null, Create SID

If upstream ActiveQoSParamSet isnon-null, Enable reception of data onnew upstream Service Flow

Receive DSA-RSP <--DSA-RSP--- Send DSA-RSP

If ActiveQoSParamSet is non-null,Enable transmission and/or receptionof data on new Service Flow(s)

Send DSA-ACK ---DSA-ACK--> Receive DSA-ACK

If downstream ActiveQoSParamSet isnon-null, Enable transmission of dataon new downstream Service Flow

268


Figure 11-30 Dynamic Service Addition Initiated from CMTS

CM CMTS

New Service Flow(s) required for CM

Check CM authorized for Service(s)

Check Service Flow(s) QoS can be supported

Create SFID(s)

If upstream AdmittedQoSParamSet is non-null, Create SID

If upstream ActiveQoSParamSet is non-null,Enable reception of data on new upstreamService Flow

Receive DSA-REQ <--DSA-REQ--- Send DSA-REQ

Confirm CM can support Service Flow(s)

Add Downstream SFID (if present)

Enable reception on any new downstreamService Flow

Send DSA-RSP ---DSA-RSP--> Receive DSA-RSP

Enable transmission & reception of data onnew Service Flow(s)

Receive DSA-ACK <--DSA-ACK--- Send DSA-ACK

Enable transmission on new upstreamService Flow

269


11.4.2.3 Dynamic Service Addition State Transition Diagrams

Figure 11-31 DSA—Locally Initiated Transaction Begin State Flow Diagram

SF Add

DSA-LocalBegin

Set DSA-REQRetries Availableto 'DSx Request

Retries'

DSA-REQ

Start T7 Timer

Save transmittedDSA-REQ

DSA-LocalDSA-RSPPending

270


Figure 11-32 DSA—Locally Initiated Transaction DSA-RSP Pending State Flow Diagram


DSA-RSPSF Abort Add

Stop T7 TimerStop T7 Timer

DSA Failed

Save DSA-ACKwith Condition

Code 'reject-add-aborted'

Set ConditionCode to 'reject-xxx'

Okay ?

Yes

Enableservice flow

DSASucceeded

Set ConditionCode to 'okay'

DSA-ACK

Save transmittedDSA-ACK

DSA-LocalHolding Down

Start T10 Timer

Timeout T7 SF Delete-Remote

Stop T7 Timer

DSA Ended

DSA-LocalEnd

RetriesAvailable

?

Yes

Start T10 Timer


DSA-LocalRetries Exhausted

DecrementDSA-REQ

Retries Available

SavedDSA-REQ

Start T7 Timer

No

No

271


Figure 11-33 DSA—Locally Initiated Transaction Holding State Flow Diagram


Timeout T10 DSA-RSP

SavedDSA-ACK

DSA ACKLost


SF Changed,SF Change-Remote,SF Delete-Remote

SF Delete-Local

DSA-LocalDeleting

Service FlowStop T10 Timer

DSA Ended

DSA-LocalEnd

272


Figure 11-34 DSA—Locally Initiated Transaction Retries Exhausted State Flow Diagram

DSA-LocalRetries Exhausted

Timeout T10 SF Delete-Remote DSA-RSPSF Abort Add

DSA Failed

Save DSA-ACKwith Condition

Code 'reject-add-aborted'

Stop T10 TimerDSA Erred

DSA Ended

DSA-LocalEnd

Okay ?

Yes



DSA-ACK

Save transmittedDSA-ACK


Enableservice flow

DSASucceeded

No

273


Figure 11-35 DSA—Locally Initiated Transaction Deleting Service Flow State Flow Diagram

DSA-LocalDeleting

Service Flow

Timeout T10SF Deleted,

SF Delete-Remote

Stop T10 Timer

DSA Ended

DSA-LocalEnd

DSA-RSP

DSA ACKLost

DSA-LocalDeleting

Service Flow

274


Figure 11-36 DSA—Remotely Initiated Transaction Begin State Flow Diagram

DSA-RemoteBegin

DSA-REQ

Okay ?

Yes

[ CMTS Only ]Enable

upstreamservice flow

[ CM Only ]Enable

downstreamservice flow

DSA Failed



DSA-RemoteDSA-ACKPending

Set DSA-RSPRetries Availableto 'DSx Response

Retries'

DSA-RSP

Start T8 Timer

Save transmittedDSA-RSP

No

275


Figure 11-37 DSA—Remotely Initiated Transaction DSA-ACK Pending State Flow Diagram


DSA-ACK

Stop T8 Timer

Okay ?

DSA Failed

Yes

[ CMTS Only ]Enable

downstreamservice flow

[ CM Only ]Enable

upstreamservice flow

DSASucceeded

Start T8 Timer

DSA-RemoteHolding Down

Disableservice flow

SF Delete-Local

Stop T8 Timer

Start T10 Timer

DSA-RemoteDeleting

Service Flow

DSA-REQSF DSA-ACK

LostSF Delete-

Remote

Stop T8 Timer

Timeout T8

RetriesAvailable

?

Yes


DSA Erred

DSA-RemoteEnd

DSA Ended

DecrementDSA-RSP

Retries Available

SavedDSA-RSP

Start T8 Timer

RetriesAvailable

?

Yes

SavedDSA-RSP

No

No

No

276


Figure 11-38 DSA—Remotely Initiated Transaction Holding Down State Flow Diagram

SF Changed,SF Deleted,

SF Delete-Remote


Timeout T8 DSA-ACK


SF Delete-Local,SF Change-Remote

Stop T8 Timer

DSA Ended

DSA-RemoteEnd

277


Figure 11-39 DSA—Remotely Initiated Transaction Deleting Service State Flow Diagram

11.4.3 Dynamic Service Change

The Dynamic Service Change (DSC) set of messages is used to modify the flow parameters associated with aService Flow. Specifically, DSC can:

• Modify the Service Flow Specification

• Add, Delete or Replace a Flow Classifier

• Add, Delete or Set PHS elements

A single DSC message exchange can modify the parameters of one downstream service flow and/or oneupstream service flow.

To prevent packet loss, any required bandwidth change must be sequenced between the application generatingthe data and the bandwidth parameters of the Service Flow carrying the data. Because MAC messages can belost, the timing of Service Flow parameter changes can vary, and it occurs at different times in the CM andCMTS. Applications should reduce their transmitted data bandwidth before initiating a DSC to reduce theService Flow bandwidth, and should not increase their transmitted data bandwidth until after the completion of aDSC increasing the Service Flow bandwidth.

The CMTS controls both upstream and downstream scheduling. Scheduling is based on data transmissionrequests and is subject to the limits contained in the current Service Flow parameters at the CMTS. The timing ofService Flow parameter changes, and any consequent scheduling changes, is independent of both direction and

DSA-RemoteDeleting

Service Flow


SF Delete-Remote

Stop T10 Timer

DSA Ended

DSA-RemoteEnd

DSA-REQ,DSA-ACK

DSA-RemoteDeleting

Service Flow

278


whether there is an increase or decrease in bandwidth. The CMTS always changes Service Flow parameters onreceipt of a DSC-REQ (CM-initiated transaction) or DSC-RSP (CMTS-initiated transaction).

The CMTS also controls the downstream transmit behavior. The change in downstream transmit behavior isalways coincident with the change in downstream scheduling (i.e., CMTS controls both and changes bothsimultaneously).

The CM controls the upstream transmit requests, subject to limits contained in the current Service Flowparameters at the CM. The timing of Service Flow parameter changes in the CM, and any consequent CMtransmit request behavior changes, is a function of which device initiated the transaction. For a CM-initiatedDSC-REQ, the Service Flow parameters are changed on receipt of the DSC-RSP from the CMTS. For a CMTS-initiated DSC-REQ, the Service Flow parameters are changed on receipt of the DSC-REQ from the CMTS.

Any service flow can be deactivated with a Dynamic Service Change command by sending a DSC-REQmessage, referencing the Service Flow Identifier, and including a null ActiveQoSParameterSet. However, if aPrimary Service Flow of a CM is deactivated that CM is de-registered and MUST re-register. Therefore, careshould be taken before deactivating such Service Flows. If a Service Flow that was provisioned duringregistration is deactivated, the provisioning information for that Service Flow MUST be maintained until theService Flow is reactivated.

A CM MUST have only one DSC transaction outstanding per Service Flow. If it detects a second transactioninitiated by the CMTS, the CM MUST abort the transaction it initiated and allow the CMTS initiated transactionto complete.

A CMTS MUST have only one DSC transaction outstanding per Service Flow. If it detects a second transactioninitiated by the CM, the CMTS MUST abort the transaction the CM initiated and allow the CMTS initiatedtransaction to complete.

Note: Currently anticipated applications would probably control a Service Flow through either the CM or CMTS, and not both.Therefore the case of a DSC being initiated simultaneously by the CM and CMTS is considered as an exception condition andtreated as one.

11.4.3.1 CM-Initiated Dynamic Service Change

A CM that needs to change a Service Flow definition performs the following operations.

The CM informs the CMTS using a Dynamic Service Change Request message (DSC-REQ). The CMTS MUSTdecide if the referenced Service Flow can support this modification. The CMTS MUST respond with a DynamicService Change Response (DSC-RSP) indicating acceptance or rejection. The CM reconfigures the Service Flowif appropriate, and then MUST respond with a Dynamic Service Change Acknowledge (DSC-ACK).

279


11.4.3.2 CMTS-Initiated Dynamic Service Change

A CMTS that needs to change a Service Flow definition performs the following operations.

The CMTS MUST decide if the referenced Service Flow can support this modification. If so, the CMTS informsthe CM using a Dynamic Service Change Request message (DSC-REQ). The CM checks that it can support theservice change, and MUST respond using a Dynamic Service Change Response (DSC-RSP) indicatingacceptance or rejection. The CMTS reconfigures the Service Flow if appropriate, and then MUST respond with aDynamic Service Change Acknowledgment (DSC-ACK.

CMTS CM

Service Flow Requires Modifying

Receive DSC-REQ <--------- DSC-REQ ---------- Send DSC-REQ

Validate Request

Modify Service Flow

Send DSC-RSP ---------- DSC-RSP ---------> Receive DSC-RSP

Modify Service Flow

Receive DSC-ACK <--------- DSC-ACK ---------- Send DSC-ACK

Figure 11-40 CM-Initiated DSC

CMTS CM

Service Flow Requires Modifying

Send DSC-REQ ---------- DSC-REQ ---------> Receive DSC-REQ

Modify Service Flow

Receive DSC-RSP <--------- DSC-RSP ---------- Send DSC-RSP

Modify Service Flow

Send DSC-ACK ---------- DSC-ACK ---------> Receive DSC-ACK

Figure 11-41 CMTS-Initiated DSC

280


11.4.3.3 Dynamic Service Change State Transition Diagrams

Figure 11-42 DSC—Locally Initiated Transaction Begin State Flow Diagram

Save service flowQoS state

DSC-LocalDSC-RSPPending

Set DSC-REQRetries Availableto 'DSx Request

Retries'

DSC-REQ

Start T7 Timer

Save transmittedDSC-REQ

[ CM Only ]If decrease upstream

bandwidth, modifytransmission

SF Change

DSC-LocalBegin

281


Figure 11-43 DSC—Locally Initiated Transaction DSC-RSP Pending State Flow Diagram

SF Delete-Local

DSC-RSP

Stop T7 Timer

Start T10 Timer

DSC-LocalDeleting

Service Flow

Stop T7 Timer

Restoreservice flowQoS State

DSC Failed



Okay ?No

Yes

DSCSucceeded


DSC-ACK

Save transmittedDSC-ACK

Start T10 Timer

DSC-LocalHolding Down

ModifyService FlowParameters

SF DSC-REQLost

SF Change-Remote

[ CM Only ]

SF Delete-Remote

DSC-LocalEnd

Stop T7 Timer

DSC Ended

Timeout T7

RetriesAvailable

?

Yes

No

Start T10 Timer

DSC-LocalRetries Exhausted


DecrementDSC-REQ

Retries Available

SavedDSC-REQ

Start T7 Timer

RetriesAvailable

?

No Yes

SavedDSC-REQ

282


Figure 11-44 DSC—Locally Initiated Transaction Holding Down State Flow Diagram


Timeout T10 DSC-RSP

SavedDSC-ACK

DSC ACKLost


SF Changed,SF Change-Remote,SF Delete-Remote

SF Delete-Local

DSC-LocalDeleting

Service FlowStop T10 Timer

DSC Ended

DSC-LocalEnd

283


Figure 11-45 DSC—Locally Initiated Transaction Retries Exhausted State Flow Diagram

DSC-LocalRetries Exhausted

DSC-RSPSF Delete-LocalSF Delete-RemoteTimeout T10

Stop T10 TimerDSC Erred

DSC Ended

DSC-LocalEnd

DSC-LocalDeleting

Service Flow

Okay ?

Yes

ModifyService Flowparameters


DSC-ACK

Save transmittedDSC-ACK


DSCSucceeded

No

Restoreservice flowQoS state

DSC Failed


284


Figure 11-46 DSC—Locally Initiated Transaction Deleting Service Flow State Flow Diagram

DSC-LocalDeleting

Service Flow


SF Delete-Remote

Stop T10 Timer

DSC Ended

DSC-LocalEnd

DSC-RSP

DSC ACKLost

DSC-LocalDeleting

Service Flow

285


Figure 11-47 DSC—Remotely Initiated Transaction Begin State Flow Diagram

DSC-RemoteDSC-ACKPending

SF Delete-Local

Stop T8 Timer

Start T10 Timer

DSC-RemoteDeleting

Service Flow

DSC-ACK

Stop T8 Timer

Okay ?No

YesRestore

service flow

DSC Failed

DSCSucceeded

Start T8 Timer

DSC-RemoteHolding Down

DSC-REQSF DSC-ACK

LostSF Delete-

Remote

Stop T8 Timer

Timeout T8

RetriesAvailable

?

Yes

No


DSC Erred

DSC-RemoteEnd

DSC Ended

DecrementDSC-RSP

Retries Available

SavedDSC-RSP

Start T8 Timer

RetriesAvailable

?

No

Yes

SavedDSC-RSP

286


Figure 11-48 DSC—Remotely Initiated Transaction DSC-ACK Pending State Flow Diagram1

1. Revised Figure 11-48 per ECN RFI2-N-02210, change#11, by GO, on 11/22/02.


SF Delete-Local

Stop T8 Timer

Start T10 Timer

DSC-RemoteDeleting

Service Flow

DSC-ACK

Stop T8 Timer

Okay ?No

Yes

Restoreservice flow

DSC Failed

DSCSucceeded

Start T8 Timer


DSC-REQSF DSC-ACK

LostSF Delete-

Remote

Stop T8 Timer

Timeout T8

RetriesAvailable

?

Yes

No


DSC Erred

DSC-RemoteEnd

DSC Ended

DecrementDSC-RSP

Retries Available

SavedDSC-RSP

Start T8 Timer

RetriesAvailable

?

No

Yes

SavedDSC-RSP

287


Figure 11-49 DSC—Remotely Initiated Transaction Holding Down State Flow Diagram

DSC-RemoteEnd

SF Changed,SF Deleted,

SF Delete-Remote


Timeout T8 DSC-ACK


SF Delete-Local,SF Change-Remote

Stop T8 Timer

DSC Ended

288


Figure 11-50 DSC—Remotely Initiated Transaction Deleting Service Flow State Flow Diagram

11.4.4 Dynamic Service Deletion

Any service flow can be deleted with the Dynamic Service Deletion (DSD) messages. When a Service Flow isdeleted, all resources associated with it are released, including classifiers and PHS. However, if a PrimaryService Flow of a CM is deleted, that CM is de-registered and MUST re-register. Also, if a Service Flow that wasprovisioned during registration is deleted, the provisioning information for that Service Flow is lost until the CMre-registers. However, the deletion of a provisioned Service Flow MUST NOT cause a CM to re-register.Therefore, care should be taken before deleting such Service Flows.

11.4.4.1 CM Initiated Dynamic Service Deletion

A CM wishing to delete an upstream and/or a downstream Service Flow generates a delete request to the CMTSusing a Dynamic Service Deletion-Request message (DSD-REQ). The CMTS removes the Service Flow(s) andgenerates a response using a Dynamic Service Deletion-Response message (DSD-RSP). Only one upstream and/or one downstream Service Flow can be deleted per DSD-Request.

DSC-RemoteDeleting

Service Flow


SF Delete-Remote

Stop T10 Timer

DSC Ended

DSC-RemoteEnd

DSC-REQ,DSC-ACK

DSC-RemoteDeleting

Service Flow

289


Figure 11-51 Dynamic Service Deletion Initiated from CM

11.4.4.2 CMTS Initiated Dynamic Service Deletion

A CMTS wishing to delete an upstream and/or a downstream dynamic Service Flow generates a delete request tothe associated CM using a Dynamic Service Deletion-Request message (DSD-REQ). The CM removes theService Flow(s) and generates a response using a Dynamic Service Deletion-Response message (DSD-RSP).Only one upstream and/or one downstream Service Flow can be deleted per DSD-Request.1

Figure 11-52 Dynamic Service Deletion Initiated from CMTS2

CM CMTS

Service Flow(s) no longerneeded

Delete Service Flow(s)

Send DSD-REQ ---DSD-REQ--> Receive DSD-REQ

Verify CM is Service Flow(s)‘owner’


Receive DSD-RSP <--DSD-RSP--- Send DSD-RSP

CM CMTS

Service Flow(s) no longerneeded


Determine associated CM forthis Service Flow(s)

Receive DSD-REQ <---DSD-REQ--- Send DSD-REQ


Send DSD-RSP ---DSD-RSP--> Receive DSD-RSP

1. text replaced per rfi n-00088, 12/6/00, po2. (s) added per rfi n-00088, 12/6/00, po

290


11.4.4.3 Dynamic Service Deletion State Transition Diagrams

Figure 11-53 DSD—Locally Initiated Transaction Begin State Flow Diagram

SF Delete

DSD-LocalBegin

DSD-LocalDSD-RSPPending

Set DSD-REQRetries Availableto 'DSx Request

Retries'

DSD-REQ

Start T7 Timer

Save transmittedDSD-REQ

Disableservice flow

291


Figure 11-54 DSD—Locally Initiated Transaction DSD-RSP Pending State Flow Diagram


DSD-RSPSF Delete-Remote

DSD-LocalHolding Down

Start T7 Timer

Stop T7 Timer Stop T7 Timer

DSDSucceeded

SF DSD-REQLost

RetriesAvailable

?

Yes

SavedDSD-REQ

Timeout T7

RetriesAvailable

?

Yes

DSD Erred

DSD Ended

DSD-LocalEnd


DecrementDSD-REQ

Retries Available

SavedDSD-REQ

Start T7 Timer

No

No

292


Figure 11-55 DSD—Locally Initiated Transaction Holding Down State Flow Diagram


DSD-RSP

DSDSucceeded


SF DeletedTimeout T7

DSD Ended

DSD-LocalEnd

293


Figure 11-56 DSD—Remotely Initiated Transaction Begin State Flow Diagram

DSD-RemoteBegin

Start T10 Timer

Save transmittedDSD-RSP

DSD-RemoteHolding Down

Disableservice flow

DSD-REQ

DSD-RSP

DSDSucceeded

294


Figure 11-57 DSD—Remotely Initiated Transaction Holding Down State Flow Diagram

11.4.5 Dynamically Changing Downstream and/or Upstream Channels

11.4.5.1 DCC General Operation

At any time after registration, the CMTS MAY direct the CM to change its downstream and/or upstream channel.This may be done for traffic balancing, noise avoidance, or other reasons which are beyond the scope of thisspecification. Figure 11-59 through Figure 11-62 show the procedure that MUST be followed by the CMTS.Figure 11-63 through Figure 11-66 show the corresponding procedure that MUST be followed by a CM.

The DCC command can be used to change only the upstream frequency, only the downstream frequency, or boththe upstream and downstream frequencies. When only the upstream or only the downstream frequency ischanged, the change is typically within a MAC domain. When both the upstream and downstream frequenciesare changed, the change may be within a MAC domain, or between MAC domains.

The Upstream Channel ID MUST be unique between the old and new channels. In this context, the old channelrefers to the channel that the CM was on before the jump, and the new channel refers to the channel that the CMis on after the jump.

Upon synchronizing with the new upstream and/or downstream channel, the CM MUST use the techniquespecified in the DCC-REQ Initialization Technique TLV, if present, to determine if it should perform re-initialization, only ranging, or neither. If this TLV is not present in DCC-REQ, the CM MUST re-initialize itsMAC on the new channel assignment. (Refer to Section 11.2). If the CM has been instructed to re-initialize, thenthe CMTS MUST NOT wait for a DCC-RSP to occur on the new channel.


DSD-REQ


Stop T10 TimerSaved

DSD-RSP

Timeout T10SF Deleted

DSD Ended

DSD-RemoteEnd

295


If the CM is being moved within a MAC domain, then a re-initialization may not be required. If the CM is beingmoved between MAC domains, then a re-initialization may be required. Re-initializing, if requested, is donewith the new upstream and downstream channel assignments. It includes obtaining upstream parameters,establish IP connectivity, establish time of day, transfer operational parameters, register, and initialize baselineprivacy. If re-initialization is performed, the CM MUST NOT send a DCC-RSP on the new channel.

The decision to re-range is based upon the CMTS’s knowledge of any path diversity that may exist between theold and new channels, or if any of the fundamental parameters of the upstream or downstream channel such asmodulation rate, modulation type, or mini-slot size have changed.

When DCC-REQ does not involve re-initialization or re-ranging, the design goal of the CM will typically be tominimize the disruption of traffic to the end user. To achieve this goal, a CM MAY choose to continue to use QoSresources (such as bandwidth grants) on its current channel after receiving a DCC-REQ and before actuallyexecuting the channel change. The CM might also need this time to flush internal queues or reset state machinesprior to changing channels.

The CM MAY continue to use QoS resources on the old channel, including the transmission and reception ofpackets, after sending a DCC-RSP (depart) message and prior to the actual jump. The CM MAY use QoSresources on the new channel, including the transmission and reception of packets, after the jump and prior tosending a DCC-RSP (arrive) message. The CMTS MUST NOT use the DCC-RSP (depart) message to removeQoS resources on the old channel. The CMTS MUST NOT wait for a DCC-RSP (arrive) message on the newchannel before allowing QoS resources to be used. This provision is to allow the Unsolicited Grant Service to beused on the old and new channel with a minimum amount of disruption when changing channels.

The CMTS MUST hold the QoS resources on the old channel until a time of T13 has passed after the last DCC-REQ that was sent, or until it can internally confirm the presence of the CM on the new channel assignment. TheCM MUST execute the departure from the old channel before the expiry of T13. The CM MAY continue to useQoS resources on the old channel after responding with DCC-RSP and before the expiry of T13.

If the CM is commanded to perform initial or station maintenance or to use the channel directly, the destinationCMTS MUST hold the QoS resources on the new channel until a time of T15 has passed after the last DCC-REQwas sent if the CM has not yet been detected on the new channel. If the CM is commanded to re-initialize theMAC, then QoS resources are not reserved on the destination CMTS, and T15 does not apply.

The T15 timer represents the maximum time period for the CM to complete the move to the destination CMTS,and is based on the TLV encodings (i.e. initialization technique TLV) included in the DCC-REQ message and thelocal configuration of the destination CMTS.

The destination CMTS SHOULD calculate and limit T15 based on internal policy according to the guidelines inSection 11.4.5.1.1.

If initialization technique of initial ranging is utilized and if the CM arrives after T15 has passed, attempting touse resources on the new channel that have been removed (ranging or requesting bandwidth on a SID that hasbeen deleted), the CMTS MUST send a Ranging Abort to the CM in order to cause the DCC transaction to fail,ensuring that the CM and CMTS states remain in sync.

When a CM is moved between downstream channels on different IP subnets using initialization techniques otherthan re-initialize the MAC, a network connectivity issue may occur because no DHCP process is indicated aspart of the DCC operation. The CM MAY implement a vendor-specific feature to deal with this situation. TheCMTS SHOULD take this issue into account when sending a DCC-REQ and SHOULD direct the CM to use theappropriate initialization technique TLV to ensure no IP connectivity loss as a result of DCC.

Once the CM changes channels, all previous outstanding bandwidth requests made via the Request IE orRequest/Data IE are invalidated, and the CM MUST re-request bandwidth on the new channel. In the case of

296


Unsolicited Grant Service in the upstream, the grants are implicit with the QoS reservations, and do not need tobe re-requested.

11.4.5.1.1 Derivation of T15 Timer

The maximum value noted for the T15 timer denotes the maximum amount of time that the CMTS shouldreserve resources on the new channel. This value is not to be used to represent acceptable performance.

The equation below describes the method for calculating the value of T15.

T15 = CmJumpTime + CmtsRxRngReq

Each of the variables in the equation calculating the T15 timer is explained in the table below.

The minimum value of the T15 timer is four seconds; this was derived by quadrupling the value of the T13 timer.The maximum value of the T15 timer is 35 seconds.

11.4.5.1.2 Initialization Technique

There are many factors that drive the selection of an initialization technique when commanding a dynamicchannel change. A CM will not be able to successfully execute a channel change given an initialization techniquethat is unsuitable for the cable plant conditions. In some cases, a CM will impair the new channel given anunsuitable initialization technique. For instance, consider the use of initialization technique 4 (use the newchannel(s) directly without re-initializing or performing initial or station maintenance) when there is a significantdifference in propagation delay between the old and new channel. Not only will the CM be unable tocommunicate with the CMTS after the channel change, but its transmissions may also interfere with thetransmissions of other CMs using the channel.

Variable Explanation and Value

CmJumpTime This is the CM’s indication to the CMTS of when it intends to start the jump and howlong it will take to jump. For a downstream change, it includes the time for the CM tosynchronize to the downstream parameters on the destination channel, such as QAMsymbol timing, FEC framing, and MPEG framing. It incorporates CM housecleaning onthe old channel. It also incorporates one T11 period for the CM to process and receivethe DCC-REQ message. This optional value is computed by the CM and returned inDCC-RSP (depart).

If the CM does not specify the Jump Time TLVs, then the destination CMTS assumesthat the value is 1.3 seconds. This recognizes the fact that the CM may continue to usethe old channel until the expiry of the T13 timer.

If the CM specifies the Jump Time TLVs, then the destination CMTS uses the specifiedvalue.

CmtsRxRngReq This variable represents the time for the CM to receive and use a ranging opportunity,and for the CMTS to receive and process the RNG-REQ.

For the initialization technique of use directly, this value is two times the CMTS timeperiod between unicast ranging opportunities plus 20 - 40 milliseconds for MAP andRNG-REQ transmission time and CMTS RNG-REQ processing time.

For the initialization technique of station maintenance, this value is two times theCMTS time period between unicast ranging opportunities plus 20 - 40 milliseconds forMAP and RNG-REQ transmission time and CMTS RNG-REQ processing time.

For the initialization technique of initial maintenance, this value is 30 seconds.Because the variables involved in initial maintenance are not strictly under the controlof the CMTS, the computation of this factor is uncertain.

297


Careful consideration must be given to the selection of an initialization technique. Some restrictions are listedbelow. This list is not exhaustive, but is intended to prevent the use of a particular initialization technique underconditions where its use could prevent the CM from successfully executing the channel change. Note thatpackets may be dropped under some conditions during channel changes.

The use of initialization technique 0 (reinitialize the MAC) results in the longest interruption of service.However, the CMTS MUST signal the use of this technique when QoS resources will not be reserved on the newchannel(s).

The use of initialization technique 1 (broadcast initial ranging) may also result in a lengthy interruption ofservice. However, this interruption of service is mitigated by the reservation of QoS resources on the newchannel(s). The service interruption can be further reduced if the CMTS supplies downstream parameter sub-TLVs and the UCD substitution TLV in the DCC-REQ in addition to providing more frequent initial rangingopportunities on the new channel.

The use of initialization technique 2 (unicast initial ranging) offers the possibility of only a slight interruption ofservice. However, the CMTS MUST NOT use this technique if:

• Propagation delay differences between the old and new channels will cause the burst timing to exceed theranging accuracy requirements for the CM (refer to Section 6.2.19.1).

• Attenuation or frequency response differences between the old and new upstream channels will cause thereceived power at the CMTS to change by more than 6dB.

The use of initialization technique 3 (broadcast initial ranging or unicast initial ranging) offers the possibility ofonly a slight interruption of service. This value might be used when there is uncertainty when the CM mayexecute the DCC command and thus a chance that it might miss station maintenance slots. However, the CMTSMUST NOT use this technique if the conditions for using techniques 1 and 2 are not completely satisfied.

The use of initialization technique 4 (use the new channel without ranging) results in the least interruption ofservice. However, the CMTS MUST NOT use this technique if:

• Any of the following upstream channel-wide parameters is changing:

• Modulation Rate (on an S-CDMA channel only)

• S-CDMA Mode Enable

• S-CDMA US ratio numerator ‘M’

• S-CDMA US ratio numerator ‘N’

• The downstream channel is changing and the CM is operating in S-CDMA mode.

• Attenuation or frequency response differences between the old and new upstream channels will cause thereceived power at the CMTS to change by more than 6dB.

• Propagation delay differences between the old and new channels will cause the burst timing to exceed theranging accuracy requirements for the CM (refer to Section 6.2.19.1).

• Micro-reflections on the new upstream channel will result in an unacceptable BER (greater than 1e-8) withthe pre-equalizer coefficients set to the initial setting (refer to Section 6.2.15).

The CMTS SHOULD NOT use initialization technique 4 when the new or old channel is S-CDMA and themodulation rate is changing.

298


11.4.5.2 DCC Exception Conditions

If a CM issues a DSA-REQ or DSC-REQ for more resources, and the CMTS needs to do a DCC to obtain thoseresources, the CMTS will reject the DSA or DSC command without allocating any resources to the CM. TheCMTS includes a confirmation code of “reject-temporary-DCC” (refer to Section C.1.3.1) in the DSC-RSPmessage to indicate that the new resources will not be available until a DCC is received. The CMTS will thenfollow the DSA or DSC transaction with a DCC transaction.

After the CM jumps to a new channel and completes the DCC transaction, the CM retries the DSA or DSCcommand. If the CM has not changed channels after the expiry of T14, as measured from the time that the CMreceived DSA-RSP or DSC-RSP from the CMTS, then the CM MAY retry the resource request.

If the CMTS needs to change channels in order to satisfy a resource request other than a CM initiated DSA orDSC command, then the CMTS should execute the DCC command first, and then issue a DSA or DSCcommand.

If a CMTS does a DCC with re-initialize, the config file could cause the CM to come back to the originalchannel. This would cause an infinite loop. To prevent this, if the provisioning system default is to specify theupstream channel ID and/or the downstream frequency, then the CMTS SHOULD NOT use DCC-REQ with there-initialize option.

The CMTS MUST NOT issue a DCC command if the CMTS has previously issued a DSA, or DSC command,and that command is still outstanding. The CMTS MUST NOT issue a DCC command if the CMTS is stillwaiting for a DSA-ACK or DSC-ACK from a previous CM initiated DSA-REQ or DSC-REQ command.

The CMTS MUST NOT issue a DSA or DSC command if the CMTS has previously issued a DCC command,and that command is still outstanding.

If the CMTS issues a DCC-REQ command and the CM simultaneously issues a DSA-REQ or DSC-REQ thenthe CMTS command takes priority. The CMTS responds with a confirmation code of “reject-temporary” (referto Section C.1.3.1). The CM proceeds with executing the DCC command.

If the CM is unable to achieve communications with a CMTS on the new channel(s), it MUST return to theprevious channel(s) and re-initialize its MAC. The previous channel assignment represents a known goodoperating point which should speed up the re-initialization process. Also, returning to the previous channelprovides a more robust operational environment for the CMTS to find a CM that fails to connect on the newchannel(s).

If the CMTS sends a DCC-REQ and does not receive a DCC-RSP within time T11, it MUST retransmit theDCC-REQ up to a maximum of “DCC-REQ Retries” (Annex B) before declaring the transaction a failure. Notethat if the DCC-RSP was lost in transit and the CMTS retries the DCC-REQ, the CM may have already changedchannels.

If the CM sends a DCC-RSP on the new channel and does not receive a DCC-ACK from the CMTS within timeT12, it MUST retry the DCC-RSP up to a maximum of “DCC-RSP Retries” (Annex B).

If the CM receives a DCC-REQ with the Upstream Channel ID TLV, if present, equal to the current UpstreamChannel ID, and the Downstream Frequency TLV, if present, is equal to the current downstream frequency, thenthe CM MUST consider the DCC-REQ as a redundant command. The remaining DCC-REQ TLV parametersMUST NOT be executed, and the CM MUST return a DCC-RSP, with a confirmation code of “reject-already-there”, to the CMTS (refer to Section C.4.1).

299


If a DOCSIS 2.0-enabled CM is moved from a Type 1 channel to a Type 2 channel via a DCC using aninitialization technique other than re-initialize the MAC, the CM MUST operate in 2.0 mode on the destinationchannel, basing its requests on IUCs 9 and 10 instead of IUCs 5 and 6. If a CM in which DOCSIS 2.0 is disabledin registration is moved from a Type 1 channel to a Type 2 channel via a DCC with initialization technique otherthan re-initialize the MAC, the CM MUST continue to base its requests on the destination channel on IUCs 5 and6.

If the CM is moved via a DCC using the initialization technique of re-initialize the MAC, the previous 2.0 enablesetting is not applicable. If DOCSIS 2.0 was previously disabled and the target upstream channel is Type 2 orType 3, the 2.0 disable setting is discarded and the CM MUST use the target upstream channel; however, after re-initialization, the CM MUST operate in the 2.0 mode defined in the config file acquired in the re-initializationprocess.

11.4.5.3 DCC Performance

The purpose of a DCC is to move the CM to a new upstream and/or downstream channel with little interruptionof service. There are many factors that affect the performance of a DCC transaction including CMhousecleaning, initialization technique, and the number of TLV hints given by the current CMTS in the DCC-REQ message. Each of these factors is individually discussed in the table below.

The DCC transaction is defined from the perspective of both the CM and the CMTS for the discussion onperformance in the following table. From the perspective of the CM, the DCC transaction begins when the CMreceives the DCC-REQ message from the CMTS and completes when the CM receives the DCC-ACK messagefrom the CMTS. From the perspective of the CMTS, the DCC transaction begins when the CMTS sends theDCC-REQ message to the CM and completes when the CMTS receives the DCC-RSP (arrive) message from theCM.

Table 11-1 Factors affecting DCC performance

TLV Type Value Explanation

InitializationTechnique

Absent or 0

ReinitializeMAC

There are no performance requirements in this case. The CM willarrive on the destination CMTS after initialization occurs.

1

BroadcastInitialRanging

There are low performance expectations in this case because manyfactors affect the performance, such as collisions and rangingbackoff. The CM should arrive on the destination CMTS as quicklyas possible.

2

UnicastInitialRanging

The DCC transaction SHOULD complete within 1.5 seconds afterthe start of jump.

3

Broadcast orUnicastInitialRanging

The CMTS does not know which ranging technique the CM willutilize. The CM should arrive on the destination CMTS as quickly aspossible.

4

Use ChannelDirectly

The DCC transaction SHOULD complete within one second after thestart of jump.

DS Parameter The CMTS SHOULD include the downstream parameter TLVs forstation maintenance and use directly initialization techniques thatare expected to occur quickly.

UCD Substitution The CMTS MUST include the UCD substitution TLV for initializationtechniques of option two, three, or four.

300


When the DCC-REQ does not contain UCD Substitution TLVs and/or specifies an Initialization Technique ofInitial Maintenance, Station Maintenance, or use directly, the destination CMTS SHOULD increase theprobability that the CM will arrive quickly by using the CM Jump Time TLVs specified in the DCC-RSP (depart)to adjust the transmission of UCDs and ranging opportunities such that they coincide with the time when CM hasestimated that it will arrive, and SHOULD increase the frequency of UCDs and/or ranging opportunities duringthis period.

11.4.5.4 Near-Seamless Channel Change

When the CMTS wishes to add new QoS reservations to a CM, it may be necessary to move that CM to a newupstream and/or downstream to achieve that goal. During that changing of channels, it is desirable to provide theminimum of interruption to existing QoS services such as voice over IP or video streaming sessions. This near-seamless channel change is the primary design goal of the DCC command. The CMTS MAY support a near-seamless channel change. The CM MAY support a near-seamless channel change.

The actions below are recommended operating procedures to implement a near-seamless channel change. Thelist assumes both the upstream and downstream channels are changing. A subset of the list would apply if onlythe upstream or downstream channel changed.

To support a near-seamless channel change, the following conditions should apply in the network:

• The physical layer parameters for the new upstream and downstream channels should not changewith respect to the old upstream and downstream channels. Note that a change in downstreamparameters could invalidate the ranging parameters.

• The ranging parameters should not change between the old and new channels. This may requiresymmetrical cabling and plant conditions which are external to the CMTS.

• The CMTS should use the same time stamp and SYNC mechanism for all downstream channels.

• IP routing should be configured so that the CM and its attached CPEs can continue to use theirexisting IP addresses. This will avoid disruption to RTP sessions or other in progress applications.

To achieve a near-seamless channel change, the CMTS:

• SHOULD duplicate all the relevant QoS reservations for the CM on the old and new channelassignments before initiating a DCC-REQ.

• SHOULD duplicate downstream packet flow for the CM on the old and new channel assignmentsbefore initiating a DCC-REQ (for downstream channel changes).

• SHOULD transmit MAP messages for the new upstream channel on the old downstream channel forat least the duration of T13, if the old and new downstream channels share the same timestamp.(Note that if the CM cannot cache MAPs for the new upstream while on the old downstreamchannel, then the channel change delay will be increased by the amount of time into the future thatMAPs are generated. Thus, the CMTS SHOULD refrain from scheduling MAPs farther into thefuture than it needs to.)

• SHOULD specify the downstream and upstream parameters of the new channels prior to the CMjumping.

• SHOULD specify to not wait for a SYNC message on the new channel.

SYNCSubstitution

The CMTS MUST include the SYNC substitution TLV for initializationtechniques of option two, three, or four.

CM Jump Time The length of jump TLV SHOULD be less than one second fordownstream channel changes that include the downstreamparameter TLVs or for upstream only channel changes.

Table 11-1 Factors affecting DCC performance (Continued)

301


• SHOULD specify to skip initialization (as defined in Section 11.2).

• SHOULD specify to skip initial ranging.

• SHOULD manage service flow substitutions between old and new SIDs, SAID, Service Flow IDs,and Unsolicited Grant Time Reference as required. Service Class Names SHOULD remain the samebetween the old and new channel(s).

To achieve a near-seamless channel change, the CM:

• SHOULD reply with estimates for CM Jump Time in the DCC-RSP message.

• SHOULD listen for and cache MAP messages on the old downstream that apply to the newupstream. This SHOULD be done during time T13.

• SHOULD use the downstream parameters and the UCD in its cache from the DCC command toforce a quicker PHY convergence when jumping.

• SHOULD NOT wait for a SYNC message after PHY convergence and before transmitting, if theCMTS permits the CM to do so.

• SHOULD use the cached MAPS, if available, to allow a quicker start-up time.

• SHOULD minimize the disruption of traffic in either direction by allowing traffic to continue toflow in both directions up to the moment prior to the jump and then immediately afterresynchronization to the new channel(s) has happened.

• SHOULD queue incoming data packets that arrive during the jump, and transmit them after thejump.

• SHOULD discard VoIP packets after the jump that have caused the upstream Unsolicited GrantService queue to exceed its limit, but no more than necessary.

Applications that are running over the DOCSIS path should be able to cope with the loss of packets that mayoccur during the time that the CM changes channels.

11.4.5.5 Example Operation

11.4.5.5.1 Example Signalling

Figure 11-58 shows an example of the use of DCC and its relation to the other DOCSIS MAC messages. Inparticular, this example describes a scenario where the CM attempts to allocated new resources with a DSAmessage. The CMTS temporarily rejects the request, tells the CM to change channels, and then the CM re-requests the resources. This example (not including all exception conditions) is described below. Refer toSection 11.2 for more detail.

a) An event occurs, such as the CM issuing a DSA-REQ message.

b) The CMTS decides that it needs the CM to change channels in order to service this resource request. TheCMTS responds with a DSA-RSP message which includes a confirmation code of “reject-temporary-DCC”(refer to Section C.1.3.1) in the DSC-RSP message to indicate that the new resources are not available untila DCC is received. The CMTS now rejects any further DSA or DSC messages until the DCC command isexecuted.

c) The CMTS initiates QoS reservations on the new upstream and/or downstream channels. The QoSreservations include the new resource assignment along with all the current resource assignments assignedto the CM. In this example, both the upstream and downstream channels are changed.

d) To facilitate a near-seamless channel change, since the CMTS is not sure exactly when the CM will switchchannels, the CMTS duplicates the downstream packet flow on the old and new downstream channels.

302


e) The CMTS issues a DCC-REQ command to the CM.

f) The CM sends a DCC-RSP (depart). The CM then cleans up its queues and state machines as appropriateand changes channels.

g) If there was a downstream channel change, the CM synchronizes to the QAM symbol timing, synchronizesthe FEC framing, and synchronizes with the MPEG framing.

h) If the CM has been instructed to re-initialization, it does so with the new upstream and/or downstreamchannel assignment. The CM exits from the flow of events described here, and enters the flow of eventsdescribed in Section 11.2 starting with the recognition of a downstream SYNC message.

i) The CM searches for a UCD message unless it has been supplied with a copy.

j) The CM waits for a downstream SYNC message unless it has been instructed not to wait for one.

k) The CM collects MAP messages unless it already has them available in its cache.

l) The CM performs initial ranging unless it has been instructed to skip them.

m) The CM resumes normal data transmission with its new resource assignment.

n) The CM sends a DCC-RSP (arrive) message to the CMTS.

o) The CMTS responds with a DCC-ACK.

p) The CMTS removes the QoS reservations from the old channels. If the downstream packet flow wasduplicated, the packet duplication would also be removed on the old downstream channel.

q) The CM re-issues its DSA-REQ command.

r) The CMTS reserves the requested resources and responds with a DSA-RSP.

s) The CM finishes with a DSA-ACK.

303


Figure 11-58 DCC Example Operational Flow

DS #1 US #1 US #2 DS #2CM

data traffic

data traffic

DSA-REQ

DSA-ACK

DSA-RSP

data traffic

DCC-REQ

DCC-RSP

Sync of QAM, FEC,MPEG

UCD (optional)

SYNC (optional)

MAP (optional)

data traffic

Optional re-range

data traffic

reserve resourcesand duplicate

downstream traffic

data traffic

data traffic

CM changes channels

data traffic

CMTS

release resourcesand stop traffic

duplication

DCC-RSP

DCC-ACK

Optional re-initialize and exit from flow

Start T14

DSA-REQ

DSA-RSP

DSA-ACK

Start T11, T13

Start T12

304


The states for the old and new CMTSes are shown as separate flow diagrams, since the old and new CMTS maybe different. If the CMTSes are the same (e.g., the same MAC domain), the CMTS will need to run both sets ofstate machines concurrently.

The flow diagrams show points where explicit signaling between the old and new CMTS is desirable, especiallyfor near-seamless operation. The mechanism for this signaling is beyond the scope of this specification.

Note that the flow diagrams for both old and new CMTSes have been carefully crafted to handle many errorconditions, such as:

• If the CM does not respond to the DCC-REQ (or responds with a reject conf code) and does not move, then itwill be allowed to remain on the old channel. Resources on the new channel will be released (old CMTS sig-nals DCC aborted to the new CMTS).

• If the CM DCC-RSP (depart) is lost, but the CM moves and arrives on the new CMTS, the new CMTS willsignal that the CM has arrived to the old CMTS, allowing it to remove resources.

• If the CM DCC-RSP (depart) is received and the CM DCC-RSP (arrive) is lost, but the new CMTS otherwisedetects the presence of the CM, the DCC transaction is considered successful, and the CM is allowed toremain on the new channel.

• If the CM DCC-RSP (depart) and (arrive) are lost, but the new CMTS otherwise detects the presence of theCM, the new CMTS will signal that the CM has arrived to the old CMTS, allowing it to remove resources,and the CM is allowed to remain on the new channel.

• If the CM DCC-RSP (depart) is received, but the CM never arrives, the new CMTS will detect this andremove resources after T15 expires.

• If the CM DCC-RSP (depart) is lost and the CM never arrives, the old CMTS will signal DCC aborted to thenew CMTS, allowing it to remove resources. The old CMTS will use a different mechanism outside the scopeof the DCC flow diagrams (such as ranging timeout) to remove resources on the old channels.

• If the CMTS DCC-ACK is lost and the DCC-RSP retry counter is expired, the CM will log and error and con-tinue to the operational state.

There is a race condition that is not addressed in the flow diagrams; if the CM DCC-RSP (depart) is lost, the oldCMTS will signal DCC aborted to the new CMTS. If the CM is in the process of moving, but has not yet arrived,the new CMTS will remove resources. This will prevent the CM from arriving successfully, unless it is able tocomplete the jump and arrive in approximately 1.2 seconds (3 retries of the DCC-REQ).

305


Figure 11-59 Dynamically Changing Channels: CMTS View Part 1

Previous CMTSOperational

ChannelChange

Required

Set DCC-REQretry counter to 0

DCC-REQ

Start T11Start T13

Previous CMTS DCC-RSP (depart) Pending

DCC-RSP(<conf code>)

ERROR:Unknown

DCCtransaction


DCCCMTS A

New CMTSOperational

DCC beginning (tonew CMTS),

including DCC-REQ parameters

Prepare newchannel(s) withany appropriate

resourceassignments


ERROR:Unknown

DCCtransaction

New CMTSOperational

New CMTS DCC-RSP(arrive) Pending

Note that the new CMTS is not informed of the DCC if theCM will Reset the MAC, and it will ignore other events thatare sent by the old CMTS in other states.

DCC beginning(from old CMTS),including DCC-

REQ parameters

InitializationTechnique =Reinitializethe MAC?

No

Yes

Other eventfrom oldCMTS

New CMTSOperational

Ignore the event.

Start T15

306



Previous CMTS DCC-RSP (depart) Pending

DCC-RSP(reject-

<reason>)

DCC-RSP(depart)

Timeout T11

DCC-REQRetries

Exhausted?

IncrementDCC-REQ retries

counter

No

ERROR:CM not

responding

Yes


ERROR:DCC-REQrejected

<reason>

Previous CMTSDCC

T13 Pending

Stop T11 Stop T11

Stop T13

DCCCMTS A

DCC-RSPCM Jump

Time (to newCMTS)

DCC Aborted (tonew CMTS)

CM Arrived(from new

CMTS)

Remove oldchannelresource

assignments.


ERROR:DCC-RSP

(depart) lost

Stop T11Stop T13

307



Previous CMTSDCC

T13 Pending

Timeout T13CM no longer

present onold channel

Stop T13


Remove oldchannel resource

assignments.

1

1 The mechanism to determinethis event is vendor-specific.


ERROR:Unknown

DCCtransaction

Previous CMTSDCC

T13 Pending

CM Arrived(from new

CMTS)

308



New CMTS DCCHold-down

Timeout T10DCC-RSP

(arrive)

DCC-ACK


New CMTSOperational


DCC-RSP(arrive)

DCC-ACK


Start T10

Timeout T15

Remove newchannel resource

assignments.

New CMTSOperational

ERROR:CM notarriving

CM Arrived(to old CMTS)

DCC-RSPCM Jump

Time (fromold CMTS)


Store JumpTime

DCC Aborted(from oldCMTS)

ERROR:DCC Aborted

CM detectedon newchannel

1

1 Determination of this is CMTS-specific, but can include receivingRNG-REQ or bandwidth requestsfrom the CM on the new channel.

Stop T15 Stop T15Restart T15

309


Figure 11-63 Dynamically Changing Channels: CM View Part 1

CM Operational

DCC-REQ

Already usingUS and DSchannels?

DCC-RSP(reject-

already-there)

Yes

ERROR: BadCMTS DCC

already-there

CM Operational

No

Can jump bemade?

DCC-RSP(depart)

Yes

No

DCC-RSP(reject-

<reason>)

ERROR:DCC-REQ

denied

CM Operational

Clean up internalqueues and other

housekeeping

Apply Id substitutions,store UCD from

DCC-REQ (if present)

DCCCM A

DCC-REQvalid?

Parse DCC-REQ

Yes

DCC-RSP(reject-

<reason>)

No

ERROR: BadCMTS DCC<reason>

CM Operational

310



DownstreamChange?

No

YesCM DCC

Downstream Change

Initializationtechnique =Re-init the

MAC?

Yes Reset the MAC


NoInitializationtechnique =

Use-Directly?

No

Valid UCD fortarget upstream

stored?

Yes

CM DCCAcquire UCD

No

DCCCM A

Yes

DCC-RSP(arrive)

Start T12

CM DCC-ACK pending

Set DCC-RSP(arrive) retrycounter to 0

DCCCM B

CM DCCRanging

Wait forSYNCs?

Valid MAP incache?

No

Yes

CM DCCAcquire SYNC

Yes

CM DCCAcquire MAP

No

The state “ObtainUpstream Parameters”links to the state machinein Figure 11-1.

1

1

311



Change tuner, attemptdownstream lock (usinghints provided by CMTS

in DCC-REQ, if any)

Successfullock?

Yes

No

CM DCC Failed

CM DCCDownstream Change

{Return to maindiagram}

CM DCCAcquire MAP

Wait for a MAPmessage.

MAPacquired?


CM DCC Failed

No

Yes

Perform rangingas required (initial/

station).

RangingSuccess?

CM DCCRanging

No

CM DCC Failed


Yes

See Figures 11-6and 11-7 for details.

2

2

CM DCCAcquire SYNC

Wait for a SYNCmessage (up to

Lost SYNCInterval).

SYNCacquired?


CM DCC Failed

No

Yes

CM DCCAcquire UCD

Wait for Valid UCDfor target

upstream channel(or expiry of T1)

Valid UCDacquired?

No

CM DCC Failed


Yes

1

11. If DOCSIS 2.0 is enabled, a valid UCD

describes either a type 1, 2, or 3channel.

2. If DOCSIS 2.0 is NOT enabled, a validUCD describes a type 1 or type 2channel.

312



CM DCC-ACK pending

Timeout T12 DCC-ACK

Stop T12

CM Operational

IncrementDCC-RSP (arrive)

retry counter

No

DCC-RSPretries

exhausted?

DCCCM B

Yes

ERROR:DCC-ACK not

received

Parse DCC-ACK

DCC-ACKvalid?

No

ERROR: BadCMTS DCC-

ACK

CM DCC-ACK pending

Yes

Return to oldupstream/

downstream.

Reset the MAC


CM DCC Failed

ERROR:DCC failed<reason>

The state “ObtainUpstream Parameters”links to the statemachine in Figure 9-1.

313


11.4.5.5.2 Example Timing

11.4.5.5.2.1 Upstream and Downstream Change (Use Channel Directly: CMTS Supplies All TLV Hints)

In this example, the current CMTS sends a DCC-REQ message requesting that the CM switch both upstream anddownstream channels. The DCC-REQ message includes the UCD substitution TLV, the SYNC substitution TLV,the downstream parameter TLVs, and the initialization technique TLV of 4 (use channel directly). The CM doesnot include the CM jump time TLV in the DCC-RSP.

The destination CMTS has the following local parameters:

UCD interval – 1 secondSYNC interval – 10 msec.Unicast ranging interval – 1 sec.

The destination CMTS calculates the T15 timer value. The definition of the formula used to determine T15 isshown below. The variables used in calculating T15 are explained in the table below.


T15 = 1.3 sec. + (2.04 sec.) = 3.34 sec.

The CM synchronizes to the downstream parameters on the new channel, applies the UCD supplied in the DCC-REQ, collects MAP messages on the new channel, and resumes normal data transmission on the destinationchannels. This occurs within the recommended performance of 1 second.

11.4.5.5.2.2 Upstream and Downstream Change (Station maintenance: CMTS Supplies No TLV Hints)

In this example, the current CMTS sends a DCC-REQ message requesting that the CM switch both upstream anddownstream channels. The DCC-REQ message includes the initialization technique TLV of 2 (perform stationmaintenance). It also includes the required UCD substitution TLV and SYNC substitution sub-TLV. The CMdoes not include the CM jump time TLV in the DCC-RSP.

The destination CMTS has the following local parameters:

UCD interval – 1 secondSYNC interval – 10 msec.Unicast ranging interval – 1 sec.

The destination CMTS starts scheduling the CM immediately after it sends the DCC-REQ. The destinationCMTS calculates the T15 timer value. The definition of the formula used to determine T15 is shown below. Thevariables used in calculating T15 are explained in the table below.


Variable Value Explanation

CmJumpTime 1.3 sec. Since the CM did not include the optional jump time TLV, theCMTS will use the default value of 1.3 seconds.

CmtsRxRngReq 2.02 sec

2 * (1 sec.) + 40msec.

Two times the CMTS time period between unicast rangingopportunities plus 20 - 40 milliseconds for MAP and RNG-REQ transmission time and CMTS RNG-REQ processingtime.

314


T15 = 1.3 sec. + (2.04 sec.) = 3.34 sec.

The CM should synchronize to the downstream parameters on the new channel, apply the UCD messageprovided, collect MAP messages on the destination channel without waiting for a downstream SYNC on thedestination channel, perform station maintenance on the destination channel, and resume normal datatransmission on the destination channels.

These events occur in less than two seconds; this is within the acceptable performance criteria. The DCCtransaction occurred within the recommended four second sum of CM jump time and two ranging intervals (0 +2 sec. = 2 sec.).

11.5 Fault Detection and Recovery

Fault detection and recovery occurs at multiple levels.

• At the physical level, FEC is used to correct errors where possible — refer to Section 6 for details.

• The MAC protocol protects against errors through the use of checksum fields across both the MAC Headerand the data portions of the packet - refer to Section 8 for details.

• All MAC management messages are protected with a CRC covering the entire message, as defined in Section8. Any message with a bad CRC MUST be discarded by the receiver.

Table 11-2 shows the recovery process that MUST be taken following the loss of a specific type of MACmessage.

SP-OSSIv2.0 [DOCSIS5] appendix F contains a list of error codes with more useful information as to the failureof the PHY and MAC layers. Refer to Section 8.2.8 for additional information.

Variable Value Explanation

CmJumpTime 1.3 sec. Since the CM did not include the optional jump time TLV, theCMTS will use the default value of 1.3 seconds.

CmtsRxRngReq 2.02 sec

2 * (1 sec.) + 40msec.

Two times the CMTS time period between unicast rangingopportunities plus 20 - 40 milliseconds for MAP and RNG-REQ transmission time and CMTS RNG-REQ processingtime.

315


Table 11-2 Recovery Process on Loss of Specific MAC Messages

Messages at the network layer and above are considered to be data packets by the MAC Sublayer. These areprotected by the CRC field of the data packet and any packets with bad CRCs are discarded. Recovery from theselost packets is in accordance with the upper layer protocol.

11.5.1 Prevention of Unauthorized Transmissions

A CM SHOULD include a means for terminating RF transmission if it detects that its own carrier has been oncontinuously for longer than the longest possible valid transmission.

Message Name Action Following Message Loss

SYNC The CM can lose SYNC messages for a period of the Lost SYNC interval (see Annex B) before ithas lost synchronization with the network. A CM that has lost synchronization MUST NOT use theupstream and MUST try to re-establish synchronization.

UCD During CM initialization the CM MUST receive a usable1 UCD before transmitting on theupstream. When in the “Obtain Upstream Parameters” state of CM initialization process, if the CMdoesn’t receive a usable UCD within the T1 timeout period, the CM MUST NOT transmit on theupstream and MUST scan for another downstream channel. After receiving a usable UCD,whenever the CM receives an unusable UCD or a MAP with a UCD Count that doesn’t match theConfiguration Change Count of the last UCD received, the CM MUST NOT transmit on theupstream and MUST start the T1 timer. If the T1 timer expires under these circumstances, the CMMUST reset and reinitialize its MAC connection.

1. A usable UCD is one that contains legal profiles that the modem can understand. The CM MAY alsorequire that the UCD Count of the MAPs received match the Configuration Change Count field of the lastreceived UCD before it considers the UCD as usable.

MAP A CM MUST NOT transmit without a valid upstream bandwidth allocation. If a MAP is missed dueto error, the CM MUST NOT transmit for the period covered by the MAP.

RNG-REQ

RNG-RSP

If a CM fails to receive a valid ranging response within a defined timeout period after transmitting arequest, the request MUST be retried a number of times (as defined in Annex B). Failure toreceive a valid ranging response after the requisite number of attempts MUST cause the modemto reset and reinitialize its MAC connection.

REG-REQ

REG-RSP

If a CM fails to receive a valid registration response within a defined timeout period aftertransmitting a request, the request will be retried a number of times (as defined in Annex B).Failure to receive a valid registration response after the requisite number of attempts will causethe modem to reset and reinitialize its MAC connection.

UCC-REQ

UCC-RSP

If a CMTS fails to receive a valid upstream channel change response within a defined timeoutperiod after transmitting a request, the request MUST be retried a number of times (as defined inAnnex B). Failure to receive a valid response after the requisite number of attempts MUST causethe CMTS to consider the CM as unreachable.

316


12 Supporting Future New Cable Modem Capabilities

12.1 Downloading Cable Modem Operating Software

A CMTS SHOULD be capable of being remotely reprogrammed in the field via a software download over thenetwork.

The cable modem MUST be capable of being remotely reprogrammed in the field via a software download overthe network. This software download capability MUST allow the functionality of the cable modem to be changedwithout requiring that cable system personnel physically revisit and reconfigure each unit. It is expected that thisfield programmability will be used to upgrade cable modem software to improve performance, accommodatenew functions and features (such as enhanced class of service support), correct any design deficienciesdiscovered in the software, and to allow a migration path as the Data Over Cable Interface Specification evolves.

The mechanism used for download MUST be TFTP file transfer. The mechanism by which transfers are securedand authenticated is in [DOCSIS8]. The transfer MUST be initiated in one of two ways:

• An SNMP manager requests the CM to upgrade.

• If the Software Upgrade File Name in the CM’s configuration file does not match the current software imageof the CM, the CM MUST request the specified file via TFTP from the Software Server.

Note: The Software Server IP Address is a separate parameter. If present, the CM MUST attempt to download the specifiedfile from this server. If not present, the CM MUST attempt to download the specified file from the configuration file server.

The CM MUST verify that the downloaded image is appropriate for itself. If the image is appropriate, the CMMUST write the new software image to non-volatile storage. Once the file transfer is completed successfully, theCM MUST restart itself with the new code image.

If the CM is unable to complete the file transfer for any reason, it MUST remain capable of accepting newsoftware downloads (without operator or user interaction), even if power or connectivity is interrupted betweenattempts. The CM MUST log the failure and MAY report it asynchronously to the network manager.

Following upgrade of the operational software, the CM MAY need to follow one of the procedures describedabove in order to change channels to use the enhanced functionality.

If the CM is to continue to operate in the same upstream and downstream channels as before the upgrade, then itMUST be capable of inter-working with other CMs which may be running previous releases of software.

Where software has been upgraded to meet a new version of the specification, then it is critical that it MUSTinter-work with the previous version in order to allow a gradual transition of units on the network.

317



318


Annex A Well-Known Addresses

A.1 MAC Addresses

MAC addresses described here are defined using the Ethernet/ISO8802-3 convention as bit-little-endian.

The following multicast address MUST be used to address the set of all CM MAC sublayers; for example, whentransmitting Allocation Map PDUs:

01-E0-2F-00-00-01

The addresses in the range

01-E0-2F-00-00-02 through 01-E0-2F-00-00-0F

are reserved for future definition. Frames addressed to any of these addresses SHOULD NOT be forwarded outof the MAC-sublayer domain.

A.2 MAC Service IDs

The following MAC Service IDs have assigned meanings. Those not included in this table are available forassignment, either by the CMTS or administratively.

A.2.1 All CMs and No CM Service IDs

The following Service IDs are used in MAPs for special purposes or to indicate that any CM can respond in thecorresponding interval.

0x0000 is addressed to no CM. This address is typically used when changing upstream burst parameters so thatCMs have time to adjust their modulators before the new upstream settings take effect. This is also the“Initialization SID” used by the CM during initial ranging.

0x3FFF is addressed to all CMs. It is typically used for broadcast Request intervals or Initial Maintenanceintervals.

A.2.2 Well-Known Multicast Service IDs

The following Service IDs are only used for Request/Data IEs. They indicate that any CM can respond in a giveninterval, but that the CM must limit the size of its transmission to a particular number of mini-slots (as indicatedby the particular multicast SID assigned to the interval).

0x3FF1-0x3FFE is addressed to all CMs. IDs in this range are available for small data PDUs, as well as requests(used only with request/data IEs). The last digit indicates the frame length and transmission opportunities asfollows:

0x3FF1: Within the interval specified, a transmission may start at any mini-slot, and must fit within onemini-slot.

0x3FF2: Within the interval specified, a transmission may start at every other mini-slot, and must fitwithin two mini-slots (e.g., a station may start transmission on the first mini-slot within the interval, thethird mini-slot, the fifth, etc.).

319


0x3FF3: Within the interval specified, a transmission may start at any third mini-slot, and must fitwithin three mini-slots (e.g., starts at first, fourth, seventh, etc.).

0x3FF4: Starts at first, fifth, ninth, etc.

...

0x3FFD: Starts at first, fourteenth (14th), twenty-seventh (27th), etc.

0x3FFE: Within the interval specified, a transmission may start at any 14th mini-slot, and must fit within14 mini-slots.

A.2.3 Priority Request Service IDs

The following Service IDs (0x3Exx) are reserved for Request IEs (refer to Section C.2.2.5.1, “Traffic Priority,”on page 354).

If 0x01 bit is set, priority zero can request.

If 0x02 bit is set, priority one can request.

If 0x04 bit is set, priority two can request.

If 0x08 bit is set, priority three can request.

If 0x10 bit is set, priority four can request.

If 0x20 bit is set, priority five can request.

If 0x40 bit is set, priority six can request.

If 0x80 bit is set, priority seven can request.

Bits can be combined as desired by the CMTS upstream scheduler for any Request IUCs.

A.3 MPEG PID

All DOCSIS data MUST be carried in MPEG-2 packets with the header PID field set to 0x1FFE.

320


Annex B Parameters and Constants

System Name Time ReferenceMinimum

ValueDefaultValue

MaximumValue

CMTS Sync Interval Nominal time between transmission ofSYNC messages (refer to Section 8.3.2)

200 msec

CMTS UCD Interval Time between transmission of UCDmessages (refer to Section 8.3.3)

2 sec

CMTS Max MAP Pending The number of mini-slots that a CMTS isallowed to map into the future (refer toSection 8.3.4)

4096 mini-slot times

CMTS Ranging Interval Time between transmission of broadcastRanging requests (refer to Section 9.3.3)

2 sec

CM Lost Sync Interval Time since last received Sync messagebefore synchronization is considered lost

600 msec

CM ContentionRanging Retries

Number of Retries on contention RangingRequests (refer to Section 11.2.4)

16

CM,CMTS

Invited RangingRetries

Number of Retries on inviting RangingRequests (refer to Section 11.2.4)

16

CM Request Retries Number of retries on bandwidthallocation requests

16

CMCMTS

RegistrationRequest/Response Retries

Number of retries on registrationrequests/responses

3

CM Data Retries Number of retries on immediate datatransmission

16

CMTS CM MAPprocessing time

Time provided between arrival of the lastbit of a MAP at a CM and effectiveness ofthat MAP (refer to Section 9.1.5)

(200 + M/5.12) µs(ref Section6.2.17)

CMTS CM RangingResponseprocessing time

Minimum time allowed for a CM followingreceipt of a ranging response before it isexpected to reply to an invited rangingrequest

1 msec

CMTS CM Configuration The maximum time allowed for a CM,following receipt of a configuration file, tosend a Registration Request to a CMTS.

30 sec

CM T1 Wait for UCD timeout 5 * UCDintervalmaximumvalue

CM T2 Wait for broadcast ranging timeout 5 * ranginginterval

CM T3 Wait for ranging response 50 msec 200 msec 200 msec

CM T4 Wait for unicast ranging opportunity. Ifthe pending-till-complete field was usedearlier by this modem, then the value ofthat field must be added to this interval.

30 sec 35 sec

CMTS T5 Wait for Upstream Channel Changeresponse

2 sec

CMCMTS

T6 Wait for REG-RSP and REG-ACK 3 sec

CMCMTS

Mini-slot size for1.x channels.

Size of mini-slot for upstreamtransmission. For channels that supportDOCSIS 1.x CMs.

32modulationintervals

321


CMCMTS

Mini-slot size forDOCSIS 2.0 OnlyChannels.

Size of mini-slot for upstreamtransmission. For channels that do notsupport DOCSIS 1.x CMs.

16 symbols

CM

CMTS

Timebase Tick System timing unit 6.25 µsec

CM

CMTS

DSx RequestRetries

Number of Timeout Retries on DSA/DSC/DSD Requests

3

CM

CMTS

DSx ResponseRetries

Number of Timeout Retries on DSA/DSC/DSD Responses

3

CM

CMTS

T7 Wait for DSA/DSC/DSD Responsetimeout

1 sec

CM

CMTS

T8 Wait for DSA/DSC Acknowledge timeout 300 msec

CM TFTP BackoffStart

Initial value for TFTP backoff 1sec

CM TFTP Backoff End Last value for TFTP backoff 16 sec

CM TFTP RequestRetries

Number of retries on TFTP request 16

CM TFTP DownloadRetries

Number of retries on entire TFTPdownloads

3

CM TFTP Wait The wait between TFTP retry sequences 10 min

CM ToD Retries Number of Retries per ToD Retry Period 3

CM ToD Retry Period Time period for ToD retries 5 min

CMTS T9 Registration Timeout, the time allowedbetween the CMTS sending a RNG-RSP(success) to a CM, and receiving a REG-REQ from that same CM.

15 min 15 min

CM

CMTS

T10 Wait for Transaction End timeout 3 sec

CMTS T11 Wait for a DCC Response on the oldchannel

300 ms

CM T12 Wait for a DCC Acknowledge 300 ms

CMTS T13 Maximum holding time for QoS resourcesfor DCC on the old channel

1 sec

CM T14 Minimum time after a DSx reject-temp-DCC and the next retry of DSx command

2 sec

CMTS T15 Maximum holding time for QoS resourcesfor DCC on the new channel

2 sec 35 sec

CM T16 Maximum length of time CM remains intest mode after receiving TST-REQmessage.

30 min.1

CMTS DCC-REQ Retries Number of retries on Dynamic ChannelChange Request

3

CM DCC-RSP Retries Number of retries on Dynamic ChannelChange Response

3

CM Lost DCI-REQinterval

Time from sending DCI-REQ and notreceiving a DCI-RSP

2 sec

CM DCI-REQ retry Number of retries of DCI-REQ beforerebooting

16


ValueDefaultValue

MaximumValue

322


CM DCI Backoff start Initial value for DCI backoff 1 sec

CM DCI Backoff end Last value for DCI backoff 16 sec

CMTS CM UCDprocessing time

Time between the transmission of the lastbit of a UCD with a new Change Countand the transmission time of the first bit ofthe first MAP using the new UCD. (SeeSection 11.3.2)

1 ms

1. Row “CM T16” added per RFI2-N-02102 by RKV on 10/28/02.


ValueDefaultValue

MaximumValue

323



324


Annex C Common Radio Frequency Interface Encodings

C.1 Encodings for Configuration and MAC-Layer Messaging

The following type/length/value encodings MUST be used in both the configuration file (see Annex D), in CMregistration requests and in Dynamic Service Messages. All multi-octet quantities are in network-byte order, i.e.,the octet containing the most-significant bits is the first transmitted on the wire.

The following configuration settings MUST be supported by all CMs which are compliant with thisspecification.

C.1.1 Configuration File and Registration Settings

These settings are found in the configuration file and, if present, MUST be forwarded by the CM to the CMTS inits Registration Request.

C.1.1.1 Downstream Frequency Configuration Setting

The receive frequency to be used by the CM. It is an override for the channel selected during scanning. This isthe center frequency of the downstream channel in Hz stored as a 32-bit binary number.

Valid Range: The receive frequency MUST be a multiple of 62500 Hz.

C.1.1.2 Upstream Channel ID Configuration Setting

The upstream channel ID which the CM MUST use. The CM MUST listen on the defined downstream channeluntil an upstream channel description message with this ID is found. It is an override for the channel selectedduring initialization.

C.1.1.3 Network Access Control Object

If the value field is a 1, CPEs attached to this CM are allowed access to the network, based on CM provisioning.If the value of this field is a 0, the CM MUST NOT forward traffic from attached CPE to the RF MAC network,but MUST continue to accept and generate traffic from the CM itself. The value of this field does not affectCMTS service flow operation and does not affect CMTS data forwarding operation.

The intent of “NACO = 0” is that the CM does not forward traffic from any attached CPE onto the cable network.(A CPE is any client device attached to that CM, regardless of how that attachment is implemented.) However,with “NACO = 0”, management traffic to the CM is not restricted. Specifically, with NACO off, the CM remainsmanageable, including sending/receiving management traffic such as (but not limited to):

• ARP: allow the modem to resolve IP addresses, so it can respond to queries or send traps.

Type Length Value

1 4 Rx Frequency

Type Length Value

2 1 Channel ID

Type Length On / Off

3 1 1 or 0

325


• DHCP: allow the modem to renew its IP address lease.

• ICMP: enable network troubleshooting for tools such as “ping” and “traceroute.”

• ToD: allow the modem to continue to synchronize its clock after boot.

• TFTP: allow the modem to download either a new configuration file or a new software image.

• SYSLOG: allow the modem to report network events.

• SNMP: allow management activity

In DOCSIS v1.1, with NACO off, the primary upstream and primary downstream service flows of the CMremain operational only for management traffic to and from the CM. With respect to DOCSIS v1.1 provisioning,a CMTS should ignore the NACO value and allocate any service flows that have been authorized by theprovisioning server.

C.1.1.4 DOCSIS 1.0 Class of Service Configuration Setting

This field defines the parameters associated with a DOCSIS 1.0 class of service. Any CM registering with aDOCSIS 1.0 Class of Service Configuration Setting MUST be treated as a DOCSIS 1.0 CM. Refer toSection 8.3.8, “Registration Response (REG-RSP),” on page 150.

This field defines the parameters associated with a class of service. It is somewhat complex in that is composedfrom a number of encapsulated type/length/value fields. The encapsulated fields define the particular class ofservice parameters for the class of service in question. Note that the type fields defined are only valid within theencapsulated class of service configuration setting string. A single class of service configuration setting is used todefine the parameters for a single service class. Multiple class definitions use multiple class of serviceconfiguration setting sets.

C.1.1.4.1 Class ID

The value of the field specifies the identifier for the class of service to which the encapsulated string applies.

Valid Range: The class ID MUST be in the range 1 to 16.

C.1.1.4.2 Maximum Downstream Rate Configuration Setting

For a single SID modem, the value of this field specifies the maximum downstream rate in bits per second thatthe CMTS is permitted to forward to CPE unicast MAC addresses learned or configured as mapping to theregistering modem.

For a multiple SID modem, the aggregate value of these fields specifies the maximum downstream rate in bitsper second that the CMTS is permitted to forward to CPE unicast MAC addresses learned or configured asmapping to the registering modem.

Type Length Value

4 n

Type Length Value

4.1 1

326


This is the peak data rate for Packet PDU Data (including destination MAC address and the CRC) over a one-second interval. This does not include MAC packets addressed to broadcast or multicast MAC addresses. TheCMTS MUST limit downstream forwarding to this rate. The CMTS MAY delay, rather than drop, over-limitpackets.

Note: This is a limit, not a guarantee that this rate is available.

C.1.1.4.3 Maximum Upstream Rate Configuration Setting

The value of this field specifies the maximum upstream rate in bits per second that the CM is permitted toforward to the RF Network.

This is the peak data rate for Packet PDU Data (including destination address and the CRC) over a one-secondinterval. The CM MUST limit all upstream forwarding (both contention and reservation-based), for thecorresponding SID, to this rate. The CM MUST include Packet PDU Data packets addressed to broadcast ormulticast addresses when calculating this rate.

The CM MUST enforce the maximum upstream rate. It SHOULD NOT discard upstream traffic simply becauseit exceeds this rate.

The CMTS MUST enforce this limit on all upstream data transmissions, including data sent in contention. TheCMTS SHOULD generate an alarm if a modem exceeds its allowable rate.

Note: The purpose of this parameter is for the CM to perform traffic shaping at the input to the RF network and for the CMTSto perform traffic policing to ensure that the CM does not exceed this limit.

The CMTS could enforce this limit by any of the following methods:

a) discarding over-limit requests.

b) deferring (through zero-length grants) the grant until it is conforming to the allowed limit.

c) discarding over-limit data packets.

d) Reporting to a policy monitor (for example, using the alarm mechanism) that is capable of incapacitatingerrant CMs.

Note: This is a limit, not a guarantee that this rate is available.

C.1.1.4.4 Upstream Channel Priority Configuration Setting

The value of the field specifies the relative priority assigned to this service class for data transmission in theupstream channel. Higher numbers indicate higher priority.

Valid Range: 0 - 7

Type Length Value

4.2 4

Type Length Value

4.3 4

Type Length Value

4.4 1

327


C.1.1.4.5 Guaranteed Minimum Upstream Channel Data Rate Configuration Setting

The value of the field specifies the data rate in bit/sec which will be guaranteed to this service class on theupstream channel.

C.1.1.4.6 Maximum Upstream Channel Transmit Burst Configuration Setting

The value of the field specifies the maximum transmit burst (in bytes) which this service class is allowed on theupstream channel. A value of zero means there is no limit. Note: This value does not include any physical layeroverhead.

C.1.1.4.7 Class-of-Service Privacy Enable

This configuration setting enables/disables Baseline Privacy on a provisioned CoS. See [DOCSIS10].

Table C-1 Sample DOCSIS 1.0 Class of Service Encoding

C.1.1.5 CM Message Integrity Check (MIC) Configuration Setting

The value field contains the CM message integrity check code. This is used to detect unauthorized modificationor corruption of the configuration file.

Type Length Value

4.5 4

Type Length Value

4.6 2

Type Length Enable / Disable

4.7 (= CoS_BP_ENABLE) 1 1 or 0

Type LengthValue

(sub)type Length Value

4 28 class of service configuration setting

1 1 1 service class

2 4 10,000,000 max. downstream rate of 10 Mb/sec

3 4 300,000 max. upstream rate of 300 kbps

4 1 5 return path priority of 5

5 4 64,000 min guaranteed 64 kb/sec

6 2 1518 max. Tx burst of 1518 bytes

4 28 class of service configuration setting

1 1 2 service class 2

2 4 5,000,000 max. forward rate of 5 Mb/sec

3 4 300,000 max. return rate of 300 Mb/sec

4 1 3 return path priority of 3

5 4 32,000 min guaranteed 32 kb/sec

6 2 1,518 max. Tx burst of 1518 bytes

Type Length Value

6 16 d1, d2, ... d16

328


C.1.1.6 CMTS Message Integrity Check (MIC) Configuration Setting

The value field contains the CMTS message integrity check code. This is used to detect unauthorizedmodification or corruption of the configuration file.

C.1.1.7 Maximum Number of CPEs

The maximum number of CPEs that can be granted access through a CM during a CM epoch. The CM epoch is(from Section 5.1.2.3.1) the time between startup and hard reset of the modem. The maximum number of CPEsMUST be enforced by the CM.

Note: This parameter should not be confused with the number of CPE addresses a CM may learn. A modem may learnEthernet MAC addresses up to its maximum number of CPE addresses (from Section 5.1.2.3.1). The maximum number ofCPEs that are granted access through the modem is governed by this configuration setting.

The CM MUST interpret this value as an unsigned integer. The non-existence of this option, or the value 0,MUST be interpreted as the default value of 1.

Note: This is a limit on the maximum number of CPEs a CM will grant access to. Hardware limitations of a given modemimplementation may require the modem to use a lower value.

C.1.1.8 TFTP Server Timestamp

The sending time of the configuration file in seconds. The definition of time is as in [RFC-868].

Note: The purpose of this parameter is to prevent replay attacks with old configuration files.

C.1.1.9 TFTP Server Provisioned Modem Address

The IP Address of the modem requesting the configuration file.

Note: The purpose of this parameter is to prevent IP spoofing during registration.

C.1.1.10 Upstream Packet Classification Configuration Setting

This field defines the parameters associated with one entry in an upstream traffic classification list. Refer toSection C.2.1.1.

Type Length Value

7 16 d1, d2, ... d16

Type Length Value

18 1

Type Length Value

19 4 Number of seconds since 00:00 1 Jan 1900

Type Length Value

20 4 IP Address

Type Length Value

22 n

329


C.1.1.11 Downstream Packet Classification Configuration Setting

This field defines the parameters associated with one Classifier in an downstream traffic classification list. Referto Section C.2.1.2.

C.1.1.12 Upstream Service Flow Encodings

This field defines the parameters associated with upstream scheduling for one Service Flow. Refer to SectionC.2.2.1.

C.1.1.13 Downstream Service Flow Encodings

This field defines the parameters associated with downstream scheduling for one Service Flow. Refer to SectionC.2.2.2.

C.1.1.14 Payload Header Suppression

This field defines the parameters associated with Payload Header Suppression.

C.1.1.15 Maximum Number of Classifiers

This is the maximum number of Classifiers associated with admitted or active upstream Service Flows that theCM is allowed to have. Both active and inactive Classifiers are included in the count.

This is useful when using deferred activation of provisioned resources. The number of provisioned ServiceFlows may be high and each Service Flow might support multiple Classifiers. Provisioning represents the set ofService Flows the CM can choose between. The CMTS can control the QoS resources committed to the CM bylimiting the number of Service Flows that are admitted. However, it may still be desirable to limit the number ofClassifiers associated with the committed QoS resources. This parameter provides that limit.

The default value MUST be 0 — no limit.

Type Length Value

23 n

Type Length Value

24 n

Type Length Value

25 n

Type Length Value

26 n

Type Length Value

28 2 Maximum number of active and inactive Classifiers associated withadmitted or active upstream Service Flows

330


C.1.1.16 Privacy Enable

This configuration setting enables/disables Baseline Privacy [DOCSIS8] on the Primary Service Flow and allother Service Flows for this CM. If a DOCSIS 2.0 CM receives this setting in a configuration file, the CM isrequired to forward this setting as part of the registration request (REG-REQ) as specified in Section 8.3.7,regardless of whether the configuration file is DOCSIS 1.1-style or not, while this setting is usually containedonly in a DOCSIS 1.1-style configuration file with DOCSIS 1.1 Service Flow TLVs.

The default value of this parameter MUST be 1 — privacy enabled.

C.1.1.17 Vendor-Specific Information

Vendor-specific information for cable modems, if present, MUST be encoded in the vendor specific informationfield (VSIF) (code 43) using the Vendor ID field (refer to C.1.3.2) to specify which TLV tuples apply to whichvendors products. The Vendor ID MUST be the first TLV embedded inside VSIF. If the first TLV inside VSIF isnot a Vendor ID, then the TLV MUST be discarded.

This configuration setting MAY appear multiple times. The same Vendor ID MAY appear multiple times. Thisconfiguration setting MAY be nested inside a Packet Classification Configuration Setting, a Service FlowConfiguration Setting, or a Service Flow Response. However, there MUST NOT be more than one Vendor IDTLV inside a single VSIF.

Example:

Configuration with vendor A specific fields and vendor B specific fields:

VSIF (43) + n (number of bytes inside this VSIF)8 (Vendor ID Type) + 3 (length field) + Vendor ID of Vendor AVendor A Specific Type #1 + length of the field + Value #1Vendor A Specific Type #2 + length of the field + Value #2

VSIF (43) + m (number of bytes inside this VSIF)8 (Vendor ID Type) + 3 (length field) + Vendor ID of Vendor BVendor B Specific Type + length of the field + Value

C.1.1.18 Subscriber Management TLVs

The information in these TLVs is not used by the CM; rather, the information is used by the CMTS to populatethe Subscriber Management MIB for this CM.

If present in the configuration file, the CM MUST include these TLVs in the subsequent REG-REQ to be used bythe CMTS to populate the Subscriber Management MIB for this CM. If present in the configuration file, the CMMUST include these TLVs in the CMTS MIC.

Type Length Value

29 1 0 — Disable1 — Enable

Type Length Value

43 n per vendor definition

331


C.1.1.18.1 Subscriber Management Control

This three byte field provides control information to the CMTS for the Subscriber Management MIB. The firsttwo bytes represent the number of IP addresses permitted behind the CM. The third byte is used for controlfields.

C.1.1.18.2 Subscriber Management CPE IP Table

This field lists the IP Addresses used to populate docsSubMgtCpeIpTable in the Subscriber Management MIB atthe CMTS.

C.1.1.18.3 Subscriber Management Filter Groups

The Subscriber Management MIB allows filter groups to be assigned to a CM and CPE attached to that CM.These include two CM filter groups, upstream and downstream, and two CPE filter groups, upstream anddownstream. These four filter groups are encoded in the configuration file in a single TLV as follows:

C.1.1.19 Enable 2.0 Mode

This configuration setting enables/disables DOCSIS 2.0 mode for a CM registering with a DOCSIS 2.0 CMTS.

The default value of this parameter MUST be 1 - 2.0 Mode Enabled.

C.1.1.20 Enable Test Modes

This configuration setting enables/disables certain test modes for a CM which supports test modes. Thedefinition of the test modes is beyond the scope of this specification.

If this TLV is not present, the default value MUST be 0 – Test modes disabled.

Type Length Value

35 3 byte 1,2 docsSubMgtCpeControlMaxCpeIP (low-order 10 bits)

byte 3, bit 0: docsSubMgtCpeControlActive

byte 3, bit 1: docsSubMgtCpeControlLearnable

byte 3, bits #2-7: reserved, must be set to zero

Type Length Value

36 N (multiple of 4) Ipa1, Ipa2, Ipa3, Ipa4

Type Length Value

37 8 bytes 1,2: docsSubMgtSubFilterDownstream group

bytes 3,4: docsSubMgtSubFilterUpstream group

bytes 5,6: docsSubMgtCmFilterDownstream group

bytes 7,8: docsSubMgtCmFilterUpstream group

Type Length Value

39 1 0 - Disable

1 - Enable

Type Length Value

40 1 0 – Disable

1 – Enable

332


C.1.2 Configuration-File-Specific Settings

These settings are found in only the configuration file. They MUST NOT be forwarded to the CMTS in theRegistration Request.

C.1.2.1 End-of-Data Marker

This is a special marker for end of data. It has no length or value fields.

C.1.2.2 Pad Configuration Setting

This has no length or value fields and is only used following the end of data marker to pad the file to an integralnumber of 32-bit words.

C.1.2.3 Software Upgrade Filename

The filename of the software upgrade file for the CM. The filename is a fully qualified directory-path name. Thefile is expected to reside on a TFTP server identified in a configuration setting option defined in Section D.2.2.See also Section 12.1.

C.1.2.4 SNMP Write-Access Control

This object makes it possible to disable SNMP “Set” access to individual MIB objects. Each instance of thisobject controls access to all of the writeable MIB objects whose Object ID (OID) prefix matches. This objectmay be repeated to disable access to any number of MIB objects.

Where n is the size of the ASN.1 Basic Encoding Rules [ISO8025] encoding of the OID prefix plus one byte forthe control flag.

The control flag may take values:

0 - allow write-access

1 - disallow write-access

Any OID prefix may be used. The Null OID 0.0 may be used to control access to all MIB objects. (The OID1.3.6.1 will have the same effect.)

Type

255

Type

0

Type Length Value

9 n filename

Type Length Value

10 n OID prefix plus control flag

333


When multiple instances of this object are present and overlap, the longest (most specific) prefix has precedence.Thus, one example might be

someTable: disallow write-accesssomeTable.1.3: allow write-access

This example disallows access to all objects in someTable except for someTable.1.3.

C.1.2.5 SNMP MIB Object

This object allows arbitrary SNMP MIB objects to be Set via the TFTP-Registration process.

The value is an SNMP VarBind as defined in [RFC-1157]. The VarBind is encoded in ASN.1 Basic EncodingRules, just as it would be if part of an SNMP Set request.

The cable modem MUST treat this object as if it were part of an SNMP Set Request with the following caveats:

• It MUST treat the request as fully authorized (it cannot refuse the request for lack of privilege).

• SNMP Write-Control provisions (see previous section) do not apply.

• No SNMP response is generated by the CM.

This object MAY be repeated with different VarBinds to “Set” a number of MIB objects. All such Sets MUST betreated as if simultaneous.

Each VarBind MUST be limited to 255 bytes.

C.1.2.6 CPE Ethernet MAC Address

This object configures the CM with the Ethernet MAC address of a CPE device (see Section 5.1.2.3.1). Thisobject may be repeated to configure any number of CPE device addresses.

C.1.2.7 Software Upgrade TFTP Server

The IP address of the TFTP server, on which the software upgrade file for the CM resides. See Sections 12.1 andC.1.2.3.

C.1.2.8 SnmpV3 Kickstart Value

Compliant CMs MUST understand the following TLV and its sub-elements and be able to kickstart SNMPv3access to the CM regardless of whether the CMs are operating in 1.0 mode or 1.1 mode

Type Length Value

11 n variable binding

Type Length Value

14 6 Ethernet MAC Address of CPE

Type Length Value

21 4 ip1,ip2,ip3,ip4

Type Length Value

34 n Composite

334


Up to 5 of these objects may be included in the configuration file. Each results in an additional row being addedto the usmDHKickstartTable and the usmUserTable and results in an agent public number being generated forthose rows.

C.1.2.8.1 SnmpV3 Kickstart Security Name

For the ASCII character set, the UTF8 and the ASCI I encodings are identical. Normally, this will be specified asone of the Docsis built-in USM users, e.g., “docsisManager,” “docsisOperator,” “docsisMonitor,” “docsisUser.”The security name is NOT zero terminated. This is reported in the usmDHKickStartTable asusmDHKickStartSecurityName and in the usmUserTable as usmUserName and usmUserSecurityName.

C.1.2.8.2 SnmpV3 Kickstart Manager Public Number

This number is the Diffie-Helman public number derived from a privately (by the manager or operator)generated random number and transformed according to [RFC-2786]. This is reported in theusmDHKickStartTable as usmKickstartMgrPublic. When combined with the object reported in the same row asusmKickstartMyPublicit can be used to derive the keys in the related row in the usmUserTable.

C.1.2.9 Manufacturer Code Verification Certificate

The Manufacturer’s Code Verification Certificate (M-CVC) for Secure Software Downloading specified by theappendix D of [DOCSIS8]. The CM config file MUST contain this M-CVC and/or C-CVC defined in SectionC.1.2.10 in order to allow the 1.1-compliant CM to download the code file from the TFTP server whether or notthe CM is provisioned to run with BPI, BPI+, or none of them. See appendix D of [DOCSIS8] for details.

If the length of the M-CVC exceeds 254 bytes, the M-CVC MUST be fragmented into two or more successiveType 32 elements. Each fragment, except the last, MUST be 254 bytes in length. The CM reconstructs the M-CVC by concatenating the contents (Value of the TLV) of successive Type 32 elements in the order in which theyappear in the config file. For example, the first byte following the length field of the second Type 32 element istreated as if it immediately follows the last byte of the first Type 32 element.

C.1.2.10 Co-signer Code Verification Certificate

The Co-signer’s Code Verification Certificate (C-CVC) for Secure Software Downloading specified by theappendix D of [DOCSIS8]. The CM config file MUST contain this C-CVC and/or M-CVC defined in SectionC.1.2.9 in order to allow the 1.1-compliant CM to download the code file from TFTP server whether or not theCM is provisioned to run with BPI, BPI+, or none of them. See [DOCSIS8] appendix D for details.

Type Length Value

34.1 2-16 UTF8 Encoded security name

Type Length Value

34.2 n Manager’s Diffie-Helman public number expressed as an octet string.

Type Length Value

32 n Manufacturer CVC (DER-encoded ASN.1)

Type Length Value

33 n Co-signer CVC (DER-encoded ASN.1)

335


If the length of the C-CVC exceeds 254 bytes, the C-CVC MUST be fragmented into two or more successiveType 33 elements. Each fragment, except the last, MUST be 254 bytes in length. The CM reconstructs the C-CVC by concatenating the contents (Value of the TLV) of successive Type 33 elements in the order in whichthey appear in the config file. For example, the first byte following the length field of the second Type 33element is treated as if it immediately follows the last byte of the first Type 33 element.

C.1.2.11 SNMPv3 Notification Receiver

This TLV specifies a Network Management Station that will receive notifications from the modem when it is inCoexistence mode. Up to 10 of these elements may be included in the configuration file.

C.1.2.11.1 SNMPv3 Notification Receiver IP Address

This sub-TLV specifies the IP address of the notification receiver.

C.1.2.11.2 SNMPv3 Notification Receiver UDP Port Number

This sub-TLV specifies the UDP port number of the notification receiver. If this sub-TLV is not present, thedefault value of 162 should be used.

C.1.2.11.3 SNMPv3 Notification Receiver Trap Type

This sub-TLV specifies the type of trap to send. The trap type may take values:

1 = SNMP v1 trap in an SNMP v1 packet2 = SNMP v2c trap in an SNMP v2c packet3 = SNMP inform in an SNMP v2c packet4 = SNMP v2c trap in an SNMP v3 packet5 = SNMP inform in an SNMP v3 packet

C.1.2.11.4 SNMPv3 Notification Receiver Timeout

This sub-TLV specifies the timeout value to use when sending an Inform message to the notification receiver.

Type Length Value

38 n composite

Type Length Value

38.1 4 ip1, ip2, ip3, ip4

Type Length Value

38.2 2 UDP port number

Type Length Value

38.3 2 trap type

Type Length Value

38.4 2 time in milliseconds

336


C.1.2.11.5 SNMPv3 Notification Receiver Retries

This sub-TLV specifies the number of times to retry sending an Inform message if an acknowledgement is notreceived.

C.1.2.11.6 SNMPv3 Notification Receiver Filtering Parameters

This sub-TLV specifies the ASN.1 formatted Object Identifier of the snmpTrapOID value that identifies thenotifications to be sent to the notification receiver. SNMP V3 allows the specification of which Trap OIDs are tobe sent to a trap receiver. This object specifies the OID of the root of a trap filter sub-tree. All Traps with a TrapOID contained in this trap filter sub-tree MUST be sent to the trap receiver. This object starts with the ASN.1Universal type 6 (Object Identifier) byte, then the ASN.1 length field, then the ASN.1 encoded object identifiercomponents.

C.1.2.11.7 SNMPv3 Notification Receiver Security Name

This sub-TLV specifies the V3 Security Name to use when sending a V3 Notification. This sub-TLV is only usedif Trap Type is set to 4 or 5. This name must be a name specified in a config file TLV Type 34 as part of the DHKickstart procedure. The notifications will be sent using the Authentication and Privacy Keys calculated by themodem during the DH Kickstart procedure.

This sub-TLV is not required for Trap Type = 1, 2, or 3 above. If it is not supplied for a Trap type of 4 or 5, thenthe V3 Notification will be sent in the noAuthNoPriv security level using the security name “@config”.

C.1.3 Registration-Request/Response-Specific Encodings

These encodings are not found in the configuration file, but are included in the Registration Request and option60 of the DHCP request. Some encodings are also used in the Registration Response.

The CM MUST include all Modem Capabilities Encodings that are subject to negotiation with the CMTS in itsRegistration Request. Modem Capabilities Encodings that are not subject to negotiation with the CMTS areexplicitly stated in the description of the particular modem capability. The CMTS MUST include ModemCapabilities in the Registration Response.

C.1.3.1 Modem Capabilities Encoding

The value field describes the capabilities of a particular modem, i.e., implementation dependent limits on theparticular features or number of features which the modem can support. It is composed from a number ofencapsulated type/length/value fields. The encapsulated sub-types define the specific capabilities for the modemin question. Note that the sub-type fields defined are only valid within the encapsulated capabilities configurationsetting string.

Type Length Value

38.5 2 number of retries

Type Length Value

38.6 n filter OID

Type Length Value

38.7 n security name

Type Length Value

5 n

337


The set of possible encapsulated fields is described below.

All these capabilities are to be included in both the registration request and option 60 of the DHCP request unlessthe description of the capability explicitly prohibits this.

C.1.3.1.1 Concatenation Support

If the value field is a 1 the CM requests concatenation support from the CMTS.

C.1.3.1.2 DOCSIS Version

DOCSIS version of this modem.

If this tuple is absent, the CMTS MUST assume DOCSIS v1.0 operation. The absence of this tuple or the value‘DOCSIS 1.0’ does not necessarily mean the CM only supports DOCSIS 1.0 functionality — the CM MAYindicate it supports other individual capabilities with other Modem Capability Encodings. (Refer to G.2). Thiscapability is provided by the CM for the benefit of the CMTS, the operation of the CM is not affected by thevalue returned by the CMTS.

C.1.3.1.3 Fragmentation Support

If the value field is a 1 the CM requests fragmentation support from the CMTS.

C.1.3.1.4 Payload Header Suppression Support

If the value field is a 1 the CM requests payload header suppression support from the CMTS.

C.1.3.1.5 IGMP Support

If the value field is a 1 the CM supports DOCSIS 1.1-compliant IGMP.

Note: This CM capability is not subject to negotiation with the CMTS. The CM MUST include this capability in the DHCPrequest, but MUST NOT include this capability in the registration request. If a CMTS does receive this capability with in aregistration request it MUST return the capability with the same value in the registration response.

Type Length On / Off

5.1 1 1 or 0

Type Length Value

5.2 1 0: DOCSIS v1.0

1: DOCSIS v1.1

2: DOCSIS v2.0

3-255: Reserved

Type Length Value

5.3 1 1 or 0

Type Length Value

5.4 1 1 or 0

Type Length Value

5.5 1 1 or 0

338


C.1.3.1.6 Privacy Support

The value indicates the BPI support of the CM.

C.1.3.1.7 Downstream SAID Support

This field shows the number of Downstream SAIDs the modem can support.

If the number of SAIDs is 0, the Modem can support only 1 SAID.

C.1.3.1.8 Upstream SID Support

This field shows the number of Upstream SIDs the modem can support.

If the number of SIDs is 0 that means the Modem can support only 1 SID.

C.1.3.1.9 Optional Filtering Support

This field shows the optional filtering support in the modem.

Note: This CM capability is not subject to negotiation with the CMTS. The CM MUST include this capability in the DHCPrequest, but MUST NOT include this capability in the registration request. If a CMTS does receive this capability with in aregistration request it MUST return the capability with the same value in the registration response.

C.1.3.1.10 Transmit Equalizer Taps per Modulation Interval

This field shows the maximal number of pre-equalizer taps per modulation interval T supported by the CM.

Note: All CMs MUST support T-spaced equalizer coefficients. CM support of 2 or 4 taps per modulation interval is optional. Ifthis tuple is missing, it is implied that the CM only supports T spaced equalizer coefficients. A CM MUST include this capability inthe registration request and its value MUST be 1.

Type Length Value

5.6 1 0: BPI Support

1: BPI Plus Support

2 - 255: Reserved

Type Length Value

5.7 1 Number of Downstream SAIDs the CM can support.

Type Length Value

5.8 1 Number of Upstream SIDs the CM can support.

Type Length Value

5.9 1 Packet Filtering Support Array

bit #0: 802.1P filtering

bit #1: 802.1Q filtering

bit #2-7: reserved, MUST be set to zero

Type Length Value

5.10 1 1, 2 or 4

339


C.1.3.1.11 Number of Transmit Equalizer Taps

This field shows the number of equalizer taps that are supported by the CM

Note: All CMs MUST support an equalizer length of at least 8 symbols. CM support of up to 64 T-spaced, T/2-spaced or T/4-spaced taps is optional. If this tuple is missing, it is implied that the CM only supports an equalizer length of 8 taps. A CM MUSTinclude this capability in the registration request and its value MUST be 24.

C.1.3.1.12 DCC Support

The value is the DCC support of the CM.

C.1.3.2 Vendor ID Encoding

The value field contains the vendor identification specified by the three-byte vendor-specific OrganizationUnique Identifier of the CM MAC address.

The Vendor ID MUST be used in a Registration Request, but MUST NOT be used as a stand-alone configurationfile element. It MAY be used as a sub-field of the Vendor Specific Information Field in a configuration file.When used as a sub-field of the Vendor Specific Information field, this identifies the Vendor ID of the CMswhich are intended to use this information. When the vendor ID is used in a Registration Request, then it is theVendor ID of the CM sending the request.

C.1.3.3 Modem IP Address

For backwards compatibility with DOCSIS v 1.0. Replaced by ‘TFTP Server Provisioned Modem Address’.

C.1.3.4 Service(s) Not Available Response

This configuration setting MUST be included in the Registration Response message if the CMTS is unable orunwilling to grant any of the requested classes of service that appeared in the Registration Request. Although thevalue applies only to the failed service class, the entire Registration Request MUST be considered to have failed(none of the class-of-service configuration settings are granted).

Class ID is the class-of-service class from the request which is not available

Type is the specific class-of-service object within the class which caused the request to be rejected

Type Length Value

5.11 1 8 to 64

Type Length Value

5.12 1 0 = DCC is not supported

1 = DCC is supported

Type Length Value

8 3 v1, v2, v3

Type Length Value

12 4 IP Address

Type Length Value

13 3 Class ID, Type, Confirmation Code

340


Confirmation Code (Refer to Section C.4, “Confirmation Code,” on page 367.)

C.1.3.5 Vendor-Specific Capabilities

Vendor-specific data about the CM, that is to be included in the REG-REQ, but which is not part of theconfiguration file, if present, MUST be encoded in the vendor specific capabilities (VSC) (code 44) using theVendor ID field (refer to C.1.3.2) to specify which TLV tuples apply to which vendors products. The Vendor IDMUST be the first TLV embedded inside VSC. If the first TLV inside VSIF is not a Vendor ID, then the TLVMUST be discarded.

This configuration setting MAY appear multiple times. The same Vendor ID MAY appear multiple times. ThereMUST NOT be more than one Vendor ID TLV inside a single VSC.

Example:

Configuration with vendor A specific fields and vendor B specific fields:

VSC (44) + n (number of bytes inside this VSC)8 (Vendor ID Type) + 3 (length field) + Vendor ID of VendorVendor Specific Type #1 + length of the field + Value #1Vendor Specific Type #2 + length of the field + Value #2

C.1.4 Dynamic-Service-Message-Specific Encodings

These encodings are not found in the configuration file, nor in the Registration Request/Response signaling.They are only found in DSA-REQ, DSA-RSP, DSA-ACK, DSC-REQ, DSC-RSP, DSC-ACK, and DSD-REQmessages (sections 8.3.12 through 8.3.18).

C.1.4.1 HMAC-Digest

The HMAC-Digest setting is a keyed message digest. If privacy is enabled, the HMAC-Digest Attribute MUSTbe the final Attribute in the Dynamic Service message’s Attribute list. The message digest is performed over theall of the Dynamic Service parameters (starting immediately after the MAC Management Message Header andup to, but not including the HMAC Digest setting), other than the HMAC-Digest, in the order in which theyappear within the packet.

Inclusion of the keyed digest allows the receiver to authenticate the message. The HMAC-Digest algorithm, andthe upstream and downstream key generation requirements are documented in [DOCSIS8].

This parameter contains a keyed hash used for message authentication. The HMAC algorithm is defined in[RFC2104]. The HMAC algorithm is specified using a generic cryptographic hash algorithm. Baseline Privacyuses a particular version of HMAC that employs the Secure Hash Algorithm (SHA-1), defined in [SHA].

A summary of the HMAC-Digest Attribute format is shown below. The fields are transmitted from left to right.

Type Length Value

44 n per vendor definition

Type Length Value

27 20 A 160-bit (20-octet) keyed SHA hash

341


C.1.4.2 Authorization Block

The Authorization Block contains an authorization "hint". The specifics of the contents of this "hint" are beyondthe scope of this specification, but include [PKT-DQOS].

The Authorization Block MAY be present in CM-initiated DSA-REQ and DSC-REQ messages, and CMTS-initiated DSA-RSP and DSC-RSP messages. This parameter MUST NOT be present in CMTS-initiated DSA-REQ and DSC-REQ messages, nor CM-initiated DSA-RSP and DSC-RSP messages.

The Authorization Block information applies to the entire content of the message. Thus, only a singleAuthorization Block per message MAY be present. The Authorization Block, if present, MUST be passed to theAuthorization Module in the CMTS. The Authorization Block information is only processed by theAuthorization Module.

C.1.4.3 Key Sequence Number

The value shows the key sequence number of the BPI+ Authorization Key which is used to calculate the HMAC-Digest in case that the Privacy is enabled.

C.2 Quality-of-Service-Related Encodings

C.2.1 Packet Classification Encodings

The following type/length/value encodings MUST be used in both the configuration file, registration messages,and Dynamic Service messages to encode parameters for packet classification and scheduling. All multi-octetquantities are in network-byte order, i.e., the octet containing the most-significant bits is the first transmitted onthe wire.

A classifier MUST contain at least one encoding from Section C.2.1.5, “IP Packet Classification Encodings,” onpage 346, Section C.2.1.6, “Ethernet LLC Packet Classification Encodings,” on page 348, or Section C.2.1.7,“IEEE 802.1P/Q Packet Classification Encodings,” on page 349.

The following configuration settings MUST be supported by all CMs which are compliant with thisspecification. All CMTSes MUST support classification of downstream packets based on IP header fields(Section C.2.1.5).

C.2.1.1 Upstream Packet Classification Encoding

This field defines the parameters associated with an upstream Classifier.

Note that the same subtype fields defined are valid for both the encapsulated upstream and downstream packetclassification configuration setting string. These type fields are not valid in other encoding contexts.

Type Length Value

30 n Sequence of n octets

Type Length Value

31 1 Auth Key Sequence Number (0 - 15)

Type Length Value

22 n

342


C.2.1.2 Downstream Packet Classification Encoding

This field defines the parameters associated with a downstream Classifier.

Note that the same subtype fields defined are valid for both the encapsulated upstream and downstream flowclassification configuration setting string. These type fields are not valid in other encoding contexts.

C.2.1.3 General Packet Classifier Encodings

C.2.1.3.1 Classifier Reference

The value of the field specifies a reference for the Classifier. This value is unique per Dynamic Service message,configuration file, or Registration Request message.

C.2.1.3.2 Classifier Identifier

The value of the field specifies an identifier for the Classifier. This value is unique to per Service Flow. TheCMTS assigns the Packet Classifier Identifier.

C.2.1.3.3 Service Flow Reference

The value of the field specifies a Service Flow Reference that identifies the corresponding Service Flow.

In all Packet Classifier TLVs that occur in any message where the Service Flow ID is not known (e.g., CM-initiated DSA-REQ and REG-REQ) this TLV MUST be included. In all Packet Classifier TLVs that occur in aDSC-REQ and CMTS-initiated DSA-REQ messages the Service Flow Reference MUST NOT be specified.

C.2.1.3.4 Service Flow Identifier

The value of this field specifies the Service Flow ID that identifies the corresponding Service Flow.

In Packet Classifier TLVs where the Service Flow ID is not known, and this TLV MUST NOT be included (e.g.,CM-initiated DSA-REQ and REG-REQ). In Packet Classifier TLVs that occur in a DSC-REQ and CMTS-initiated DSA-REQ message, the Service Flow ID MUST be specified.

Type Length Value

23 n

Type Length Value

[22/23].1 1 1 - 255

Type Length Value

[22/23].2 2 1 - 65535

Type Length Value

[22/23].3 2 1 - 65535

Type Length Value

[22/23].4 4 1 - 4,294,967,295

343


C.2.1.3.5 Rule Priority

The value of the field specifies the priority for the Classifier, which is used for determining the order of theClassifier. A higher value indicates higher priority.

Classifiers that appear in Configuration files and Registration messages MAY have priorities in the range 0 - 255with the default value 0. Classifiers that appear in DSA/DSC message MUST have priorities in the range 64-191,with the default value 64.

C.2.1.3.6 Classifier Activation State

The value of this field specifies whether this classifier should become active in selecting packets for the ServiceFlow. An inactive Classifier is typically used with an AdmittedQoSParameterSet to ensure resources areavailable for later activation. The actual activation of the classifier depends both on this attribute and on the stateof its service flow. If the service flow is not active then the classifier is not used, regardless of the setting of thisattribute.

The default value is 1 — activate the classifier.

C.2.1.3.7 Dynamic Service Change Action

When received in a Dynamic Service Change Request, this indicates the action that should be taken with thisclassifier.

C.2.1.4 Classifier Error Encodings

This field defines the parameters associated with Classifier Errors.

A Classifier Error Encoding consists of a single Classifier Error Parameter Set which is defined by the followingindividual parameters: Errored Parameter, Confirmation Code and Error Message.

The Classifier Error Encoding is returned in REG-RSP, DSA-RSP and DSC-RSP messages to indicate the reasonfor the recipient’s negative response to a Classifier establishment request in a REG-REQ, DSA-REQ or DSC-REQ message.

On failure, the REG-RSP, DSA-RSP or DSC-RSP MUST include one Classifier Error Encoding for at least onefailed Classifier requested in the REG-REQ, DSA-REQ or DSC-REQ message. A Classifier Error Encoding forthe failed Classifier MUST include the Confirmation Code and Errored Parameter and MAY include an Error

Type Length Value

[22/23].5 1

Type Length Value

[22/23].6 1 0 — Inactive

1 — Active

Type Length Value

[22/23].7 1 0 — DSC Add Classifier

1 — DSC Replace Classifier

2 — DSC Delete Classifier

Type Length Value

[22/23].8 n

344


Message. If some Classifier Sets are rejected but other Classifier Sets are accepted, then Classifier ErrorEncodings MUST be included for only the rejected Classifiers. On success of the entire transaction, the RSP orACK message MUST NOT include a Classifier Error Encoding.

Multiple Classifier Error Encodings may appear in a REG-RSP, DSA-RSP or DSC-RSP message, since multipleClassifier parameters may be in error. A message with even a single Classifier Error Encoding MUST NOTcontain any other protocol Classifier Encodings (e.g. IP, 802.1P/Q).

A Classifier Error Encoding MUST NOT appear in any REG-REQ, DSA-REQ or DSC-REQ messages.

C.2.1.4.1 Errored Parameter

The value of this parameter identifies the subtype of a requested Classifier parameter in error in a rejectedClassifier request. A Classifier Error Parameter Set MUST have exactly one Errored Parameter TLV within agiven Classifier Error Encoding.

If the length is one, then the value is the single-level subtype where the error was found, e.g., 7 indicates aninvalid Change Action. If the length is two, then the value is the multi-level subtype where there error was founde.g., 9-2 indicates an invalid IP Protocol value.

C.2.1.4.2 Error Code

This parameter indicates the status of the request. A non-zero value corresponds to the Confirmation Code asdescribed in C.4. A Classifier Error Parameter Set MUST have exactly one Error Code within a given ClassifierError Encoding.

A value of okay (0) indicates that the Classifier request was successful. Since a Classifier Error Parameter Setapplies only to errored parameters, this value MUST NOT be used.

C.2.1.4.3 Error Message

This subtype is optional in a Classifier Error Parameter Set. If present, it indicates a text string to be displayed onthe CM console and/or log that further describes a rejected Classifier request. A Classifier Error Parameter SetMAY have zero or one Error Message subtypes within a given Classifier Error Encoding.

Note: The length N includes the terminating zero.

Note: The entire Classifier Encoding message MUST have a total length of less than 256 characters.


[22/23].8.1 n Classifier Encoding Subtype in Error


[22/23].8.2 1 Confirmation code

SubType Length Value

[22/23].8.3 n Zero-terminated string of ASCII characters.

345


C.2.1.5 IP Packet Classification Encodings

This field defines the parameters associated with IP packet classification.

C.2.1.5.1 IP Type of Service Range and Mask

The values of the field specify the matching parameters for the IP ToS byte range and mask. An IP packet with IPToS byte value “ip-tos” matches this parameter if tos-low <= (ip-tos AND tos-mask) <= tos-high. If this field isomitted, then comparison of the IP packet ToS byte for this entry is irrelevant.

C.2.1.5.2 IP Protocol

The value of the field specifies the matching value for the IP Protocol field [RFC-1700]. If this parameter isomitted, then comparison of the IP header Protocol field for this entry is irrelevant.

There are two special IP Protocol field values: “256” matches traffic with any IP Protocol value, and “257”matches both TCP and UDP traffic. An entry that includes an IP Protocol field value greater than 257 MUST beinvalidated for comparisons (i.e., no traffic can match this entry).

Valid Range: 0 - 257

C.2.1.5.3 IP Source Address

The value of the field specifies the matching value for the IP source address. An IP packet with IP source address“ip-src” matches this parameter if src = (ip-src AND smask), where “smask” is the parameter from C.2.1.5.4. Ifthis parameter is omitted, then comparison of the IP packet source address for this entry is irrelevant.

C.2.1.5.4 IP Source Mask

The value of the field specifies the mask value for the IP source address, as described in C.2.1.5.3. If thisparameter is omitted, then the default IP source mask is 255.255.255.255.

C.2.1.5.5 IP Destination Address

The value of the field specifies the matching value for the IP destination address. An IP packet with IPdestination address “ip-dst” matches this parameter if dst = (ip-dst AND dmask), where “dmask” is the parameter

Type Length Value

[22/23].9 n

Type Length Value

[22/23].9.1 3 tos-low, tos-high, tos-mask

Type Length Value

[22/23].9.2 2 prot1, prot2

Type Length Value

[22/23].9.3 4 src1, src2, src3, src4

Type Length Value

[22/23].9.4 4 smask1, smask2, smask3, smask4

346


from C.2.1.5.6. If this parameter is omitted, then comparison of the IP packet destination address for this entry isirrelevant.

C.2.1.5.6 IP Destination Mask

The value of the field specifies the mask value for the IP destination address, as described in Section C.2.1.5.5,“IP Destination Address,” on page 346. If this parameter is omitted, then the default IP destination mask is255.255.255.255.

C.2.1.5.7 TCP/UDP Source Port Start

The value of the field specifies the low-end TCP/UDP source port value. An IP packet with TCP/UDP port value“src-port” matches this parameter if sportlow <= src-port <= sporthigh. If this parameter is omitted, then thedefault value of sportlow is 0. This parameter is irrelevant for non-TCP/UDP IP traffic.

C.2.1.5.8 TCP/UDP Source Port End

The value of the field specifies the high-end TCP/UDP source port value. An IP packet with TCP/UDP portvalue “src-port” matches this parameter if sportlow <= src-port <= sporthigh. If this parameter is omitted, thenthe default value of sporthigh is 65535. This parameter is irrelevant for non-TCP/UDP IP traffic.

C.2.1.5.9 TCP/UDP Destination Port Start

The value of the field specifies the low-end TCP/UDP destination port value. An IP packet with TCP/UDP portvalue “dst-port” matches this parameter if dportlow <= dst-port <=dporthigh. If this parameter is omitted, thenthe default value of dportlow is 0. This parameter is irrelevant for non-TCP/UDP IP traffic.

C.2.1.5.10 TCP/UDP Destination Port End

The value of the field specifies the high-end TCP/UDP destination port value. An IP packet with TCP/UDP portvalue “dst-port” matches this parameter if dportlow <= dst-port <= dporthigh. If this parameter is omitted, thenthe default value of dporthigh is 65535. This parameter is irrelevant for non-TCP/UDP IP traffic.

Type Length Value

[22/23].9.5 4 dst1, dst2, dst3, dst4

Type Length Value

[22/23].9.6 4 dmask1, dmask2, dmask3, dmask4

Type Length Value

[22/23].9.7 2 sportlow1, sportlow2

Type Length Value

[22/23].9.8 2 sporthigh1, sporthigh2

Type Length Value

[22/23].9.9 2 dportlow1, dportlow2

Type Length Value

[22/23].9.10 2 dporthigh1, dporthigh2

347


C.2.1.6 Ethernet LLC Packet Classification Encodings

This field defines the parameters associated with Ethernet LLC packet classification.

C.2.1.6.1 Destination MAC Address

The values of the field specifies the matching parameters for the MAC destination address. An Ethernet packetwith MAC destination address “etherdst” matches this parameter if dst = (etherdst AND msk). If this parameteris omitted, then comparison of the Ethernet MAC destination address for this entry is irrelevant.

C.2.1.6.2 Source MAC Address

The value of the field specifies the matching value for the MAC source address. If this parameter is omitted, thencomparison of the Ethernet MAC source address for this entry is irrelevant.

C.2.1.6.3 Ethertype/DSAP/MacType

Type, eprot1, and eprot2 indicate the format of the layer 3 protocol ID in the Ethernet packet as follows:

If type = 0, the rule does not use the layer 3 protocol type as a matching criterion. If type = 0, eprot1, eprot2 areignored when considering whether a packet matches the current rule.

If type = 1, the rule applies only to frames which contain an Ethertype value. Ethertype values are contained inpackets using the DEC-Intel-Xerox (DIX) encapsulation or the RFC1042 Sub-Network Access Protocol (SNAP)encapsulation formats. If type = 1, then eprot1, eprot2 gives the 16-bit value of the Ethertype that the packet mustmatch in order to match the rule

If type = 2, the rule applies only to frames using the IEEE 802.2 encapsulation format with a Destination Service(DSAP) other than 0xAA (which is reserved for SNAP). If type = 2, the lower 8 bits of the eprot1, eprot2, MUSTmatch the DSAP byte of the packet in order to match the rule.

If type = 3, the rule applies only to MAC Management Messages (FC field 1100001x) with a “type” field of itsMAC Management Message header (6.3.1) between the values of eprot1 and eprot2, inclusive. As exceptions,the following MAC Management message types MUST NOT be classified, and are always transmitted on theprimary service flow:

Type 4: RNG_REQType 6: REG_REQType 7: REG_RSPType 14: REG_ACK

If type = 4, the rule is considered a “catch-all” rule that matches all Data PDU packets. The rule does not matchMAC Management Messages. The value of eprot1 and eprot2 are ignored in this case.

Type Length Value

[22/23].10 n

Type Length Value

[22/23].10.1 12 dst1, dst2, dst3, dst4, dst5, dst6, msk1, msk2, msk3, msk4, msk5, msk6

Type Length Value

[22/23].10.2 6 src1, src2, src3, src4, src5, src6

348


If the Ethernet frame contains an 802.1P/Q Tag header (i.e., Ethertype 0x8100), this object applies to theembedded Ethertype field within the 802.1P/Q header.

Other values of type are reserved. If this TLV is omitted, then comparison of either the Ethertype or IEEE 802.2DSAP for this rule is irrelevant.

C.2.1.7 IEEE 802.1P/Q Packet Classification Encodings

This field defines the parameters associated with IEEE 802.1P/Q packet classification.

C.2.1.7.1 IEEE 802.1P User_Priority

The values of the field specify the matching parameters for the IEEE 802.1P user_priority bits. An Ethernetpacket with IEEE 802.1P user_priority value “priority” matches these parameters if pri-low <= priority <= pri-high. If this field is omitted, then comparison of the IEEE 802.1P user_priority bits for this entry is irrelevant.

If this parameter is specified for an entry, then Ethernet packets without IEEE 802.1Q encapsulation MUST NOTmatch this entry. If this parameter is specified for an entry on a CM that does not support forwarding of IEEE802.1Q encapsulated traffic, then this entry MUST NOT be used for any traffic.

Valid Range is 0 – 7 for pri-low and pri-high

C.2.1.7.2 IEEE 802.1Q VLAN_ID

The value of the field specify the matching value for the IEEE 802.1Q vlan_id bits. Only the first (i.e., most-significant) 12 bits of the specified vlan_id field are significant; the final four bits MUST be ignored forcomparison. If this field is omitted, then comparison of the IEEE 802.1Q vlan_id bits for this entry is irrelevant.

If this parameter is specified for an entry, then Ethernet packets without IEEE 802.1Q encapsulation MUST NOTmatch this entry. If this parameter is specified for an entry on a CM that does not support forwarding of IEEE802.1Q encapsulated traffic, then this entry MUST NOT be used for any traffic.

C.2.1.7.3 Vendor Specific Classifier Parameters

This allows vendors to encode vendor-specific Classifier parameters. The Vendor ID MUST be the first TLVembedded inside Vendor Specific Classifier Parameters. If the first TLV inside Vendor Specific ClassifierParameters is not a Vendor ID, then the TLV MUST be discarded. (Refer to Section C.1.1.17)

Type Length Value

[22/23].10.3 3 type, eprot1, eprot2

Type Length Value

[22/23].11 n

Type Length Value

[22/23].11.1 2 pri-low, pri-high

Type Length Value

[22/23].11.2 2 vlan_id1, vlan_id2

Type Length Value

[22/23].43 n

349


C.2.2 Service Flow Encodings

The following type/length/value encodings MUST be used in the configuration file, registration messages, andDynamic Service messages to encode parameters for Service Flows. All multi-octet quantities are in network-byte order, i.e., the octet containing the most-significant bits is the first transmitted on the wire.

The following configuration settings MUST be supported by all CMs which are compliant with thisspecification.

C.2.2.1 Upstream Service Flow Encodings

This field defines the parameters associated with upstream scheduling for a Service Flow. It is somewhatcomplex in that is composed from a number of encapsulated type/length/value fields.

Note that the encapsulated upstream and downstream Service Flow configuration setting strings share the samesubtype field numbering plan, because many of the subtype fields defined are valid for both types ofconfiguration settings. These type fields are not valid in other encoding contexts.

C.2.2.2 Downstream Service Flow Encodings

This field defines the parameters associated with downstream scheduling for a Service Flow. It is somewhatcomplex in that is composed from a number of encapsulated type/length/value fields.

Note that the encapsulated upstream and downstream flow classification configuration setting strings share thesame subtype field numbering plan, because many of the subtype fields defined are valid for both types ofconfiguration settings except Service Flow encodings. These type fields are not valid in other encoding contexts.

C.2.2.3 General Service Flow Encodings


The Service Flow Reference is used to associate a packet classifier encoding with a Service Flow encoding. AService Flow Reference is only used to establish a Service Flow ID. Once the Service Flow exists and has anassigned Service Flow ID, the Service Flow Reference MUST no longer be used. The Service Flow Reference isunique per configuration file, Registration message exchange, or Dynamic Service Add message exchange.


The Service Flow Identifier is used by the CMTS as the primary reference of a Service Flow. Only the CMTScan issue a Service Flow Identifier. It uses this parameterization to issue Service Flow Identifiers in CMTS-initiated DSA-Requests and in its REG/DSA-Response to CM-initiated REG/DSA-Requests. The CM specifiesthe SFID of a service flow using this parameter in a DSC-REQ message. Both the CM and CMTS MAY use thisTLV to encode Service Flow IDs in a DSD-REQ.

Type Length Value

24 n

Type Length Value

25 n

Type Length Value

[24/25].1 2 1 - 65535

350


The configuration file MUST NOT contain this parameter.

C.2.2.3.3 Service Identifier

The value of this field specifies the Service Identifier assigned by the CMTS to a Service Flow with a non-nullAdmittedQosParameterSet or ActiveQosParameterSet. This is used in the bandwidth allocation MAP to assignupstream bandwidth. This field MUST be present in CMTS-initiated DSA-REQ or DSC-REQ message related toestablishing an admitted or active upstream Service Flow. This field MUST also be present in REG-RSP, DSA-RSP and DSC-RSP messages related to the successful establishment of an admitted or active upstream ServiceFlow.

Even though a Service Flow has been successfully admitted or activated (i.e., has an assigned Service ID) theService Flow ID MUST be used for subsequent DSx message signalling as it is the primary handle for a serviceflow. If a Service Flow is no longer admitted or active (via DSC-REQ) its Service ID MAY be reassigned by theCMTS.

C.2.2.3.4 Service Class Name

The value of the field refers to a predefined CMTS service configuration to be used for this Service Flow.

Note: The length includes the terminating zero.

When the Service Class Name is used in a Service Flow encoding, it indicates that all the unspecified QoSParameters of the Service Flow need to be provided by the CMTS. It is up to the operator to synchronize thedefinition of Service Class Names in the CMTS and in the configuration file.

C.2.2.3.5 Quality of Service Parameter Set Type

This parameter MUST appear within every Service Flow Encoding, with the exception of Service FlowEncodings in the DSD-REQ where the Quality of Service Parameter Set Type has no value. It specifies theproper application of the QoS Parameter Set or Service Class Name: to the Provisioned set, the Admitted set,and/or the Active set. When two QoS Parameter Sets are the same, a multi-bit value of this parameter MAY beused to apply the QoS parameters to more than one set. A single message MAY contain multiple QoS parametersets in separate type 24/25 Service Flow Encodings for the same Service Flow. This allows specification of theQoS Parameter Sets when their parameters are different. Bit 0 is the LSB of the Value field.

For every Service Flow that appears in a Registration-Request or Registration-Response message, there MUSTbe a Service Flow Encoding that specifies a ProvisionedQoSParameterSet. This Service Flow Encoding, or otherService Flow Encoding(s), MAY also specify an Admitted and/or Active set.

Type Length Value

[24/25].2 4 1 - 4,294,967,295


[24/25].3 2 SID (low-order 14 bits)

Type Length Value

[24/25].4 2 to 16 Zero-terminated string of ASCII characters.

351


Any Service Flow Encoding that appears in a Dynamic Service Message MUST NOT specify theProvisionedQoSParameterSet.

Table C-2 Values Used in REG-REQ and REG-RSP Messages

Table C-3 Values Used In REG-REQ, REG-RSP, and Dynamic Service Messages

The value 000 is used only in Dynamic Service Change messages. It is used to set the Active and Admitted setsto Null (see Section 10.1.7.4, “Dynamic Service Flow Modification and Deletion,” on page 213).

A CMTS MUST handle a single update to each of the Active and Admitted QoS parameter sets. The ability toprocess multiple Service Flow Encodings that specify the same QoS parameter set is NOT required, and is left asa vendor-specific function. If a DSA/DSC contains multiple updates to a single QoS parameter set and thevendor does not support such updates, then the CMTS MUST reply with error code 2, reject-unrecognized-configuration-setting.

C.2.2.4 Service Flow Error Encodings

This field defines the parameters associated with Service Flow Errors.

A Service Flow Error Encoding consists of a single Service Flow Error Parameter Set which is defined by thefollowing individual parameters: Errored Parameter, Confirmation Code and Error Message.

The Service Flow Error Encoding is returned in REG-RSP, DSA-RSP and DSC-RSP messages to indicate thereason for the recipient’s negative response to a Service Flow establishment request in a REG-REQ, DSA-REQor DSC-REQ message.

The Service Flow Error Encoding is returned in REG-ACK, DSA-ACK and DSC-ACK messages to indicate thereason for the recipient’s negative response to the expansion of a Service Class Name in a corresponding REG-RSP, DSA-RSP or DSC-RSP.

Type Length Value

[24/25].6 1 Bit # 0 Provisioned Set

Bit # 1 Admitted Set

Bit # 2 Active Set

Value Messages

001 Apply to Provisioned set only

011 Apply to Provisioned and Admitted set, and perform admission control

101 Apply to Provisioned and Active sets, perform admission control on Admittedset in separate Service Flow Encoding, and activate the Service flow.

111 Apply to Provisioned, Admitted, and Active sets; perform admission controland activate this Service Flow

Value Messages

010 Perform admission control and apply to Admitted set

100 Check against Admitted set in separate Service flow Encoding, performadmission control if needed, activate this Service Flow, and apply to Active set

110 Perform admission control and activate this Service Flow, apply parameters toboth Admitted and Active sets

Type Length Value

[24/25].5 n

352


On failure, the REG-RSP, DSA-RSP or DSC-RSP MUST include one Service Flow Error Encoding for at leastone failed Service Flow requested in the REG-REQ, DSA-REQ or DSC-REQ message. On failure, the REG-ACK, DSA-ACK or DSC-ACK MUST include one Service Flow Error Encoding for at least one failed ServiceClass Name expansion in the REG-RSP, DSA-RSP or DSC-RSP message. A Service Flow Error Encoding forthe failed Service Flow MUST include the Confirmation Code and Errored Parameter and MAY include an ErrorMessage. If some Service Flow Parameter Sets are rejected but other Service Flow Parameter Sets are accepted,then Service Flow Error Encodings MUST be included for only the rejected Service Flow.

On success of the entire transaction, the RSP or ACK message MUST NOT include a Service Flow ErrorEncoding.

Multiple Service Flow Error Encodings MAY appear in a REG-RSP, DSA-RSP, DSC-RSP, REG-ACK, DSA-ACK or DSC-ACK message, since multiple Service Flow parameters may be in error. A message with even asingle Service Flow Error Encoding MUST NOT contain any QoS Parameters.

A Service Flow Error Encoding MUST NOT appear in any REG-REQ, DSA-REQ or DSC-REQ messages.


The value of this parameter identifies the subtype of a requested Service Flow parameter in error in a rejectedService Flow request or Service Class Name expansion response.A Service Flow Error Parameter Set MUSThave exactly one Errored Parameter TLV within a given Service Flow Error Encoding.


This parameter indicates the status of the request. A non-zero value corresponds to the Confirmation Code asdescribed in C.4. A Service Flow Error Parameter Set MUST have exactly one Error Code within a given ServiceFlow Error Encoding.

A value of okay(0) indicates that the Service Flow request was successful. Since a Service Flow Error ParameterSet only applies to errored parameters, this value MUST NOT be used.


This subtype is optional in a Service Flow Error Parameter Set. If present, it indicates a text string to be displayedon the CM console and/or log that further describes a rejected Service Flow request. A Service Flow ErrorParameter Set MAY have zero or one Error Message subtypes within a given Service Flow Error Encoding.

Note: The length N includes the terminating zero.

Note: The entire Service Flow Encoding message MUST have a total length of less than 256 characters.


[24/25].5.1 1 Service Flow Encoding Subtype in Error


[24/25].5.2 1 Confirmation code


[24/25].5.3 n Zero-terminated string of ASCII characters.

353


C.2.2.5 Common Upstream and Downstream Quality-of-Service Parameter Encodings

The remaining Type 24 & 25 parameters are QoS Parameters. Any given QoS Parameter type MUST appear zeroor one times per Service Flow Encoding.

C.2.2.5.1 Traffic Priority

The value of this parameter specifies the priority assigned to a Service Flow. Given two Service Flows identicalin all QoS parameters besides priority, the higher priority Service Flow SHOULD be given lower delay andhigher buffering preference. For otherwise non-identical Service Flows, the priority parameter SHOULD NOTtake precedence over any conflicting Service Flow QoS parameter. The specific algorithm for enforcing thisparameter is not mandated here.

For upstream service flows, the CMTS SHOULD use this parameter when determining precedence in requestservice and grant generation, and the CM MUST preferentially select contention Request opportunities forPriority Request Service IDs (refer to A.2.3) based on this priority and its Request/Transmission Policy (refer toC.2.2.6.3).

Note: The default priority is 0.

C.2.2.5.2 Maximum Sustained Traffic Rate

This parameter is the rate parameter R of a token-bucket-based rate limit for packets. R is expressed in bits persecond, and MUST take into account all MAC frame data PDU of the Service Flow from the byte following the

MAC header HCS to the end of the CRC.1 The number of bytes forwarded (in bytes) is limited during any timeinterval T by Max(T), as described in the expression

Max(T) = T * (R / 8) + B, (1)

where the parameter B (in bytes) is the Maximum Traffic Burst Configuration Setting (refer to C.2.2.5.3).

Note: This parameter does not limit the instantaneous rate of the Service Flow.

Note: The specific algorithm for enforcing this parameter is not mandated here. Any implementation which satisfies the aboveequation is conformant.

Note: If this parameter is omitted or set to zero, then there is no explicitly-enforced traffic rate maximum. This field specifiesonly a bound, not a guarantee that this rate is available.

C.2.2.5.2.1 Upstream Maximum Sustained Traffic Rate

For an upstream Service Flow, the CM MUST NOT request bandwidth exceeding the Max(T) requirement in (1)during any interval T because this could force the CMTS to fill MAPs with deferred grants.

The CM MUST defer upstream packets that violate (1) and “rate shape” them to meet the expression, up to alimit as implemented by vendor buffering restrictions.

Type Length Value

[24/25].7 1 0 to 7 — Higher numbers indicate higher priority

1. The payload size includes every PDU in a Concatenated MAC Frame.

354


The CMTS MUST enforce expression (1) on all upstream data transmissions, including data sent in contention.The CMTS MAY consider unused grants in calculations involving this parameter. The CMTS MAY enforce thislimit by any of the following methods: (a) discarding over-limit requests, (b) deferring (through zero-lengthgrants) the grant until it is conforming to the allowed limit, or (c) discarding over-limit data packets. A CMTSMUST report this condition to a policy module. If the CMTS is policing by discarding either packets or requests,the CMTS MUST allow a margin of error between the CM and CMTS algorithms.

C.2.2.5.2.2 Downstream Maximum Sustained Traffic Rate

For a downstream Service Flow, this parameter is only applicable at the CMTS. The CMTS MUST enforceexpression (1) on all downstream data transmissions. The CMTS MUST NOT forward downstream packets thatviolates (1) in any interval T. The CMTS SHOULD “rate shape” the downstream traffic by enqueuing packetsarriving in excess of (1), and delay them until the expression can be met.

This parameter is not intended for enforcement on the CM.

C.2.2.5.3 Maximum Traffic Burst

The value of this parameter specifies the token bucket size B (in bytes) for this Service Flow as described in

expression (1). This value is calculated from the byte following the MAC header HCS to the end of the CRC1.

The minimum value of B is 1522 bytes. If this parameter is omitted, the default value for B is 3044 bytes. Thisparameter has no effect unless a non-zero value has been provided for the Maximum Sustained Traffic Rateparameter.

For an upstream service flow, if B is sufficiently less than the Maximum Concatenated Burst parameter, thenenforcement of the rate limit equation will limit the maximum size of a concatenated burst.2

Note: The specific algorithm for enforcing this parameter is not mandated here. Any implementation which satisfies the aboveequation is conformant.

Note: The value of this parameter effects the tradeoff between the data latency perceived by an individual application, and thetraffic engineering requirements of the network. A large value will tend to reduce the latency introduced by rate limiting forapplications with bursty traffic patterns. A small value will tend to spread out the bursts of data generated by such applications,which may benefit traffic engineering within the network.3

Type Length Value

24.8 4 R (in bits per second)

Type Length Value

25.8 4 R (in bits per second)


Type Length Value

[24/25].9 4 B (bytes)

2. Section C.2.2.5.3 text from “The minimum value of B” to this footnote, updated per RFI2-N-02090by RKV on 10/28/02.

3. Section C.2.2.5.3 second Note added per RFI2-N-02090 by RKV on 10/28/02.

355


C.2.2.5.4 Minimum Reserved Traffic Rate

This parameter specifies the minimum rate, in bits/sec, reserved for this Service Flow. The CMTS SHOULD beable to satisfy bandwidth requests for a Service Flow up to its Minimum Reserved Traffic Rate. If less bandwidththan its Minimum Reserved Traffic Rate is requested for a Service Flow, the CMTS MAY reallocate the excessreserved bandwidth for other purposes. The aggregate Minimum Reserved Traffic Rate of all Service FlowsMAY exceed the amount of available bandwidth. This value of this parameter is calculated from the byte

following the MAC header HCS to the end of the CRC1. If this parameter is omitted, then it defaults to a value of0 bits/sec (i.e., no bandwidth is reserved for the flow by default).

This field is only applicable at the CMTS and MUST be enforced by the CMTS.

Note: The specific algorithm for enforcing the value specified in this field is not mandated here.

C.2.2.5.5 Assumed Minimum Reserved Rate Packet Size

The value of this field specifies an assumed minimum packet size (in bytes) for which the Minimum ReservedTraffic Rate will be provided. This parameter is defined in bytes and is specified as the bytes following the MACheader HCS to the end of the CRC2. If the Service Flow sends packets of a size smaller than this specified value,such packets will be treated as being of the size specified in this parameter for calculating the minimum ReservedTraffic Rate and for calculating bytes counts (e.g., bytes transmitted) which may ultimately be used for billing.

The CMTS MUST apply this parameter to its Minimum Reserved Traffic Rate algorithm. This parameter is usedby the CMTS to estimate the per packet overhead of each packet in the service flow.

If this parameter is omitted, then the default value is CMTS implementation dependent.

C.2.2.5.6 Timeout for Active QoS Parameters

The value of this parameter specifies the maximum duration resources remain unused on an active Service Flow.If there is no activity on the Service Flow within this time interval, the CMTS MUST change the active andadmitted QoS Parameter Sets to null. The CMTS MUST signal this resource change with a DSC-REQ to theCM.

This parameter MUST be enforced at the CMTS and SHOULD NOT be enforced at the CM. The parameter isprocessed by the CMTS for every QoS set contained in Registration messages and Dynamic Service messages. Ifthe parameter is omitted, the default of 0 (i.e., infinite timeout) is assumed. The value specified for the activeQoS set must be less than or equal to the corresponding value in the admitted QoS set which must be less than orequal to the corresponding value in the provisioned/authorized QoS set. If the requested value is too large, theCMTS MAY reject the message or respond with a value less than that requested. If the Registration or Dynamic


Type Length Value

[24/25].10 4


Type Length Value

[24/25].11 2

Type Length Value

[24/25].12 2 seconds

356


Service message is accepted by the CMTS and acknowledged by the CM, the Active MQoS Timeout timer isloaded with the new value of the timeout. The timer is activated if the message activates the associated ServiceFlow. The timer is deactivated if the message sets the active QoS set to null.

C.2.2.5.7 Timeout for Admitted QoS Parameters

The value of this parameter specifies the duration that the CMTS MUST hold resources for a Service Flow’sAdmitted QoS Parameter Set while they are in excess of its Active QoS Parameter Set. If there is no DSC-REQto activate the Admitted QoS Parameter Set within this time interval, and there is no DSC to refresh the QoSparameter sets and restart the timeout (see 8.1.5.2), the resources that are admitted but not activated MUST bereleased, and only the active resources retained. The CMTS MUST set the Admitted QoS Parameter Set equal tothe Active QoS Parameter Set for the Service Flow and initiate a DSC-REQ exchange with the CM to inform itof the change.

This parameter MUST be enforced at the CMTS and SHOULD NOT be enforced at the CM. The parameter isprocessed by the CMTS for every QoS set contained in Registration messages and Dynamic Service messages. Ifthe parameter is omitted, the default of 200 seconds is assumed. A value of 0 means that the Service Flow canremain in the admitted state for an infinite amount of time and MUST NOT be timed out due to inactivity.However, this is subject to policy control by the CMTS. The value specified for the active QoS set must be lessthan or equal to the corresponding value in the admitted QoS set which must be less than or equal to thecorresponding value in the provisioned/authorized QoS set. If the requested value is too large, the CMTS MAYreject the message or respond with a value less than that requested. If the Registration or Dynamic Servicemessage containing this parameter is accepted by the CMTS and acknowledged by the CM, the Admitted QoSTimeout timer is loaded with the new value of the timeout. The timer is activated if the message admits resourcesgreater than the active set. The timer is deactivated if the message sets the active QoS set and admitted QoS setequal to each other.

C.2.2.5.8 Vendor Specific QoS Parameters

This allows vendors to encode vendor-specific QoS parameters. The Vendor ID MUST be the first TLVembedded inside Vendor Specific QoS Parameters. If the first TLV inside Vendor Specific QoS Parameters is nota Vendor ID, then the TLV MUST be discarded. (Refer to C.1.1.17)

C.2.2.6 Upstream-Specific QoS Parameter Encodings

C.2.2.6.1 Maximum Concatenated Burst

The value of this parameter specifies the maximum concatenated burst (in bytes) which a Service Flow isallowed. This parameter is calculated from the FC byte of the Concatenation MAC Header to the last CRC in theconcatenated MAC frame.

A value of 0 means there is no limit. If this parameter is omitted the default value is 1522.1

Type Length Value

[24/25].13 2 seconds

Type Length Value

[24/25].43 n

1. Second sentence updated per RFI2-N-02090 by RKV on 10/28/02.

357


This field is only applicable at the CM. If defined, this parameter MUST be enforced at the CM.

Note: This value does not include any physical layer overhead.

Note: This applies only to concatenated bursts. It is legal and, in fact, it may be useful to set this smaller than the maximumEthernet packet size. Of course, it is also legal to set this equal to or larger than the maximum Ethernet packet size.

Note: The maximum size of a concatenated burst can also be limited by the enforcement of a rate limit, if the Maximum TrafficBurst parameter is small enough, and by limits on the size of data grants in the UCD message.1

C.2.2.6.2 Service Flow Scheduling Type

The value of this parameter specifies which upstream scheduling service is used for upstream transmissionrequests and packet transmissions. If this parameter is omitted, then the Best Effort service MUST be assumed.

This parameter is only applicable at the CMTS. If defined, this parameter MUST be enforced by the CMTS.

C.2.2.6.3 Request/Transmission Policy

The value of this parameter specifies which IUC opportunities the CM uses for upstream transmission requestsand packet transmissions for this Service Flow, whether requests for this Service Flow may be piggybacked withdata and whether data packets transmitted on this Service Flow can be concatenated, fragmented, or have theirpayload headers suppressed. For UGS, it also specifies how to treat packets that do not fit into the UGS grant.See Section 10.2, “Upstream Service Flow Scheduling Services,” on page 213 for requirements related tosettings of the bits of this parameter for each Service Flow Scheduling Type.

This parameter is required for all Service Flow Scheduling Types except Best Effort. If omitted in a Best EffortService Flow QoS parameter Set, the default value of zero MUST be used. Bit #0 is the LSB of the Value field.Bits are set to 1 to select the behavior defined below:

Type Length Value

24.14 2

1. Section C.2.2.6.1, last Note added per RFI2-N-02090 by RKV on 10/28/02.

Type Length Value

24.15 1 0 Reserved

1 for Undefined (CMTS implementation-dependent1)

1. The specific implementation dependent scheduling service type could be defined in the 24.43Vendor Specific Information Field.

2 for Best Effort

3 for Non-Real-Time Polling Service

4 for Real-Time Polling Service

5 for Unsolicited Grant Service with Activity Detection

6 for Unsolicited Grant Service

7 through 255 are reserved for future use

Type Length Value

24.16 4 Bit #0 The Service Flow MUST NOT use “all CMs” broadcast requestopportunities.

Bit #1 The Service Flow MUST NOT use Priority Request multicast requestopportunities. (Refer to A.2.3)

358


Note: Data grants include both short and long data grants.

C.2.2.6.4 Nominal Polling Interval

The value of this parameter specifies the nominal interval (in units of microseconds) between successive unicastrequest opportunities for this Service Flow on the upstream channel. This parameter is typically suited for Real-Time and Non-Real-Time Polling Service.

The ideal schedule for enforcing this parameter is defined by a reference time t0, with the desired transmissiontimes ti = t0 + i*interval. The actual poll times, t'i MUST be in the range ti <= t'i <= ti + jitter, where interval is thevalue specified with this TLV, and jitter is Tolerated Poll Jitter. The accuracy of the ideal poll times, ti, aremeasured relative to the CMTS Master Clock used to generate timestamps (refer to Section 9.3).

This field is only applicable at the CMTS. If defined, this parameter MUST be enforced by the CMTS.

C.2.2.6.5 Tolerated Poll Jitter

The values in this parameter specifies the maximum amount of time that the unicast request interval may bedelayed from the nominal periodic schedule (measured in microseconds) for this Service Flow.

The ideal schedule for enforcing this parameter is defined by a reference time t0, with the desired poll times ti =t0 + i*interval. The actual poll, t'i MUST be in the range ti <= t'i <= ti + jitter, where jitter is the value specifiedwith this TLV and interval is the Nominal Poll Interval. The accuracy of the ideal poll times, ti, are measuredrelative to the CMTS Master Clock used to generate timestamps (refer to Section 9.3).

This parameter is only applicable at the CMTS. If defined, this parameter represents a service commitment (oradmission criteria) at the CMTS.

Bit #2 The Service Flow MUST NOT use Request/Data opportunities forRequests

Bit #3 The Service Flow MUST NOT use Request/Data opportunities for Data

Bit #4 The Service Flow MUST NOT piggyback requests with data.

Bit #5 The Service Flow MUST NOT concatenate data.

Bit #6 The Service Flow MUST NOT fragment data

Bit #7 The Service Flow MUST NOT suppress payload headers

Bit #8 The Service Flow MUST drop packets that do not fit in the Unsolicited

Grant Size 1 2

All other bits are reserved.

1. This bit only applies to Service Flows with the Unsolicited Grant Service Flow Scheduling Type, if this bit is set on anyother Service Flow Scheduling type it MUST be ignored

2. Packets that classify to an Unsolicited Grant Service Flow and are larger than the Grant Size associated with thatService Flow are normally transmitted on the Primary Service Flow. This parameter overrides that default behavior.

Type Length Value

24.17 4 µsec

Type Length Value

24.18 4 µsec

Type Length Value

359


C.2.2.6.6 Unsolicited Grant Size

The value of this parameter specifies the unsolicited grant size in bytes. The grant size includes the entire MACframe data PDU from the Frame Control byte to end of the MAC frame.

This parameter is applicable at the CMTS and MUST be enforced at the CMTS.

Note: For UGS, this parameter should be used by the CMTS to compute the size of the unsolicited grant in mini-slots.

C.2.2.6.7 Nominal Grant Interval

The value of this parameter specifies the nominal interval (in units of microseconds) between successive datagrant opportunities for this Service Flow. This parameter is required for Unsolicited Grant and Unsolicited Grantwith Activity Detection Service Flows.

The ideal schedule for enforcing this parameter is defined by a reference time t0, with the desired transmissiontimes ti = t0 + i*interval. The actual grant times, t'i MUST be in the range ti <= t'i <= ti + jitter, where interval isthe value specified with this TLV, and jitter is the Tolerated Grant Jitter. When multiple grants per interval arerequested, all grants MUST be within this interval, thus the Nominal Grant Interval and Tolerated Grant JitterMUST be maintained by the CMTS for all grants in this Service Flow. The accuracy of the ideal grant times, ti,are measured relative to the CMTS Master Clock used to generate timestamps (refer to Section 9.3).

This field is mandatory for Unsolicited Grant and Unsolicited Grant with Activity Detection Scheduling Types.This field is only applicable at the CMTS, and MUST be enforced by the CMTS.

C.2.2.6.8 Tolerated Grant Jitter

The values in this parameter specifies the maximum amount of time that the transmission opportunities may bedelayed from the nominal periodic schedule (measured in microseconds) for this Service Flow.

The ideal schedule for enforcing this parameter is defined by a reference time t0, with the desired transmissiontimes ti = t0 + i*interval. The actual transmission opportunities, t'i MUST be in the range ti <= t'i <= ti + jitter,where jitter is the value specified with this TLV and interval is the Nominal Grant Interval. The accuracy of theideal grant times, ti, are measured relative to the CMTS Master Clock used to generate timestamps (refer toSection 9.3).


Type Length Value

24.19 2

Type Length Value

24.20 4 µsec

Type Length Value

24.21 4 µsec

360


C.2.2.6.9 Grants per Interval

For Unsolicited Grant Service, the value of this parameter indicates the actual number of data grants per NominalGrant Interval. For Unsolicited Grant Service with Activity Detection, the value of this parameter indicates themaximum number of Active Grants per Nominal Grant Interval. This is intended to enable the addition ofsessions to an existing Unsolicited Grant Service Flow via the Dynamic Service Change mechanism, withoutnegatively impacting existing sessions.

The ideal schedule for enforcing this parameter is defined by a reference time t0, with the desired transmissiontimes ti = t0 + i*interval. The actual grant times, t'i MUST be in the range ti <= t'i <= ti + jitter, where interval isthe Nominal Grant Interval, and jitter is the Tolerated Grant Jitter. When multiple grants per interval arerequested, all grants MUST be within this interval, thus the Nominal Grant Interval and Tolerated Grant JitterMUST be maintained by the CMTS for all grants in this Service Flow.


C.2.2.6.10 IP Type of Service Overwrite

The CMTS MUST overwrite IP packets with IP ToS byte value “orig-ip-tos” with the value “new-ip-tos”, wherenew-ip-tos = ((orig-ip-tos AND tos-and-mask) OR tos-or-mask). If this parameter is omitted, then the IP packetToS byte is not overwritten.

This parameter is only applicable at the CMTS. If defined, this parameter MUST be enforced by the CMTS.

C.2.2.6.11 Unsolicited Grant Time Reference

For Unsolicited Grant Service and Unsolicited Grant Service with Activity Detection, the value of this parameterspecifies a reference time t0 from which can be derived the desired transmission times ti = t0 + i*interval, whereinterval is the Nominal Grant Interval (Refer to C.2.2.6.7). This parameter is applicable only for messagestransmitted from the CMTS to the CM, and only when a UGS or UGS-AD service flow is being made active. Insuch cases this is a mandatory parameter.

The timestamp specified in this parameter represents a count state of the CMTS 10.24 MHz master clock. Sincea UGS or UGS-AD service flow is always activated before transmission of this parameter to the modem, thereference time t0 is to be interpreted by the modem as the ideal time of the next grant only if t0 follows the currenttime. If t0 precedes the current time, the modem can calculate the offset from the current time to the ideal time ofthe next grant according to:

interval - (((current time - t0)/10.24) modulus interval)

where interval is in units of microseconds, and current time and t0 are in 10.24 MHz units.

Type Length Value Valid Range

24.22 1 # of grants 0-127

Type Length Value

24.23 2 tos-and-mask, tos-or-mask

Type Length Value Valid Range

24.24 4 CMTS Timestamp 0-4,294,967,295

361


C.2.2.7 Downstream-Specific QoS Parameter Encodings

C.2.2.7.1 Maximum Downstream Latency

The value of this parameter specifies the maximum latency between the reception of a packet by the CMTS on itsNSI and the forwarding of the packet to its RF Interface.

If defined, this parameter represents a service commitment (or admission criteria) at the CMTS and MUST beguaranteed by the CMTS. A CMTS does not have to meet this service commitment for Service Flows that exceedtheir minimum downstream reserved rate.

C.2.2.8 Payload Header Suppression

This field defines the parameters associated with Payload Header Suppression.

Note: The entire Payload Header Suppression TLV MUST have a length of less than 255 characters.

C.2.2.8.1 Classifier Reference

The value of the field specifies a Classifier Reference that identifies the corresponding Classifier. (Refer toC.2.1.3.1)

C.2.2.8.2 Classifier Identifier

The value of the field specifies a Classifier Identifier that identifies the corresponding Classifier. (Refer toC.2.1.3.2)


The value of the field specifies a Service Flow Reference that identifies the corresponding Service Flow. (Referto C.2.2.3.1)

Type Length Value

25.14 4 µsec

Type Length Value

26 n

Type Length Value

26.1 1 1 - 255

Type Length Value

26.2 2 1 - 65535

Type Length Value

26.3 2 1 - 65535

362



The value of this field specifies the Service Flow Identifier that identifies the Service Flow to which the PHS ruleapplies.

C.2.2.8.5 Dynamic Service Change Action

When received in a Dynamic Service Change Request, this indicates the action that MUST be taken with thispayload header suppression byte string.

The “Set PHS Rule” command is used to add specific TLVs to a partially defined payload header suppressionrule. A PHS rule is partially defined when the PHSF and PHSS values are not both known. A PHS rule becomesfully defined when the PHSF and PHSS values are both known. Once a PHS rule is fully defined, “Set PHSRule” MUST NOT be used to modify existing TLVs.

The “Delete all PHS Rules” command is used to delete all PHS Rules for a specified Service Flow. See Section8.3.15 for details on DSC-REQ required PHS parameters when using this option.

Note: An attempt to Add a PHS Rule which already exists is an error condition.

C.2.2.9 Payload Header Suppression Error Encodings

This field defines the parameters associated with Payload Header Suppression Errors.

A Payload Header Suppression Error Encoding consists of a single Payload Header Suppression Error ParameterSet which is defined by the following individual parameters: Errored Parameter, Confirmation Code and ErrorMessage.

The Payload Header Suppression Error Encoding is returned in REG-RSP, DSA-RSP and DSC-RSP messages toindicate the reason for the recipient’s negative response to a Payload Header Suppression Rule establishmentrequest in a REG-REQ, DSA-REQ or DSC-REQ message.

On failure, the REG-RSP, DSA-RSP, or DSC-RSP MUST include one Payload Header Suppression ErrorEncoding for at least one failed Payload Header Suppression Rule requested in the REG-REQ, DSA-REQ orDSC-REQ message. A Payload Header Suppression Error Encoding for the failed Payload Header SuppressionRule MUST include the Confirmation Code and Errored Parameter and MAY include an Error Message. If somePayload Header Suppression Rule Sets are rejected but other Payload Header Suppression Rule Sets areaccepted, then Payload Header Suppression Error Encodings MUST be included for only the rejected PayloadHeader Suppression Rules.1 On success of the entire transaction, the RSP or ACK message MUST NOT includea Payload Header Suppression Error Encoding.

Type Length Value

26.4 4 1 - 4,294,967,295

Type Length Value

26.5 1 0 — Add PHS Rule

1 — Set PHS Rule

2 — Delete PHS Rule

3 — Delete all PHS Rules

Type Length Value

26.6 n

363


Multiple Payload Header Suppression Error Encodings MAY appear in a REG-RSP, DSA-RSP or DSC-RSPmessage, since multiple Payload Header Suppression parameters may be in error. A message with even a singlePayload Header Suppression Error Encoding MUST NOT contain any other protocol Payload HeaderSuppression Encodings (e.g., IP, 802.1P/Q).

A Payload Header Suppression Error Encoding MUST NOT appear in any REG-REQ, DSA-REQ or DSC-REQmessages.


The value of this parameter identifies the subtype of a requested Payload Header Suppression parameter in errorin a rejected Payload Header Suppression request. A Payload Header Suppression Error Parameter Set MUSThave exactly one Errored Parameter TLV within a given Payload Header Suppression Error Encoding.


This parameter indicates the status of the request. A non-zero value corresponds to the Confirmation Code asdescribed in C.4. A Payload Header Suppression Error Parameter Set MUST have exactly one Error Code withina given Payload Header Suppression Error Encoding.

A value of okay(0) indicates that the Payload Header Suppression request was successful. Since a PayloadHeader Suppression Error Parameter Set only applies to errored parameters, this value MUST NOT be used.


This subtype is optional in a Payload Header Suppression Error Parameter Set. If present, it indicates a text stringto be displayed on the CM console and/or log that further describes a rejected Payload Header Suppressionrequest. A Payload Header Suppression Error Parameter Set MAY have zero or one Error Message subtypeswithin a given Payload Header Suppression Error Encoding.

Note: The length n includes the terminating zero.

Note: The entire Payload Header Suppression Encoding message MUST have a total length of less than 256 characters.


26.6.1 1 Payload Header Suppression Encoding Subtype in Error


26.6.2 1 Confirmation code


26.6.3 n Zero-terminated string of ASCII characters.

364


C.2.2.10 Payload Header Suppression Rule Encodings

C.2.2.10.1 Payload Header Suppression Field (PHSF)

The value of this field are the bytes of the headers which MUST be suppressed by the sending entity, and MUSTbe restored by the receiving entity. In the upstream, the PHSF corresponds to the string of PDU bytes startingwith the first byte after the MAC Header Checksum. For the downstream, the PHSF corresponds to the string ofPDU bytes starting with the 13th byte after the MAC Header Checksum. This string of bytes is inclusive of bothsuppressed and unsuppressed bytes of the PDU header. The value of the unsuppressed bytes within the PHSF isimplentation dependent.

The ordering of the bytes in the value field of the PHSF TLV string MUST follow the sequence:

UpstreamMSB of PHSF value = 1st byte of PDU2nd MSB of PHSF value = 2nd byte of PDU...nth byte of PHSF (LSB of PHSF value) = nth byte of PDU

DownstreamMSB of PHSF value = 13th byte of PDU2nd MSB of PHSF value = 14th byte of PDU...nth byte of PHSF (LSB of PHSF value) = (n+13)th byte of PDU

The length n MUST always be the same as the value for PHSS.

C.2.2.10.2 Payload Header Suppression Index (PHSI)

The Payload Header Suppression Index (PHSI) has a value between 1 and 255 which uniquely references thesuppressed byte string. The Index is unique per Service Flow in the upstream direction and unique per CM in thedownstream direction. The upstream and downstream PHSI values are independent of each other.

C.2.2.10.3 Payload Header Suppression Mask (PHSM)

The value of this field is used to interpret the values in the Payload Header Suppression Field. It is used at boththe sending and receiving entities on the link. The PHSM allows fields such as sequence numbers or checksumswhich vary in value to be excluded from suppression with the constant bytes around them suppressed.

Type Length Value

26.7 n string of bytes suppressed

Type Length Value

26.8 1 index value

Type Length Value

26.9 n bit 0: 0 = don’t suppress first byte of the suppression field

1 = suppress first byte of the suppression field

bit 1: 0 = don’t suppress second byte of the suppression field

1 = suppress second byte of the suppression field

bit x: 0 = don’t suppress (x+1) byte of the suppression field

1 = suppress (x+1) byte of the suppression field

365


The length n is ceiling(PHSS/8). Bit 0 is the MSB of the Value field. The value of each sequential bit in thePHSM is an attribute for the corresponding sequential byte in the PHSF.

If the bit value is a “1” (and verification passes or is disabled), the sending entity MUST suppress the byte, andthe receiving entity MUST restore the byte from its cached PHSF. If the bit value is a “0”, the sending entityMUST NOT suppress the byte, and the receiving entity MUST restore the byte by using the next byte in thepacket.

If this TLV is not included, the default is to suppress all bytes.

C.2.2.10.4 Payload Header Suppression Size (PHSS)

The value of this field is the total number of bytes in the Payload Header Suppression Field (PHSF) for a ServiceFlow that uses Payload Header Suppression.

This TLV is used when a Service Flow is being created. For all packets that get classified and assigned to aService Flow with Payload Header Suppression enabled, suppression MUST be performed over the specifiednumber of bytes as indicated by the PHSS and according to the PHSM. If this TLV is included in a Service Flowdefinition with a value of 0 bytes, then Payload Header Suppression is disabled. A non-zero value indicatesPayload Header Suppression is enabled. Until the PHSS value is known, the PHS rule is considered partiallydefined, and suppression will not be performed. A PHS rule becomes fully defined when both PHSS and PHSFare known.

C.2.2.10.5 Payload Header Suppression Verification (PHSV)

The value of this field indicates to the sending entity whether or not the packet header contents are to be verifiedprior to performing suppression. If PHSV is enabled, the sender MUST compare the bytes in the packet headerwith the bytes in the PHSF that are to be suppressed as indicated by the PHSM.

If this TLV is not included, the default is to verify. Only the sender MUST verify suppressed bytes. If verificationfails, the Payload Header MUST NOT be suppressed. (Refer to Section 10.4.3)

C.2.2.10.6 Vendor Specific PHS Parameters

This allows vendors to encode vendor-specific PHS parameters. The Vendor ID MUST be the first TLVembedded inside Vendor Specific PHS Parameters. If the first TLV inside Vendor Specific PHS Parameters is nota Vendor ID, then the TLV MUST be discarded. (Refer to C.1.1.17)

Type Length Value

26.10 1 number of bytes in the suppression string

Type Length Value

26.11 1 0 = verify

1 = don’t verify

Type Length Value

26.43 n

366


C.3 Encodings for Other Interfaces

C.3.1 Telephone Settings Option

This configuration setting describes parameters which are specific to telephone return systems. It is composedfrom a number of encapsulated type/length/value fields. See [DOCSIS6].

C.3.2 Baseline Privacy Configuration Settings Option

This configuration setting describes parameters which are specific to Baseline Privacy. It is composed from anumber of encapsulated type/length/value fields. See [DOCSIS8].

C.4 Confirmation Code

The Confirmation Code (CC) provides a common way to indicate failures for Registration Response,Registration Ack, Dynamic Service Addition-Response, Dynamic Service Addition-Ack, Dynamic ServiceDelete-Response, Dynamic Service Change-Response, Dynamic Service Change-Ack and Dynamic ChannelChange-Response MAC Management Messages. The confirmation codes in this section are used both asmessage Confirmation Codes and as Error Codes in Error Set Encodings which may be carried in thesemessages.

Confirmation Code is one of the following:

okay / success(0)reject-other(1)reject-unrecognized-configuration-setting(2)reject-temporary / reject-resource(3)reject-permanent / reject-admin(4)reject-not-owner(5)reject-service-flow-not-found(6)reject-service-flow-exists(7)reject-required-parameter-not-present(8)reject-header-suppression(9)reject-unknown-transaction-id(10)reject-authentication-failure (11)reject-add-aborted(12)reject-multiple-errors(13)reject-classifier-not-found(14)reject-classifier-exists(15)reject-PHS-rule-not-found(16)reject-PHS-rule-exists(17)reject-duplicate-reference-ID-or-index-in-message(18)reject-multiple-upstream-service-flows(19)reject-multiple-downstream-service-flows(20)reject-classifier-for-another-service-flow(21)reject-PHS-for-another-service-flow(22)

Type Length Value

15 (= TRI_CFG01) n

Type Length Value

17 (= BP_CFG) n

367


reject-parameter-invalid-for-context(23)reject-authorization-failure(24)reject-temporary-DCC(25)

The Confirmation Codes MUST be used in the following way:

• Okay or success(0) means the message was received and successful.

• Reject-other(1) is used when none of the other reason codes apply.

• Reject-unrecognized-configuration setting(2) is used when a configuration setting is not recognized or whenits value is outside of the specified range.

• Reject-temporary(3), also known as reject-resource, indicates that the current loading of the CMTS or CMprevents granting the request, but that the request might succeed at another time.

• Reject-permanent(4), also known as reject-admin, indicates that, for policy, configuration, or capabilities rea-sons, the request would never be granted unless the CMTS or CM were manually reconfigured or replaced.

• Reject-not-owner(5) the requester is not associated with this service flow.

• Reject-service-flow-not-found(6) the Service Flow indicated in the request does not exist.

• Reject-service-flow-exists(7) the Service Flow to be added already exists.

• Reject-required-parameter-not-present(8) a required parameter has been omitted.

• Reject-header-suppression(9) the requested header suppression cannot be supported for whatever reason.

• Reject-unknown-transaction-id(10) the requested transaction continuation is invalid because the receivingend-point does not view the transaction as being ‘in process’ (i.e., the message is unexpected or out of order).

• Reject-authentication-failure(11) the requested transaction was rejected because the message contained aninvalid HMAC-digest, CMTS-MIC, provisioned IP address or timestamp.

• Reject-add-aborted(12) the addition of a dynamic service flow was aborted by the initiator of the DynamicService Addition.

• Reject-multiple-errors (13) is used when multiple errors have been detected.

• Reject-classifier-not-found (14) is used when the request contains an unrecognized classifier ID.

• Reject-classifier-exists (15) indicates that the ID of a classifier to be added already exists.

• Reject-PHS-rule-not-found (16) indicates that the request contains an SFID/classifier ID pair for which noPHS rule exists.

• Reject-PHS-rule-exists (17) indicates that the request to add a PHS rule contains an SFID/classifier ID pairfor which a PHS rule already exists.

• Reject-duplicate-reference-ID-or-index-in-message (18) indicates that the request used an SFR, classifier ref-erence, SFID, or classifier ID twice in an illegal way.

• Reject-multiple-upstream-service-flows (19) is used when DSA/DSC contains parameters for more than oneupstream flow.

• Reject-multiple-downstream-service-flows (20) is used when DSA/DSC contains parameters for more thanone downstream flow.

• Reject-classifier-for-another-service-flow (21) is used in DSA-RSP when the DSA-REQ includes classifierparameters for a SF other than the new SF(s) being added by the DSA.

• Reject-PHS-for-another-service-flow (22) is used in DSA-RSP when the DSA-REQ includes a PHS rule for aSF other than the new SF(s) being added by the DSA.

• Reject-parameter-invalid-for-context(23) indicates that the parameter supplied cannot be used in the encodingin which it was included, or that the value of a parameter is invalid for the encoding in which it wasincluded.

• Reject-authorization-failure(24) the requested transaction was rejected by the authorization module.

368


• Reject-temporary-DCC(25) indicates that the requested resources are not available on the current channels atthis time, and the CM should re-request them on new channels after completing a channel change in responseto a DCC command which the CMTS will send. If no DCC is received, the CM must wait for a time of atleast T14 before re-requesting the resources on the current channels.

C.4.1 Confirmation Codes for Dynamic Channel Change

The CM may return in the DCC-RSP message an appropriate rejection code from C.4. It may also return one ofthe following Confirmation Codes which are unique to DCC-RSP. The Confirmation Codes MUST be used inthe following way:

• depart(180) indicates the CM is on the old channel and is about to perform the jump to the new channel.

• arrive(181) indicates the CM has performed the jump and has arrived at the new channel.

• reject-already-there(182) indicates that the CMTS has asked the CM to move to a channel that it is alreadyoccupying.

• reject-20-disable(183) indicates that the CMTS has asked a CM with 2.0 mode disabled to move to a Type 3channel that it cannot use.

C.4.2 Confirmation Codes for Major Errors

These confirmation codes MUST be used only as message Confirmation Codes in REG-ACK, DSA-RSP, DSA-ACK, DSC-RSP, or DSC-ACK messages, or as the Response code in REG-RSP messages for 1.1 CMs. Ingeneral, the errors associated with these confirmation codes make it impossible either to generate an error set thatcan be uniquely associated with a parameter set in the REG-REQ, DSA-REQ, or DSC-REQ message, or togenerate a full RSP message.

reject-major-service-flow-error(200)reject-major-classifier-error(201)reject-major-PHS-rule-error(202)reject-multiple-major-errors(203)reject-message-syntax-error(204)reject-primary-service-flow-error(205)reject-message-too-big(206)reject-invalid-modem-capabilities(207)

The Confirmation Codes MUST be used only in the following way:

• Reject-major-service-flow-error(200) indicates that the REQ message did not have either a SFR or SFID in aservice flow encoding, and that service flow major errors were the only major errors.

• Reject-major-classifier-error(201) indicates that the REQ message did not have a classifier reference, or didnot have both a classifier ID and a Service Flow ID, and that classifier major errors were the only majorerrors.

• Reject-major-PHS-rule-error(202) indicates that the REQ message did not have a both a Service Flow Refer-ence/Identifier and a Classifier Reference/Identifier, and that PHS rule major errors were the only majorerrors.

• Reject-multiple-major-errors(203) indicates that the REQ message contained multiple major errors of types200, 201, 202.

• Reject-message-syntax-error(204) indicates that the REQ message contained syntax error(s) (e.g., a TLVlength error) resulting in parsing failure.

• Reject-primary-service-flow-error(205) indicates that a REG-REQ or REG-RSP message did not define arequired primary Service Flow, or a required primary Service Flow was not specified active.

369


• Reject-message-too-big(206) is used when the length of the message needed to respond exceeds the maxi-mum allowed message size.

• Reject-invalid-modem-capabilities(207) indicates that the REG-REQ contained either that in invalid combi-nation of modem capabilities or modem capabilities that are inconsistent with the services in the REG-REQ.

370


Annex D CM Configuration Interface Specification

D.1 CM IP Addressing

D.1.1 DHCP Fields Used by the CM

The following fields MUST be present in the DHCP request from the CM and MUST be set as described below:

• The hardware type (htype) MUST be set to 1 (Ethernet).

• The hardware length (hlen) MUST be set to 6.

• The client hardware address (chaddr) MUST be set to the 48 bit MAC address associated with the RF inter-face of the CM.

• The “client identifier” option MUST be included, with the hardware type set to 1, and the value set to thesame 48 bit MAC address as the chaddr field.

• Option code 60 (Vendor Class Identifier) — to allow for the differentiation between DOCSIS 2.0 and DOC-SIS 1.x CM requests, a compliant CM MUST send the following ASCII coded string in Option code 60,“docsis2.0:xxxxxxx”. Where xxxxxxx MUST be an ASCII representation of the hexadecimal encoding of theModem Capabilities; refer to Section C.1.3.1. For example, the ASCII encoding for the first two TLVs (con-catenation and DOCSIS Version) of a DOCSIS 2.0 modem would be 05nn010101020102. Note that manymore TLVs are required for a DOCSIS2.0 modem and the field “nn” will contain the length of all the TLVs.This example shows only two TLVs for simplicity.

• The “parameter request list” option MUST be included. The option codes that MUST be included in the listare:

• Option code 1 (Subnet Mask)

• Option code 2 (Time Offset)

• Option code 3 (Router Option)

• Option code 4 (Time Server Option)

• Option code 7 (Log Server Option)

The following fields are expected in the DHCP response returned to the CM. Fields identified as critical MUSTbe present in the DHCP response, and fields identified as noncritical SHOULD be present. The CM MUSTconfigure itself with the critical fields from the DHCP response, and, if present, with the non-critical fields.

• The IP address to be used by the CM (yiaddr) (critical)

• The IP address of the TFTP server for use in the next phase of the bootstrap process (siaddr) (critical)

• If the DHCP server is on a different network (requiring a relay agent), then the IP address of the relay agent(giaddr). Note: this may differ from the IP address of the first hop router (non-critical)

• The name of the CM configuration file to be read from the TFTP server by the CM (file) (critical)

• The subnet mask to be used by the CM (Subnet Mask, option 1) (non-critical)

• The time offset of the CM from Universal Coordinated Time (UTC) (Time Offset, option 2). This is used bythe CM to calculate the local time for use in time-stamping error logs. (non-critical)

• A list of addresses of one or more routers to be used for forwarding CM-originated IP traffic (Router Option,option 3). The CM is not required to use more than one router IP address for forwarding, but MUST use atleast one. (non-critical)

• A list of [RFC-868] time-servers from which the current time may be obtained (Time Server Option,option 4) (non-critical)

371


• A list of SYSLOG servers to which logging information may be sent (Log Server Option, option 7); see[DOCSIS5] (non-critical)

If a critical field is missing, or is invalid in the DHCP response during initialization, the CM MUST log an errorand reinitialize its MAC and continue channel scanning.

If a non-critical field is missing or is invalid in the DHCP response during initialization, the CM MUST log awarning, ignore the field and go operational, with the following considerations:

• If the subnet mask is missing or is invalid, the CM MUST use the default for the IP of Class A, B or C asdefined in [RFC-791].

• If the time server is missing or is invalid, the CM MUST initialize the time for the events to Jan 1, 1970,0h00.

If the IP address field is missing or is invalid in the DHCP response during renew or rebind, the CM MUST logan error and reinitialize its MAC and continue channel scanning.

If any other critical or non-critical field is missing or is invalid in the DHCP response during renew or rebind, the

CM MUST log a warning, ignore the field if it is invalid and stay operational.1

To assist the DHCP server in differentiating a CM discovery request from a CPE-side LAN discovery request, aCMTS MUST implement the following:

• All CMTSes MUST support the DHCP relay agent information option [RFC-3046]. Specifically, the CMTSMUST include the 48 bit MAC address of the RF side interface of the CM generating or bridging the DHCPdiscovery request in the agent remote ID sub-option field before relaying the discovery to a DHCP server.

• If the CMTS is a router, it MUST use a giaddr field to differentiate between CM and CPE side station if theyare provisioned to be in different IP subnets. Bridging CMTSes SHOULD also provide this functionality.

D.2 CM Configuration

D.2.1 CM Binary Configuration File Format

The CM-specific configuration data MUST be contained in a file which is downloaded to the CM via TFTP. Thisis a binary file in the same format defined for DHCP vendor extension data [RFC-2132].

It MUST consist of a number of configuration settings (1 per parameter) each of the form

Type Length Value

Type is a single-octet identifier which defines the parameter.

Length is a single octet containing the length of the value field in octets (not including type and lengthfields)

Value is from one to 254 octets containing the specific value for the parameter

The configuration settings MUST follow each other directly in the file, which is a stream of octets (no recordmarkers).

1. Revised sentence per ECN RFI2-N-02216, chg #1, by GO, on 12/02/02.

372


Configuration settings are divided into three types:

• Standard configuration settings which MUST be present

• Standard configuration settings which MAY be present

• Vendor-specific configuration settings.

CMs MUST be capable of processing all standard configuration settings. CMs MUST ignore any configurationsetting present in the configuration file which it cannot interpret. To allow uniform management of CMsconformant to this specification, conformant CMs MUST support a 8192-byte configuration file at a minimum.

Authentication of the provisioning information is provided by two message integrity check (MIC) configurationsettings, CM MIC and CMTS MIC.

• CM MIC is a digest which ensures that the data sent from the provisioning server were not modified en route.This is NOT an authenticated digest (it does not include any shared secret).

• CMTS MIC is a digest used to authenticate the provisioning server to the CMTS during registration. It istaken over a number of fields one of which is a shared secret between the CMTS and the provisioning server.

Use of the CM MIC allows the CMTS to authenticate the provisioning data without needing to receive the entirefile.

Thus the file structure is of the form shown in Figure D-1:

Figure D-1 Binary Configuration File Format

D.2.2 Configuration File Settings

The following configuration settings MUST be included in the configuration file and MUST be supported by allCMs. The CM MUST NOT send a REG-REQ based on a configuration file that lacks these mandatory items.

• Network Access Configuration Setting

• CM MIC Configuration Setting

• CMTS MIC Configuration Setting

• End Configuration Setting

• DOCSIS 1.0 Class of Service Configuration Setting— or —

• Upstream Service Flow Configuration Setting

• Downstream Service Flow Configuration Setting

Note: A DOCSIS 1.0 CM must be provided with a DOCSIS 1.0 Class of Service Configuration. A CM conformant with thisspecification should only be provisioned with DOCSIS 1.0 Class of Service Configuration information if it is to behave as aDOCSIS 1.0 CM; otherwise, it should be provisioned with Service Flow Configuration Settings

The following configuration settings MAY be included in the configuration file and if present MUST besupported by all CMs.

ConfigurationSetting 1

ConfigurationSetting 2

ConfigurationSetting n

CMMIC

CMTSMIC

373


• Downstream Frequency Configuration Setting

• Upstream Channel ID Configuration Setting

• Baseline Privacy Configuration Setting

• Software Upgrade Filename Configuration Setting

• Upstream Packet Classification Setting

• Downstream Packet Classification Setting

• SNMP Write-Access Control

• SNMP MIB Object

• Software Server IP Address

• CPE Ethernet MAC Address

• Maximum Number of CPEs

• Maximum Number of Classifiers

• Privacy Enable Configuration Setting

• Payload Header Suppression

• TFTP Server Timestamp

• TFTP Server Provisioned Modem Address

• Pad Configuration Setting

• SNMPv3 Notification Receiver

• Enable 2.0 Mode

• Enable Test Modes1

The following configuration setting MAY be included in the configuration file and if present, and applicable tothis type of modem, MUST be supported.

• Telephone Settings Option

The following configuration settings MAY be included in the configuration file and if present MAY be supportedby a CM.

• Vendor-Specific Configuration Settings

Note: There is a limit on the size of registration request and registration response frames (see Section 8.2.5.2). Theconfiguration file should not be so large as to require the CM or CMTS to exceed that limit.

D.2.3 Configuration File Creation

The sequence of operations required to create the configuration file is as shown in Figure D-2 through Figure D-5.

1. Create the type/length/value entries for all the parameters required by the CM.

1. Added this bullet statement to the list per ECN RFI2-N-02210, by GO, on 11/22/02.

374


Figure D-2 Create TLV Entries for Parameters Required by the CM

2. Calculate the CM message integrity check (MIC) configuration setting as defined in Section D.2.3.1 and addto the file following the last parameter using code and length values defined for this field.

Figure D-3 Add CM MIC

3. Calculate the CMTS message integrity check (MIC) configuration setting as defined in Section D.3.1 and addto the file following the CM MIC using code and length values defined for this field.

Figure D-4 Add CMTS MIC

4. Add the end of data marker.

type, length, value for parameter 2

type, length, value for parameter n




type, length, value for CM MIC





type, length, value for CMTS MIC


375


Figure D-5 Add End of Data Marker

D.2.3.1 CM MIC Calculation

The CM message integrity check configuration setting MUST be calculated by performing an MD5 digest overthe bytes of the configuration setting fields. It is calculated over the bytes of these settings as they appear in theTFTPed image, without regard to TLV ordering or contents. There are two exceptions to this disregard of thecontents of the TFTPed image:

1. The bytes of the CM MIC TLV itself are omitted from the calculation. This includes the type, length, andvalue fields.

2. The bytes of the CMTS MIC TLV are omitted from the calculation. This includes the type, length, and valuefields.

On receipt of a configuration file, the CM MUST recompute the digest and compare it to the CM MICconfiguration setting in the file. If the digests do not match then the configuration file MUST be discarded

D.3 Configuration Verification

It is necessary to verify that the CM’s configuration file has come from a trusted source. Thus, the CMTS and theconfiguration server share an Authentication String that they use to verify portions of the CM’s configuration inthe Registration Request.

D.3.1 CMTS MIC Calculation

The CMTS message integrity check configuration setting MUST be calculated by performing an MD5 digestover the following configuration setting fields, when present in the configuration file, in the order shown:

• Downstream Frequency Configuration Setting

• Upstream Channel ID Configuration Setting

• Network Access Configuration Setting

• DOCSIS 1.0 Class of Service Configuration Setting

• Baseline Privacy Configuration Setting

• Vendor-Specific Configuration Settings

• CM MIC Configuration Setting

• Maximum Number of CPEs

• TFTP Server Timestamp




type, length, value for CMTS MIC

end of data marker


376


• TFTP Server Provisioned Modem Address

• Upstream Packet Classification Setting

• Downstream Packet Classification Setting

• Upstream Service Flow Configuration Setting

• Downstream Service Flow Configuration Setting

• Maximum Number of Classifiers

• Privacy Enable Configuration Setting

• Payload Header Suppression

• Subscriber Management Control

• Subscriber Management CPE IP Table

• Subscriber Management Filter Groups

• Enable Test Modes

The bulleted list specifies the order of operations when calculating the CMTS MIC over configuration settingType fields. The CMTS MUST calculate the CMTS MIC over TLVs of the same Type in the order they werereceived. Within Type fields, the CMTS MUST calculate the CMTS MIC over the Subtypes in the order theywere received. To allow for correct CMTS MIC calculation by the CMTS, the CM MUST NOT reorderconfiguration file TLVs of the same Type or Subtypes within any given Type in its Registration-Requestmessage.

All configuration setting fields MUST be treated as if they were contiguous data when calculating the CM MIC.

The digest MUST be added to the configuration file as its own configuration setting field using the CMTS MICConfiguration Setting encoding.

The authentication string is a shared secret between the provisioning server (which creates the configurationfiles) and the CMTS. It allows the CMTS to authenticate the CM provisioning. The authentication string is to beused as the key for calculating the keyed CMTS MIC digest as stated in D.3.1.1.

The mechanism by which the shared secret is managed is up to the system operator.

On receipt of a configuration file, the CM MUST forward the CMTS MIC as part of the registration request(REG-REQ).

On receipt of a REG-REQ, the CMTS MUST recompute the digest over the included fields and theauthentication string and compare it to the CMTS MIC configuration setting in the file. If the digests do notmatch, the registration request MUST be rejected by setting the authentication failure result in the registrationresponse status field.

D.3.1.1 Digest Calculation

The CMTS MIC digest field MUST be calculated using HMAC-MD5 as defined in [RFC-2104].

377



378


Annex E The Data-Over-Cable Spanning Tree Protocol

Section 5.1.2.1 requires the use of the spanning tree protocol on CMs that are intended for commercial use andon bridging CMTSes. This annex describes how the 802.1d spanning tree protocol is adapted to work for data-over-cable systems.

E.1 Background

A spanning tree protocol is frequently employed in a bridged network in order to deactivate redundant networkconnections; i.e., to reduce an arbitrary network mesh topology to an active topology that is a rooted tree thatspans all of the network segments. The spanning tree algorithm and protocol should not be confused with thedata-forwarding function itself; data forwarding may follow transparent learning bridge rules, or may employany of several other mechanisms. By deactivating redundant connections, the spanning tree protocol eliminatestopological loops, which would otherwise cause data packets to be forwarded forever for many kinds offorwarding devices.

A standard spanning tree protocol [IEEE 802.1d] is employed in most bridged local area networks. This protocolwas intended for private LAN use and requires some modification for cable data use.

E.2 Public Spanning Tree

To use a spanning tree protocol in a public-access network such as data-over-cable, several modifications areneeded to the basic IEEE 802.1d process. Primarily, the public spanning tree must be isolated from any privatespanning tree networks to which it is connected. This is to protect both the public cable network and any attachedprivate networks. Figure E-1 illustrates the general topology.

Figure E-1 Spanning Tree Topology

CableModem

CMTS

CableModem

CableModem

Bridged Private Network


379


The task for the public spanning tree protocol, with reference to Figure E-1, is to:

• Isolate the private bridged networks from each other. If the two private networks merge spanning trees theneach is subject to instabilities in the other’s network. Also, the combined tree may exceed the maximumallowable bridging diameter.

• Isolate the public network from the private networks’ spanning trees. The public network must not be subjectto instabilities induced by customers’ networks; nor should it change the spanning tree characteristics of thecustomers’ networks.

• Disable one of the two redundant links into the cable network, so as to prevent forwarding loops. This shouldoccur at the cable modem, rather than at an arbitrary bridge within the customer’s network.

The spanning tree protocol must also serve the topology illustrated in Figure E-2:

Figure E-2 Spanning Tree Across CMTSes

In Figure E-2, in normal operation the spanning tree protocol should deactivate a link at one of the two cablemodems. It should not divert traffic across the private network. Note that in some circumstances, such asdeactivation of Link-X, spanning tree will divert traffic onto the private network (although limits on learnedMAC addresses will probably throttle most transit traffic). If this diversion is undesirable, then it must beprevented by means external to spanning tree; for example, by using routers.

E.3 Public Spanning Tree Protocol Details

The Data over Cable Spanning Tree algorithm and protocol is identical to that defined in [IEEE 802.1d], with thefollowing exceptions:

• When transmitting Configuration Bridge Protocol Data Units (BPDUs), the Data over Cable Spanning TreeMulticast Address 01-E0-2F-00-00-03 MUST be used rather than that defined in IEEE 802.1d. These BPDUswill be forwarded rather than recalculated by ordinary IEEE 802.1d bridges.

• When transmitting Configuration BPDUs, the SNAP header AA-AA-03-00-E0-2F-73-74 MUST be usedrather than the LLC 42-42-03 header employed by 802.1d. This is to further differentiate these BPDUs fromthose used by IEEE 802.1d bridges, in the event that some of those bridges do not correctly identify multicast

MAC addresses.1

1. It is likely that there are a number of spanning tree bridges deployed which rely solely on the LSAPs to dis-tinguish 802.1d packets. Such devices would not operate correctly if the data-over-cable BPDUs also usedLSAP=0x42.

Link-X

CMTS(bridge)

CableModem

CMTS(bridge)

Switched/BridgedHeadendNetwork

CableModem


380


• IEEE 802.1d BPDUs MUST be ignored and silently discarded.

• Topology Change Notification (TCN) PDUs MUST NOT be transmitted (or processed). TCNs are used inIEEE networks to accelerate the aging of the learning database when the network topology may havechanged. Since the learning mechanism within the cable network typically differs, this message is unneces-sary and may result in unnecessary flooding.

• CMTSes operating as bridges must participate in this protocol and must be assigned higher priorities (morelikely to be root) than cable modems. The NSI interface on the CMTS SHOULD be assigned a port costequivalent to a link speed of at least 100 Mbps. These two conditions, taken together, should ensure that (1) aCMTS is the root, and (2) any other CMTS will use the head-end network rather than a customer network toreach the root.

• The MAC Forwarder of the CMTS MUST forward BPDUs from upstream to downstream channels, whetheror not the CMTS is serving as a router or a bridge.

Note that CMs with this protocol enabled will transmit BPDUs onto subscriber networks in order to identifyother CMs on the same subscriber network. These public spanning tree BPDUs will be carried transparently overany bridged private subscriber network. Similarly, bridging CMTSes will transmit BPDUs on the NSI as well ason the RFI interface. The multicast address and SNAP header defined above are used on all links.

E.4 Spanning Tree Parameters and Defaults

Section 4.10.2 of [IEEE 802.1d] specifies a number of recommended parameter values. Those values should beused, with the exceptions listed below:

E.4.1 Path Cost

In [IEEE 802.1d], the following formula is used:

Path_Cost = 1000 / Attached_LAN_speed_in_Mb/s

For CMs, this formula is adapted as:

Path_Cost = 1000 / (Upstream_modulation_rate * bits_per_symbol_for_long_data_grant)

That is, the modulation type (QPSK or 16QAM) for the Long Data Grant IUC is multiplied by the rawmodulation rate to determine the nominal path cost. Table E-1 provides the derived values.

Table E-1 CM Path Cost

For CMTSes, this formula is:

Path_Cost = 1000 / (Downstream_symbol_rate * bits_per_symbol)

ModulationRate Default Path Cost

kHz QPSK 16QAM

160 3125 1563

320 1563 781

640 781 391

1280 391 195

2560 195 98

381


E.4.2 Bridge Priority

The Bridge Priority for CMs SHOULD default to 36864 (0x9000). This is to bias the network so that the rootwill tend to be at the CMTS. The CMTS SHOULD default to 32768, as per 802.1d.

Note that both of these recommendations affect only the default settings. These parameters, as well as othersdefined in 802.1d, SHOULD be manageable throughout their entire range through the Bridge MIB (RFC-1493)or other means.

382


Annex F European Specification Additions1

This section applies to the second technology option referred to in Section 1 (1.1 Scope). For the first option,refer to Sections 4, 6 and 7.

This annex describes the physical layer specifications required for what are generally called Euro-DOCSIScable-modems. This is an optional annex and in no way affects certification of North American, DOCSIS 1.x andDOCSIS 2.0 modems.

The numbering of the paragraphs has been made so that the suffix after the F refers to the part of the specificationwhich has changed. As a consequence some paragraphs are missing in this annex, because no change is required.

F.1 Scope and Purpose

No change required.

F.2 References

See Section 2.

F.3 Glossary

See Section 3.

F.4 Functional Assumptions

This section describes the characteristics of cable television plants to be assumed for the purpose of operating adata-over-cable-system. It is not a description of CMTS or CM parameters. The data-over-cable system MUSTbe interoperable with the environment described in this section.

F.4.1 Broadband access network

A coaxial-based broadband access network is assumed. This may take the form of either an all-coax or Hybrid-Fiber/Coax (HFC) network. The generic term “cable network” is used here to cover all cases.

A cable network uses a shared-medium, tree-and-branch architecture with analogue transmission. The keyfunctional characteristics assumed in this document are the following:

• Two-way transmission.

• A maximum optical/electrical spacing between the CMTS and the most distant customer terminal of 160 km(route meters).

• A maximum differential optical/electrical spacing between the CMTS and the closest and most distantmodems of 160 km (route meters).

1. Annex F rewritten per RFI2-N-02137 by RKV on 10/29/02.

383


F.4.2 Equipment Assumptions

F.4.2.1 Frequency plan

In the downstream direction, the cable system is assumed to have a passband with a typical lower edge between47 and 87.5 MHz and an upper edge which is implementation-dependent but is typically in the range of 300 to862 MHz. Within that passband, PAL/SECAM analogue television signals in 7/8 MHz channels, FM-radiosignals, as well as other narrowband and wideband digital signals are assumed to be present.

In the upstream direction, the cable system is assumed to have a passband with a lower edge at 5 MHz and anupper edge which is implementation-dependent but is typically in the range of 25 to 65 MHz.

F.4.2.2 Compatibility with Other Services

Refer to Section 4.2.2.

F.4.2.3 Fault Isolation Impact on Other Users


F.4.2.4 Cable System Terminal Devices

Compliance with EMC requirements is not covered by this specification. The protection requirements withrespect to electromagnetic compatibility are contained in harmonized standards published in the Official Journalof the European Communities.

Any reference in the present document to the transmission of television in the forward channel that is notconsistent with [EN 300 429] is outside the normative scope as only [EN 300 429] is used for digital multi-program TV distribution by cable in European applications.

Requirements for safety are outside the scope of the present document. Safety standards for Europeanapplications are published by CENELEC.

Note: Examples of such CENELEC product safety standards are [EN 60950] and [EN 50083-1].

Note: For CENELEC safety categories of interfaces, see [EG 201 212].

F.4.3 RF Channel Assumptions

Refer to Section 4.3.

F.4.3.1 Transmission Downstream

The RF channel transmission characteristics of the cable network in the downstream direction assumed for thepurposes of minimal operating capability are described in Table F-1. This assumes nominal analogue videocarrier level (peak envelope power) in a 7/8 MHz channel bandwidth. All conditions are present concurrently.

384


Table F-1 Assumed downstream RF channel transmission characteristics for analogueTV and sound signals

Parameter Value

Frequency range Cable system normal downstream operating range isfrom 47 MHz to as high as 862 MHz. However theoperating range for data communication is from 108 to862 MHz. The use of frequencies between 108 and 136MHz may be forbidden due to national regulation withregard to interference with aeronautical navigationfrequencies.

RF channel spacing (design bandwidth) 7/8 MHz, 8 MHz channels are used for datacommunication

Transit delay from head-end to most distant customer ≤0.800 ms (typically much less)

Carrier-to-noise ratio in a 8 MHz band (analogue video level) Not less than 44 dB (Note 4)

Carrier-to-interference ratio for total power (discrete andbroadband ingress signals)

Not less than 52 dB within the design bandwidth

Composite triple beat distortion for analogue modulated carriers Not greater than – 57 dBc within the design bandwidth(Note 6 a)

Composite second-order distortion for analogue modulatedcarriers

Not greater than – 57 dBc within the design bandwidth(Note 6 b)

Cross-modulation level Under consideration

Amplitude ripple 2.5 dB in 8 MHz

Group delay ripple in the spectrum occupied by the CMTS 100 ns over frequency range 0.5 – 4.43 MHz

Micro-reflections bound for dominant echo –10 dBc @ ≤ 0.5 µs, –15 dBc @ ≤ 1.0 µs–20 dBc @ ≤ 1.5 µs, –30 dBc @ > 1.5 µs

Carrier hum modulation Not greater than – 46 dBc (0.5%)

Burst noise Not longer than 25 µs at a 10 Hz average rate

Seasonal and diurnal signal level variation 8 dB

Signal level slope, 85 - 862 MHz Maximum slope of 12 dB in either the positive or negativedirection

Maximum analogue video carrier level at the system outlet,inclusive of above signal level variation

77 dBµV (Note 6 c)

Lowest analogue video carrier level at the system outlet,inclusive of above signal level variation

60 dBµV (Note 6 d)

NOTE 1 – Transmission is from the head-end combiner to the CM input at the customer location.

NOTE 2 – For measurements above, the normal downstream operating frequency band (except hum), impairments arereferenced to the highest-frequency PAL/SECAM carrier level.

NOTE 3 – For hum measurements above, the normal downstream operating frequency band, a continuous-wave carrier issent at the test frequency at the same level as the highest-frequency PAL/SECAM carrier.

NOTE 4 – This presumes that the average digital carrier is operated at analogue peak carrier level. When the digital carrier isoperated below the analogue peak carrier level, this C/N may be less.

NOTE 5 – Measurements methods are defined in [CENELEC 50083-7].

NOTE 6 – For SECAM systems the following values apply

a) Not greater than -52 dBc within the design bandwidth

b) Not greater than -52 dBc within the design bandwidth

c) 74 dBµV

d) 57 dBµV

385


F.4.3.2 Transmission Upstream

The RF channel transmission characteristics of the cable network in the upstream direction assumed for thepurposes of minimal operating capability are described in Table F-2. All conditions are present concurrently.

Table F-2 Assumed upstream RF channel transmission characteristics

F.4.3.2.1 Availability

Refer to Section 4.3.2.1.

F.4.4 Transmission Levels

The nominal average power level of the downstream CMTS QAM signal(s) within an 8 MHz channel is targetedto be in the range –13 dBc to 0 dBc relative to the analogue peak video carrier level and will normally not exceedthe analogue peak video carrier level (typically between –10 to –6 dBc for 64QAM, and between –6 to –4 dBcfor 256QAM). The nominal power level of the upstream CM signal(s) will be as low as possible to achieve therequired margin above noise and interference. Uniform power loading per unit bandwidth is commonly followedin setting upstream signal levels, with specific levels established by the cable network operator to achieve therequired carrier-to-noise and carrier-to-interference ratios.

F.4.5 Frequency Inversion


Parameter Value

Frequency range 5 up to 65 MHz edge to edge

Transit delay from the most distant CM to the nearest CM orCMTS

≤ 0.800 ms (typically much less)

Carrier-to-noise ratio in active channel Not less than 22 dB

Carrier-to-ingress power (the sum of discrete and broadbandingress signals) ratio in active channel

Not less than 22 dB (Note 2)

Carrier-to-interference (the sum of noise, distortion, common-pathdistortion and cross-modulation) ratio in active channel

Not less than 22 dB

Carrier hum modulation Not greater than –23 dBc (7.0%)

Burst noise Not longer than 10 µs at a 1 kHz average rate for mostcases (Notes 3 and 4)

Amplitude ripple (maximum) 5-65 MHz: 2.5 dB in 2 MHz

Group delay ripple (maximum) 5-65 MHz: 300 ns in 2MHz

Micro-reflections (maximum) – Single echo –10 dBc @ ≤ 0.5 µs

–20 dBc @ ≤ 1.0 µs

–30 dBc @ > 1.0 µs

Seasonal and diurnal signal level variation Not greater than 12 dB min to max

NOTE 1 – Transmission is from the CM output at the customer location to the head-end.

NOTE 2 – Ingress avoidance or tolerance techniques MAY be used to ensure operation in the presence of time-varyingdiscrete ingress signals that could be as high as 0 dBc.

NOTE 3 – Amplitude and frequency characteristics sufficiently strong to partially or wholly mask the data carrier.

NOTE 4 – Impulse noise levels more prevalent at lower frequencies (<15 MHz).

386


F.5 Communication Protocols

Refer to Section 5.

F.6 Physical Media Dependent Sublayer Specification

F.6.1 Scope

This section applies to the second technology option referred to in Section 1 (1.1 Scope). In those cases wherethe requirement for both technology options are identical, a reference is provided to the main text.

Whenever any reference in this section to spurious emissions conflicts with any legal requirement for the area ofoperation, the latter shall take precedence.

F.6.2 Upstream

F.6.2.1 Overview


F.6.2.2 Signal Processing Requirements


F.6.2.3 Modulation Formats


F.6.2.4 R-S Encode

F.6.2.4.1 R-S Encode Modes


F.6.2.4.2 R-S Bit-to-Symbol Ordering


F.6.2.5 R-S Frame Structure


F.6.2.5.1 R-S Codeword Length


387


F.6.2.5.1.1 Burst Size

Refer to Section 6.2.5.1.1.

F.6.2.5.1.2 Fixed Codeword Length


F.6.2.5.1.3 Shortened Last Codeword


F.6.2.5.2 R-S FEC Disabled

Refer to Section 6.2.5.2.1

F.6.2.6 TDMA Byte Interleaver


F.6.2.6.1 Byte Interleaver Parameters


F.6.2.6.2 Interleaver Operating Modes


F.6.2.6.2.1 Fixed Mode


F.6.2.6.2.2 Dynamic Mode


F.6.2.6.2.2.1 Dynamic Mode Calculations

Refer to Section 6.2.6.2.2.1.

F.6.2.7 Scrambler (Randomizer)


1. Added “Burst Size” and “R-S FEC Disabled” per ECN RFI2-N-02210, by GO, on 11/22/02.

388


F.6.2.8 TCM Encoder


F.6.2.8.1 TCM R-S Bytes to Symbol Mapping


F.6.2.9 Preamble Prepend


F.6.2.10 Modulation Rates


F.6.2.11 S-CDMA Framer and Interleaver

F.6.2.11.1 S-CDMA Framing Considerations


F.6.2.11.2 Mini-slot Numbering


F.6.2.11.2.1 Mini-slot Numbering Parameters in UCD


F.6.2.11.2.2 Mini-slot Numbering Examples


F.6.2.11.3 Transmission Time


F.6.2.11.4 Latency Considerations


F.6.2.11.5 Spreader-off Bursts for Maintenance on S-CDMA channel


F.6.2.12 S-CDMA Framer


389


F.6.2.12.1 Subframe Definition


F.6.2.12.2 Framer Operation


F.6.2.12.2.1 Rules for Preamble and Coded TCM Symbols


F.6.2.12.2.2 Rules for Uncoded Symbols and the Uncoded TCM Subsymbols


F.6.2.12.2.3 Subframe Example


F.6.2.12.2.4 Frame Transmission


F.6.2.13 Symbol Mapping


F.6.2.14 S-CDMA Spreader


F.6.2.14.1 Code Hopping


F.6.2.15 Transmit Pre-Equalizer


F.6.2.16 Spectral Shaping


390


F.6.2.16.1 Upstream Frequency Agility and Range

The upstream PMD sublayer MUST support operation over the frequency range of 5-65 MHz edge to edge.

Offset frequency resolution MUST be supported having a range of ±32 kHz (increment = 1 Hz; implementwithin ±10 Hz).

F.6.2.16.2 Spectrum Format


F.6.2.17 Relative Processing Delays


F.6.2.18 Transmit Power Requirements

The CM MUST support varying the amount of transmit power. Requirements are presented for 1) range ofreported transmit power, 2) step size of power commands, 3) step size accuracy (actual change in output powercompared to commanded change), and 4) absolute accuracy of CM output power. The protocol by which poweradjustments are performed is defined in Section 11.2.4. Such adjustments by the CM MUST be within the rangesof tolerances described below. A CM MUST confirm that the transmit power limits are met after a RNG-RSP isreceived or after a UCD change.

Transmit power is defined as the average RF power in the occupied bandwidth (channel width) transmitted in thedata symbols of a burst, assuming equally likely QAM symbols, measured at the F-connector of the CM.

Maximum and minimum transmit power level requirements refer to the CM’s target transmit power level,defined as the CM’s estimate of its actual transmit power. The actual transmitted power MUST be within ±2 dBof the target power. The target transmit power MUST be variable over the range specified in Table F-5.

Transmit power as reported by the CM in the MIB is referenced to the 64QAM constellation. When transmittingwith other constellations, a slightly different transmit power will result, depending on the constellation gain inTable F-3 (see Section 6.2.13). As an example, if the reported power is 90 dBµV, 64QAM will be transmittedwith a target power of 90 dBµV, while QPSK will be transmitted with 88.82 dBµV.

Table F-3 Constellation Gains and Power Limits

Constellation

ConstellationGain GconstRelative to

64QAM (dB)

Pmin(dBµV)

Pmax(dBµV)TDMA

Pmax(dBµV)

S-CDMA

Pmin -Gconst(dBµV)

Pmax -Gconst(dBµV)TDMA

Pmax -Gconst(dBµV)

S-CDMA

QPSK -1.18 68 118 113 69.18 119.18 114.18

8QAM -0.21 68 115 113 68.21 115.21 113.21

16QAM -0.21 68 115 113 68.21 115.21 113.21

32QAM 0.00 68 114 113 68.00 114.00 113.00

64QAM 0.00 68 114 113 68.00 114.00 113.00

128QAM 0.05 68 N/A 113 67.95 N/A 112.95

391


F.6.2.18.1 TDMA Transmit Power Calculations

In TDMA mode, the CM determines its target transmit power Pt as follows. Define:

Pr = Reported power level (dBµV) of CM in MIB (refers to 64QAM constellation)∆P = Power level adjustment (dB); for example, as commanded in ranging response messageGconst = Constellation gain (dB) relative to 64QAM constellation (see above table)Pmin = Minimum target transmit power permitted for the CM per Section 6.2.21.1 (see above table)Pmax = Maximum target transmit power permitted for the CM per Section 6.2.21.1 (see above table)Phi = min(Pmax - Gconst) over all burst profiles used by the CM (see above table)Plow = max(Pmin - Gconst) over all burst profiles used by the CM (see above table)Pt = Target transmit power level (dBµV) of CM (actual transmitted power as estimated by CM)



The CM then transmits with target power Pt = Pr + Gconst , i.e., the reported power plus the constellation gain.

Usually the reported power level is a relatively constant quantity, while the transmitted power level variesdynamically as different burst profiles, with different constellation gains, are transmitted. A CM’s target transmitpower MUST never be below Pmin or above Pmax . This implies that in some cases the extreme transmit powerlevels (e.g., 118 dBµV for QPSK and 68 dBµV) may not be permitted if burst profiles with multipleconstellations are active. Also, if only QPSK is used, the reported power may be greater than 118 dBµV, althoughthe target transmit power will not exceed 118 dBµV.

For example, if only QPSK and 64QAM burst profiles are active, Phi = 114 dBµV and Plow = 69.2 dBµV. Themaximum permitted QPSK transmitted power is 114 - 1.2 = 112.8 dBµV, the minimum QPSK power is 69.2 - 1.2= 68 dBµV, the maximum 64QAM power is 114 dBµV, and the minimum 64QAM power is 69.2 dBµV.

F.6.2.18.2 S-CDMA Transmit Power Calculations

In S-CDMA mode, the CM determines its target transmit power Pt as follows. Define:

Phi = min[Pmax - Gconst] over all burst profiles used by the CM (see above table)Plow = max[Pmin - Gconst] + 10 log(number_active_codes / number_of_codes_per_mini-slot)where the maximum is over all burst profiles used by the CM (see above table)



In a spreader-on frame, the CM then transmits each code i with target power

Pt,i = Pr + Gconst,i - 10 log(number_active_codes)

i.e., the reported power plus the constellation gain Gconst,i of that code, less a factor taking into account thenumber of active codes. The total transmit power Pt in a frame is the sum of the individual transmit powers Pt,i ofeach code, where the sum is performed using absolute power quantities (non-dB domain).

392


In a spreader-off frame, the CM target transmit power is Pt = Pr + Gconst .

The transmitted power level varies dynamically as the number of allocated codes varies, and as different burstprofiles, with different constellation gains, are transmitted. A CM’s target transmit power MUST never be belowPmin or above Pmax , including over all numbers of allocated codes and all burst profiles. This implies that insome cases the extreme transmit power levels (e.g., 68 and 113 dBµV) may not be permitted. Also if, forexample, only QPSK is used, the reported power may be greater than 113 dBµV, although the target transmitpower will not exceed 113 dBµV.

If, for example, QPSK and 64QAM burst profiles are active, Phi = 113 dBµV and Plow = 69.2 dBµV. Themaximum permitted QPSK transmitted power is 113 - 1.2 = 111.8 dBµV when all active codes are transmitted,the minimum QPSK power is 69.2 - 1.2 = 68 dBµV when one mini-slot is transmitted, the maximum 64QAMpower is 113 dBµV when all active codes are transmitted, and the minimum 64QAM power is 69.2 dBµV withone mini-slot transmitted. The minimum QPSK power permitted while transmitting, for example, 2 minislots is71 dBµV, and the minimum 64QAM power permitted while transmitting 2 minislots is 72.2 dBµV.

The CM needs to implement some form of clipping on the transmitted waveform at the higher output powers inorder to prevent peak to average ratio (PAR) issues.

The power received at the CMTS in a spreader-on frame will sometimes be less than the nominal power of aspreader-off frame because of such factors as 1) broadcast opportunities not used by any CM, 2) unicast grantsnot used by one or more CMs, or 3) mini-slots assigned to the NULL SID.

F.6.2.18.3 Transmit Power Step Size

The step resolution in transmit power MUST be 1dB or less. When a CM is commanded with finer resolutionthan it can implement, it MUST round to the nearest supported step size. If the commanded step is half waybetween two supported step sizes, the CM MUST choose the smaller step. For example, with a supported stepresolution of 1 dB, a command to step ± 0.5 dB would result in no step, while a command to step ± 0.75 dBwould result in a ±1 dB step.

The step size accuracy MUST be within ± 0.4 dB. For example, the actual power increase resulting from acommand to increase the power level by 1 dB in a CM's next transmitted burst MUST be between 0.6 dB and1.4 dB.

A relaxation in step size accuracy to ±1.4 dB is allowed for one gain change when changing the powerthroughout the full power control range in either direction (from low-end to high-end power and vice versa). Thelocations of these two gain changes with relaxed accuracy MUST be at least 2 dB apart, thus enabling the use oflarge step attenuators in the coverage of the full power control range (hysteresis effect).

F.6.2.19 Burst Profiles

The transmission characteristics are separated into three portions: a) Channel Parameters, b) Burst ProfileAttributes, and c) User Unique Parameters. The Channel Parameters include i) the modulation rate (six ratesfrom 160 ksym/sec to 5.12 Msym/sec in octave steps), ii) the center frequency (Hz), iii) the 1536-bit PreambleSuperstring, and iv) the S-CDMA channel parameters. The Channel Parameters are further described in Section8.3.3 Table 8-18; these characteristics are shared by all users on a given channel. The Burst Profile Attributes arelisted in Table F-4 and are further described in Section 8.3.3 Table 8-19; these parameters are the sharedattributes corresponding to a burst type. The User Unique Parameters may vary for each user even when usingthe same burst type on the same channel as another user (for example, Power Level), and are listed in Table F-5.

The CM MUST generate each burst at the appropriate time as conveyed in the mini-slot grants provided by theCMTS MAPs (Section 8.3.4).

393


The CM MUST support all burst profiles commanded by the CMTS via the Burst Descriptors in the UCD(Section 8.3.3), and subsequently assigned for transmission in a MAP (Section 8.3.4).

Table F-4 Burst Profile Attributes

Burst Profile Attributes Configuration Settings

Modulation QPSK, 8 QAM, 16 QAM, 32 QAM,64 QAM, 128 QAM(TCM Only)

Differential Encoding On/Off

TCM Encoding On/Off

Preamble Length 0-1536 bits (Note Section F.6.2.9)

Preamble Value offset 0 to 1534

R-S FEC Error Correction (T) 0 to 16 (0 implies no R-S FEC.The number of codeword parity bytesis 2*T)

R-S FEC Codeword Information Bytes (k) Fixed: 16 to 253 (assuming R-S FEC on)Shortened: 16 to 253 (assuming FEC on)

Scrambler Seed 15 bits

Maximum Burst Length (mini-slots)1

1. A burst length of 0 mini-slots in the Channel Profile means that the burst length isvariable on that channel for that burst type. The burst length, while not fixed, is grantedexplicitly by the CMTS to the CM in the MAP.

0 to 255

Guard Time 4 to 255 modulation intervals

1 for S-CDMA channels

Last Codeword Length Fixed, shortened

Scrambler On/Off On/Off

Interleaver Width (Nr) (RS CodewordLength, k+2*T)

18 to 255

Byte Interleaver Depth (Ir)2

2. If depth=1, no interleaving; if depth=0, dynamic mode.

0 - Dynamic Mode1 - No Interleaving2 to floor(2048/Nr)

3

for Fixed Mode

3. Nr is the R-S codeword size k+2T as defined in Section F.6.2.6.1.

Byte Interleaver Block Size (Br)4

4. Used only in dynamic mode

2*Nr to 2048

Interleaver Packet Size (Nf), (in bytes,including FEC)

≥ 18 bytes

S-CDMA Spreader5 On/Off

S-CDMA Codes per Subframe5

5. Used only for S-CDMA channels.

1 to 128

S-CDMA Interleaver Step5 1 to (spreading intervals per frame - 1)

394


F.6.2.19.1 Ranging Offset

Ranging Offset is the delay correction applied by the CM to the CMTS Upstream Frame Time derived at the CM.It is an advancement equal to roughly the round-trip delay of the CM from the CMTS, and is needed tosynchronize upstream transmissions in the TDMA and S-CDMA schemes. The CMTS MUST provide feedbackcorrection for this offset to the CM, based on reception of one or more successfully received bursts (i.e.,satisfactory result from each technique employed: error correction and/or CRC), with resolution of 1/16384 ofthe frame tick increment (6.25 µsec/(64*256) = 0.381469726 nsec). The CMTS sends adjustments to the CM,where a negative value implies the Ranging Offset is to be decreased, resulting in later times of transmission atthe CM.

For TDMA channels the CM MUST implement the correction with resolution of at most 1 symbol duration (ofthe symbol rate in use for a given burst), and (other than a fixed bias) with accuracy within ±0.25 µsec plus ±1/2symbol owing to resolution. As an example, for the maximum symbol rate of 5,120 ksps, the correspondingsymbol period would be 195 ns, the corresponding maximum resolution for the timing correction MUST be 195ns, and the corresponding minimum accuracy MUST be ±348 ns. The accuracy of CM burst timing of ±0.25 µsecplus ±1/2 symbol is relative to the mini-slot boundaries derivable at the CM based on an ideal processing of thetimestamp signals received from the CMTS.

For S-CDMA channels the CM MUST implement the ranging offset correction to within ±0.01of the nominalchip period. As an example, for the maximum chip rate of 5,120 kHz, the corresponding maximum resolution forthe timing correction would be 195 ns * (±0.01) or roughly ±2ns.

F.6.2.19.2 TDMA Reconfiguration Times


Table F-5 User Unique Burst Parameters

User Unique Parameter Configuration Settings

Power Level TDMA:

+68 to +114 dBµV (32QAM, 64QAM)+68 to +115 dBµV (8QAM, 16QAM)+68 to +118 dBµV (QPSK)

S-CDMA:

+68 to +113 dBµV (all modulations)

1-dB steps

Offset Frequency1

1. The CM MUST implement the Offset Frequency to within ±10 Hz.

Range = ±32 kHz; increment = 1 Hz;implement within ±10 Hz

Ranging Offset Integer part: 0 to (216 - 1), increments of6.25 µsec/64

Fractional part: unsigned 8-bit fractionalextension, units of 6.25 µsec/(64*256) =0.38146973 nsec

Burst Length (mini-slots) if variable on thischannel (changes burst-to-burst)

1 to 255 mini-slots

Transmit Equalizer Coefficients Up to 64 coefficients;

4 bytes per coefficient: 2 real, 2 imaginary

395


F.6.2.19.3 S-CDMA Reconfiguration Times


F.6.2.19.4 CM Timing Offsets When Changing Modulation Rate

Refer to Section 6.2.19.4.1

F.6.2.20 Burst Timing Convention


F.6.2.21 Fidelity Requirements

The following requirements assume that any pre-equalization is disabled unless otherwise noted.

F.6.2.21.1 Spurious Emissions

The spurious emissions specifications are separated into two regions based on the transmit power. Region 1 isdefined to have a power range of +74 dBµV to (Pmax - 3), i.e., the central region. Region 2 is defined from +68dBµV to +74 dBµV and (Pmax - 3) to Pmax, i.e., the low and high ends of the transmit power. Pmax depends on themodulation order, per Table F-5, as follows: for TDMA, +118 dBµV for QPSK, +115 dBµV for 8QAM/16QAM, +114 dBµV for 32QAM/64QAM, and +113 dBµV for all modulations of S-CDMA.

For S-CDMA mode, when a modem is transmitting fewer than 4 spreading codes, the Region 2 specifications areused for all transmit power levels. Otherwise, for all other numbers of spreading codes (e.g., 4 to 128) or forTDMA mode, the spurious emissions specifications are used according to the power ranges defined for Regions1 and 2 above.

In addition, for S-CDMA, the spurious emission specifications for S-CDMA MUST be met for anynumber_allocated_codes, as defined in Section F.6.2.19.

The noise and spurious power MUST NOT exceed the levels given in Table F-6, Table F-7, and Table F-8.

In Table F-6, in-band spurious includes noise, carrier leakage, clock lines, synthesizer spurious products, andother undesired transmitter products. It does not include ISI. The measurement bandwidth for Inband spurious isequal to the modulation rate (e.g., 160 to 5120 kHz). All requirements expressed in dBc are relative to the actualtransmit power that the CM emits.

The measurement bandwidth for the three (or fewer) Carrier-Related Frequency Bands (below 65 MHz) is 160kHz, with up to three 160 kHz bands, each with no more than the value given in Table F-6, allowed to beexcluded from the “Bands within 5 to 65 MHz Transmitting Burst” specs of Table F-8. Carrier-related spuriousemissions include all products whose frequency is a function of the carrier frequency of the upstreamtransmission, such as but not limited to carrier harmonics.

The measurement bandwidth is also 160 kHz for the Between Bursts specs of Table F-6 below 65 MHz.

1. Section F.6.2.19.4 added per RFI2-N-02178 by RKV on 10/30/02.

396


The Transmitting Burst specs apply during the mini-slots granted to the CM (when the CM uses all or a portionof the grant), and for 32 modulation intervals before and after the granted mini-slots. The Between Bursts specsapply except during a used grant of mini-slots, and the 32 modulation intervals before and after the used grant.

In TDMA mode, a mini-slot may be as short as 32 modulation intervals, or 6.25 microseconds at the 5.12 Msym/sec rate, or as short as 200 microseconds at the 160 ksym/sec rate.

Table F-6 Spurious Emissions

1. These spec limits exclude a single discrete spur related to the tuned received channel; this single discrete spur MUST NOTbe greater than 20 dBµV.

2. “dB ref d/s” is relative to the received downstream signal level. Some spurious outputs are proportional to the receive signallevel.

3. The frequencies from 108 to 136 MHz may be forbidden due to national regulations.

4. These specification limits exclude three or fewer discrete spurs. Such spurs must not be greater than 20 dBµV.

F.6.2.21.1.1 Adjacent Channel Spurious Emissions

Spurious emissions from a transmitted carrier may occur in an adjacent channel which could be occupied by acarrier of the same or different modulation rate. The following table lists the required adjacent channel spuriousemission levels for all combinations of transmitted carrier modulation rates and adjacent channel modulationrates. The measurement is performed in an adjacent channel interval that is of appropriate bandwidth anddistance from the transmitted carrier based on the modulation rates of the transmitted carrier and the carrier in theadjacent channel.

Parameter Transmitting Burst Between Bursts

Inband. -40 dBc The greater of -72 dBc or +1 dBµV

Adjacent Band See Table F-7 The greater of -72 dBc or +1 dBµV

3 or Fewer Carrier-Related Frequency Bands(such as second harmonic, if < 65 MHz)

Region 1: -50 dBc fortransmitted modulationrate = 320 kHz andabove; -47 dBc fortransmitted modulationrate = 160 kHz

Region 2: -47 dBc

The greater of -72 dBc or +1 dBµV

Bands within 5 to 65 MHz (excluding assignedchannel, adjacent channels, and carrier-relatedchannels)

See Table F-8 The greater of -72 dBc or +1 dBµV

CM Integrated Spurious Emissions Limits (all in250 kHz, includes discretes)

87.5 to 108 MHz30 dBµV 1 dBµV

CM Integrated Spurious Emissions Limits (all in4.75 MHz, includes discretes 1)

65 to 87.5 MHz

108 to 136 MHz

136 to 862 MHz

max –40 dBc, 34 dBµV

20 dBµV

15 dBµV

34 dBµV

15 dBµV

max (15 dBµV, –40 dB ref d/s 2)

CM Discrete Spurious Emissions Limits 1)

65 to 87.5 MHz

108 to 862 MHz

max –50 dBc, 24 dBµV

10 dBµV

24 dBµV

10 dBµV

397


Table F-7 Adjacent Channel Spurious Emissions Relative to the Transmitted Burst Power Level

F.6.2.21.1.2 Spurious Emissions in 5 to 65 MHz

Spurious emissions, other than those in an adjacent channel or carrier related emissions listed above, may occurin intervals (frequency bands) that could be occupied by other carriers of the same or different modulation rates.To accommodate these different modulation rates and associated bandwidths, the spurious emissions aremeasured in an interval equal to the bandwidth corresponding to the modulation rate of the carrier that could betransmitted in that interval. This interval is independent of the current transmitted modulation rate.

The following table lists the possible modulation rates that could be transmitted in an interval, the requiredspurious level in that interval, and the initial measurement interval at which to start measuring the spuriousemissions. Measurements should start at the initial distance and be repeated at increasing distance from thecarrier until the upstream band edge, 5 MHz or 65 MHz, is reached. Measurement intervals should not includethe three or fewer carrier related emission bands excluded above.

Table F-8 Spurious Emissions in 5 to 65 MHz Relative to the Transmitted Burst Power Level

F.6.2.21.2 Spurious Emissions During Burst On/Off Transients

Each transmitter MUST control spurious emissions, prior to and during ramp up and during and following rampdown, before and after a burst.

On/off spurious emissions, such as the change in voltage at the upstream transmitter output due to enabling ordisabling transmission, MUST be no more than 100 mV, and such a step MUST be dissipated no faster than 2 µsof constant slewing. This requirement applies when the CM is transmitting at +115 dBµV or more; at backed-offtransmit levels, the maximum change in voltage MUST decrease by a factor of 2 for each 6-dB decrease ofpower level from +115 dBµV, down to a maximum change of 7 mV at +91 dBµV and below. This requirementdoes not apply to CM power-on and power-off transients.

Transmitted carriermodulation rate

Specification in theinterval, Region 1

Specificationin the

interval,Region 2

Measurement intervaland distance from carrier

edgeAdjacent channel carrier

modulation rate

-47 dBc -45 dBc 20 kHz to 180 kHz 160 kSymb/s


All modulation rates -46 dBc -45 dBc 80 kHz to 720 kHz 640 kSymb/s




Possible modulationrate in this interval


Region 1


Region 2Initial measurement interval and

distance from carrier edge

160 kSymb/s -54 dBc -53 dBc 220 kHz to 380 kHz






398


F.6.2.21.3 Modulation Error Ratio (MER)

MER measures the cluster variance caused by the transmit waveform at the output of the ideal receive matchedfilter. It includes the effects of ISI, spurious, phase noise, and all other transmitter degradations. For TDMA thematched filter is a square-root raised cosine filter with an alpha = 0.25. For S-CDMA, the matched filter is asquare-root raised cosine filter with alpha = 0.25, convolved with the time-reversed spreading code sequence.MER includes the effects of ISI, spurious, phase noise, and all other transmitter degradations.

F.6.2.21.3.1 Definitions

Symbol MER: MERsymb is defined in Section 6.2.21.3.1, “Definitions”.

F.6.2.21.3.2 Requirements

Unless otherwise stated, the MER MUST meet or exceed the following limits over the full transmit power rangeof Table 6-8 for each modulation, each modulation rate, and over the full carrier frequency range, and for S-CDMA, over any valid number of active and allocated codes. The 5-65 MHz carrier frequency range refers moreprecisely to [5 MHz + modulation rate * 1.25 / 2] to [65 MHz - modulation rate * 1.25 / 2]. At the break pointsbetween regions, the higher MER specification applies.

Case 1: Flat Channel, transmit equalization OFF

Case 1a: for modulation rates 2.56 MHz and below

MERsymb ≥ 30 dB over 15 to 47 MHz carrier frequency

MERsymb ≥ 27 dB over 10 MHz to 15 MHz and 47 MHz to 54 MHz carrier frequency


Case 1b: for modulation rate 5.12 MHz

MERsymb ≥ 27 dB over 15 to 47 MHz carrier frequency



Case 2: Flat channel, transmit equalization ON

Case 2a: for TDMA/QPSK, MERsymb ≥ 30 dB.

Case 2b: for S-CDMA and all TDMA modulations except QPSK, MERsymb ≥ 35 dB.

Case 2c: for S-CDMA, MERchip ≥ 33 dB.

Case 3: Echo channel, transmit equalization ON

Case 3a: In the presence of a single echo selected from the channel micro-reflections defined in Table 4-2 onpage 26, the measured MERsymb MUST be ≥ 33 dB for TDMA/QPSK, and ≥ 33 dB for S-CDMA and allTDMA modulations except QPSK.

Case 3b: In the presence of two or three of the echoes defined in Table 4-2 on page 26 (at most one of eachspecified magnitude and delay), the measured MERsymb MUST be ≥ 29 dB. Since the table does not boundecho delay for the -30 dBc case, for testing purposes it is assumed that the time span of the echo at thismagnitude is less than or equal to 1.5 µs.

399


F.6.2.21.4 Filter Distortion


F.6.2.21.4.1 Amplitude


F.6.2.21.4.2 Phase


F.6.2.21.5 Carrier Phase Noise


F.6.2.21.6 Channel Frequency Accuracy


F.6.2.21.7 Modulation Rate Accuracy


F.6.2.21.8 Modulation Timing Jitter

F.6.2.21.8.1 Symbol Timing Jitter for Asynchronous Operation


F.6.2.21.8.2 Chip Timing Jitter for Synchronous Operation

All jitter specifications assume a downstream input to the CM per Section F.6.3.5, Section F.6.3.6, SectionF.6.3.7.2, Section F.6.3.7.3, Section F.6.3.9, and Section F.6.3.10.

For S-CDMA mode, upstream chip clock timing error (with the mean error subtracted out) relative to the CMTSmaster clock MUST be less than 0.005 RMS of the chip period over a 35-second measurement interval. Thisapplies 1) to the worst-case jitter and frequency drift specified for the CMTS Master clock and the CMTSdownstream symbol clock in the requirements above and 2) for any round-trip propagation delay up to themaximum allowed.

The CM upstream chip clock SHOULD track the jitter components below 10 Hz in the input downstream symbolclock with an error transfer function below -25 dB. The CM upstream chip clock SHOULD attenuate the jittercomponents in the input downstream symbol clock above 200 Hz.

F.6.2.22 Upstream Demodulator Input Power Characteristics

The maximum total input power to the upstream demodulator MUST NOT exceed 95 dBµV in the 5-65 MHzfrequency range of operation.

400


The intended received power in each carrier MUST be within the values shown in Table F-9.

Table F-9 Maximum Range of Commanded Nominal Receive Power in Each Carrier

The demodulator MUST operate within its defined performance specifications with received bursts within ±6 dBof the nominal commanded received power.

F.6.2.23 Upstream Electrical Output from the CM

The CM MUST output an RF modulated signal with the characteristics delineated in Table F-10.

Table F-10 Electrical Output from CM

F.6.3 Downstream

F.6.3.1 Downstream protocol

The downstream PMD sublayer MUST conform to [EN 300 429].

F.6.3.2 Interleaving

The downstream PMD sublayer MUST support the interleaver with the characteristics defined in Table F-11.This interleaver mode fully complies with [EN 300 429].

Modulation Rate(kSymb/s)

Maximum Range(dBµV)

160 +44 to +74

320 +47 to +77

640 +50 to +80

1,280 +53 to +83

2,560 +56 to +86

5,120 +59 to +89

Parameter Value

Frequency 5 to 65 MHz edge to edge

Level range (one channel) TDMA:

+68 to +114 dBµV (32QAM, 64QAM)+68 to +115 dBµV (8QAM, 16QAM)+68 to +118 dBµV (QPSK)

S-CDMA:

+68 to +113 dBµV (all modulations of S-CDMA)

Modulation Type QPSK, 8QAM, 16QAM, 32QAM, 64QAM, and 128QAM

Modulation Rate (nominal) TDMA: 160, 320, 640, 1280, 2560 and 5120 kSymb/s

S-CDMA: 1280, 2560 and 5120 kSymb/s

Channel Bandwidth TDMA: 200, 400, 800, 1600, 3200 and 6400 kHz

S-CDMA: 1600, 3200 and 6400 kHz

Nominal Output impedance 75 ohms

Output Return Loss > 6 dB (5-65 MHz)

Connector F connector per [ISO-169-24] (common with the input)

401


Table F-11 Interleaver characteristics

F.6.3.3 Downstream frequency plan

The downstream frequency plan will include all center frequencies between 112 and 858 MHz on 250 kHzincrements. It is up to the operator to decide which frequencies to use to meet national and network requirements.

F.6.3.4 CMTS output electrical

The CMTS MUST output an RF modulated signal with the following characteristics defined in Table F-12.

I(Number of taps)

J(Increment)

Burst protection64QAM/256QAM

Latency64QAM/256QAM

12 17 18 µs/14 µs 0.43 ms/0.32 ms

402


Table F-12 CMTS output

F.6.3.5 Downstream electrical input to CM

The CM MUST accept an RF modulated signal with the following characteristics (see Table F-13).

Parameter Value

Center Frequency (fc) 112 to 858 MHz ± 30 kHz

Level Adjustable over the range 110 to 121 dBµV

Modulation type 64QAM and 256QAM

Symbol rate (nominal)

64QAM

256QAM

6.952 Msym/s

6.952 Msym/s

Nominal channel spacing 8 MHz

Frequency response

64QAM

256QAM

∼ 0.15 square root raised cosine shaping

∼ 0.15 square root raised cosine shaping

Total discrete spurious In-band (fc ± 4 MHz) < –57 dBc

In-band spurious and noise (fc ± 4 MHz) < –46.7 dBc; where channel spurious and noise includes all discretespurious, noise, carrier leakage, clock lines, synthesizer products, andother undesired transmitter products. Noise within ± 50 kHz of the carrieris excluded.

Adjacent channel (fc ± 4.0 MHz) to(fc ±4.75 MHz)

< –58 dBc in 750 kHz.

Adjacent channel (fc ± 4.75 MHz) to(fc ±12 MHz)

< –60.6 dBc in 7.25 MHz, excluding up to 3 spurs, each of which must be< −60 dBc when each is measured with 10 kHz bandwidth.

Next adjacent channel (fc ± 12 MHz) to(fc ± 20 MHz)

Less than the greater of –63.7 dBc or 49.3 dBµV in 8 MHz, excluding upto three discrete spurs. The total power in the spurs must be < –60 dBcwhen each is measured with 10 kHz bandwidth.

Other channels (80 MHz to 1000 MHz) < 49.3 dBµV in each 8 MHz channel, excluding up to three discrete spurs.The total power in the spurs must be < − 60 dBc when each is measuredwith 10 kHz bandwidth.

Phase noise 1 kHz-10 kHz: –33 dBc double sided noise power

10 kHz-50 kHz: –51 dBc double sided noise power

50 kHz-3 MHz: –51 dBc double sided noise power

Output impedance 75 ohms

Output return loss > 14 dB within an output channel up to 750 MHz; > 13 dB in an outputchannel above 750 MHz

Connector F connector per [ISO-169-24]

403


Table F-13 Electrical input to CM

F.6.3.6 CM BER performance

The bit-error-rate performance of a CM MUST be as described in this section. The requirements apply to theI = 12, J = 17 mode of interleaving.

F.6.3.6.1 64QAM

F.6.3.6.1.1 64QAM CM BER Performance


when operating at a carrier to noise ratio (Es/No) of 25.5 dB or greater.

F.6.3.6.1.2 64QAM image rejection performance

Performance as described in Section F.6.3.6.1.1 MUST be met with analogue or digital signal at +10 dBc in anyportion of the RF band other than the adjacent channels.

F.6.3.6.1.3 64QAM Adjacent channel performance

Performance as described in Section F.6.3.6.1.1 MUST be met with digital signal at 0 dBc in the adjacentchannels.

Performance as described in Section F.6.3.6.1.1 MUST be met with analogue signal at +10 dBc in the adjacentchannels.

Performance as described in Section F.6.3.6.1.1, with an additional 0.2-dB allowance, MUST be met with digitalsignal at +10 dBc in the adjacent channels.

Parameter Value

Center Frequency 112 to 858 MHz ± 30 kHz

Level Range (one channel) 43 to 73 dBµV for 64QAM

47 to 77 dBµV for 256QAM


Symbol Rate (nominal) 6.952 Msym/s (64QAM) and 6.952 Msym/s (256QAM)

Bandwidth 8 MHz (alpha = 0.15 square root raised cosine shaping for 64QAM and alpha= 0.15 square root raised cosine shaping for 256QAM)

Total Input Power (80-862 MHz) < 90 dBµV

Input (load) Impedance 75 ohms

Input Return Loss > 6 dB (85 to 862 MHz)

Connector F connector per [ISO-169-24] (common with the output)

404


F.6.3.6.2 256QAM

F.6.3.6.2.1 256QAM CM BER Performance

Implementation loss of the CM MUST be that the CM achieves a post-FEC BER less than or equal to 10-8 whenoperating at a carrier to noise ratio (Es/No) as shown in Table F-14.

Table F-14 256QAM CM BER performance

F.6.3.6.2.2 256QAM image rejection performance

Performance as described in Section F.6.3.6.2.1 MUST be met with analogue or digital signal at +10 dBc in anyportion of the RF band other than the adjacent channels.

F.6.3.6.2.3 256QAM adjacent channel performance

Performance as described in Section F.6.3.6.2.1 MUST be met with analogue or digital signal at 0 dBc in theadjacent channels.

Performance as described in Section F.6.3.6.2.1, with an additional 0.5-dB allowance, MUST be met withanalogue signal at +10 dBc in the adjacent channels.

Performance as described in Section F.6.3.6.2.1, with an additional 1.0-dB allowance, MUST be met with digitalsignal at +10 dBc in the adjacent channels.

F.6.3.6.2.4 Additional specifications for QAM

The following additional specifications are given for the QAM-modulation.

F.6.3.7 CMTS timestamp jitter


F.6.3.7.1 CMTS Master Clock Jitter for Asynchronous Operation


Input receive signal level Es/No

47 dBµV to 54 dBµV 34.5 dB

> 54 to +77 dBµV 31.5 dB

Parameter Specification

I/Q Phase offset < 1.0 °

I/Q crosstalk -50 dB

I/Q Amplitude imbalance 0.05 dB max

I/Q timing skew < 3.0 nsec

405


F.6.3.7.2 CMTS Master Clock Jitter for Synchronous Operation


F.6.3.7.3 CMTS Master Clock Frequency Drift for Synchronous Operation


F.6.3.8 CMTS Clock Generation

The CMTS has the following three options related to the synchronization of the CMTS Master Clock and theDownstream Symbol Clock:

1. Not locked.

2. Downstream Symbol Clock locked to CMTS Master Clock.

3. CMTS Master Clock locked to Downstream Symbol Clock.

For S-CDMA operation the Master Clock and the Downstream Symbol Clock MUST be locked using eitheroption 2 or 3.

Let fb' represent the rate of the Downstream Symbol Clock which is locked to the CMTS Master Clock and let fm

'

represent the rate of the CMTS Master Clock locked to the Downstream Symbol Clock. Let fb represent thenominal specified downstream symbol rate and let fm represent the nominal CMTS Master Clock rate (10.24MHz).

With the Downstream Symbol Clock locked to the CMTS Master Clock the following equation MUST hold:

fb' = fm*M/N

With the CMTS Master Clock locked to the Downstream Symbol Clock the following equation MUST hold:

fm' = fb*N/M

M and N MUST be unsigned integer values each representable in 16 bits. (These are specified in the channelTLV parameters of the UCD). When the Downstream Symbol Clock and the CMTS Master Clock are not lockedtogether (Sync mode = 0), the values of M and N are not valid and are ignored by the CM.

The values of M and N MUST result in a value of fb' or fm

' which is not more than ±1 ppm from its specifiednominal value. Table F-15 lists the downstream modes of operation, their associated nominal symbol rates, fb,example values for M and N, the resulting synchronized clock rates, and their offsets from their nominal values.

406


Table F-15 Downstream symbol rates and example parameters for synchronization with the CMTSMaster Clock

F.6.3.9 Downstream Symbol Clock Jitter for Synchronous Operation

The downstream symbol clock MUST meet the following double sideband phase noise requirements over thefollowing frequency ranges:

< [-50 + 20*log(fDS/6.952)] dBc (i.e., < 0.07 nsec RMS) 10 Hz to 100 Hz

< [-50 + 20*log(fDS/6.952)] dBc (i.e., < 0.07 nsec RMS) 100 Hz to 1 kHz



< [-27 + 20*log(fDS/6.952)] dBc (i.e., < 1 nsec RMS) 100 kHz to (fDS /2)

where fDS is the frequency of the measured clock in MHz. The value of fDS MUST be an integral multiple ordivisor of the downstream symbol clock. For example, an fDS = 27.808 MHz clock may be measured if there isno explicit 6.952 MHz clock available.

The CMTS MUST provide a test mode in which:

• The downstream QAM symbol sequence is replaced with an alternating binary sequence (1, -1, 1, -1, 1, -1, ...)at nominal amplitude, on both I and Q.

• The CMTS generates the downstream symbol clock from the 10.24 MHz reference clock as in normalsynchronous operation. If an explicit downstream symbol clock which is capable of meeting the above phasenoise requirements is available (e.g., a smooth clock without clock domain jitter), this test mode is notrequired.

F.6.3.10 Downstream Symbol Clock Drift for Synchronous Operation


F.7 Downstream transmission convergence sublayer

F.7.1 Introduction


Downstreammode

NominalSpecified

Symbol Rate, fb(MHz) M/N

CMTS Master ClockRate, fm

' (MHz)Downstream Symbol

Rate, fb' (MHz)

Offset fromNominal

Annex A,64QAM and256QAM(8 MHz)

6.952 869/1280 10.24 6.952 0 ppm

407


F.7.2 MPEG Packet format


F.7.3 MPEG Header for Euro-DOCSIS Data-Over-Cable

The format of the MPEG Transport Stream Header is defined in section 2.4 of [ITU-T H.222.0]. The particularfield values that distinguish Data-Over-Cable MAC streams are defined in Table F-16. Field names are from theITU specification.

The MPEG Header consists of 4 bytes that begin the 188-byte MPEG Packet. The format of the header for use onan Euro-DOCSIS Data-Over-Cable PID is restricted to that shown in Table F-16. The header format conforms tothe MPEG standard, but its use is restricted in this specification to NOT ALLOW inclusion of anadaptation_field in the MPEG packets.

Table F-16 MPEG Header format for Euro-DOCSIS Data-Over-Cable packets

F.7.4 MPEG Payload for Euro-DOCSIS Data-Over-Cable

The MPEG Payload portion of the MPEG Packet will carry the Euro-DOCSIS MAC frames. The first byte of theMPEG payload will be a ‘pointer_field’ if the payload_unit_start_indicator (PUSI) of the MPEG Header is set.

stuff_byte This standard defines a stuff_byte pattern having a value (0xFF) that is used within the Euro-DOCSIS Payload to fill any gaps between the Euro-DOCSIS MAC frames. This value is chosen as an unusedvalue for the first byte of the Euro-DOCSIS MAC frame. The ‘FC’ byte of the MAC Header will be defined tonever contain this value. (FC_TYPE = ‘11’ indicates a MAC-specific frame, and FC_PARM = ‘11111’ is notcurrently used and, according to this specification, is defined as an illegal value for FC_PARM.)

pointer_field The pointer_field is present as the fifth byte of the MPEG packet (first byte following the MPEGheader) whenever the PUSI is set to one in the MPEG header. The interpretation of the pointer_field is asfollows:

The pointer_field contains the number of bytes in this packet that immediately follow the pointer_field that theCM decoder must skip past before looking for the beginning of an Euro-DOCSIS MAC Frame. A pointer fieldMUST be present if it is possible to begin a Data-Over-Cable MAC Frame in the packet, and MUST point toeither:

Field Length (bits) Description

sync_byte 8 0x47; MPEG Packet Sync byte.

transport_error_indicator 1 Indicates an error has occurred in the reception of the packet.This bit is reset to zero by the sender, and set to one wheneveran error occurs in transmission of the packet.

payload_unit_start_indicator 1 A value of one indicates the presence of a pointer_field as thefirst byte of the payload (fifth byte of the packet)

transport_priority 1 Reserved; set to zero.

PID (see Note) 13 Euro-DOCSIS Data-Over-Cable well-known PID (0x1FFE)

transport_scrambling_control 2 Reserved; set to ‘00’.

adaptation_field_control 2 ‘01’; use of the adaptation_field is NOT ALLOWED on theEuro-DOCSIS PID.

continuity_counter 4 Cyclic counter within this PID

408


1. the beginning of the first MAC frame to start in the packet; or

2. any stuff_byte preceding the MAC frame.

F.7.5 Interaction with the MAC sublayer


F.7.6 Interaction with the Physical layer

The MPEG-2 packet stream MUST be encoded according to [EN 300 429].

F.7.7 MPEG Header synchronization and recovery

The MPEG-2 packet stream SHOULD be declared “in frame” (i.e., correct packet alignment has been achieved)when five consecutive correct sync bytes, each 188 bytes from the previous one, have been received.

The MPEG-2 packet stream SHOULD be declared “out of frame”, and a search for correct packet alignmentstarted, when nine consecutive incorrect sync bytes are received.

The format of MAC frames is described in detail in Section 8.

F.8 Media Access Control Specification

F.8.1 Introduction


F.8.2 MAC Frame Formats


F.8.3 MAC Management Messages

F.8.3.1 MAC Management Message Header


F.8.3.2 Time Synchronization (SYNC)

Time Synchronization (SYNC) MUST be transmitted by CMTS at a periodic interval to establish MAC sublayertiming. The message MUST use an FC field with FC_TYPE = MAC Specific Header and FC_PARM = TimingMAC Header. This MUST be followed by a Frame PDU in the format shown in Figure F-1.

409


Figure F-1 Format of Packet PDU Following the Timing Header

The parameters shall be as defined below:

CMTS Timestamp The count state of an incrementing 32 bit binary counter clocked with the CMTS10.24 MHz master clock.

The CMTS timestamp represents the count state at the instant that the first byte (or a fixed time offset from thefirst byte) of the Time Synchronization MAC Management Message is transferred from the DownstreamTransmission Convergence Sublayer to the Downstream Physical Media Dependent Sublayer as described inSection 6.3.7. A CMTS MUST always put the SYNC-message at the start of an MPEG-packet. This is requiredfor compatibility with certain CM implementations.

410


Annex G DOCSIS 2.0 and 1.0/1.1 Interoperability

DOCSIS 2.0 is the third generation of the DOCSIS specification. The terms DOCSIS 2.0, DOCSIS 1.1, andDOCSIS 1.0 refer to these three different specifications.

The DOCSIS 2.0 specification primarily aims at enhancing the limited upstream physical layer performance of aDOCSIS 1.0- or 1.1-based cable access system. Two new MAC Management Message Types have been defined,and several new parameter encodings have been defined in the existing MAC messages. A DOCSIS 2.0 CMTS iscapable of supporting a higher upstream throughput for a given channel bandwidth as well as increased toleranceto noise experienced in the upstream.

As well as supporting DOCSIS 2.0 capable CMs, the DOCSIS 2.0 CMTS must be backwards compatible withDOCSIS 1.0 and DOCSIS 1.1 CMs. Furthermore, it is necessary for a DOCSIS 2.0 CM to function like a 1.0 CMwhen interoperating with a 1.0 CMTS and to function like a 1.1 CM when interoperating with a 1.1 CMTS.

This section describes the interoperability issues and trade-offs involved when the operator wishes to supportDOCSIS 1.0 and/or DOCSIS 1.1 CMs as well as DOCSIS 2.0 CMs on the same cable access channel.

G.1 General Interoperability Issues

This section addresses the general DOCSIS 1.x/2.0 interoperability issues that do not depend on the modulationtype used for the upstream channel.

G.1.1 Provisioning

The parameters of the TFTP configuration file for a DOCSIS 2.0 CM are (except for the addition of one optionalTLV) identical to those for a DOCSIS 1.1 CM, and are a superset of those for a DOCSIS 1.0 CM. Configuration-file editors that support DOCSIS 1.1 may need to be modified to support the new TLV defined in DOCSIS 2.0.

A TFTP configuration file containing Class of Service TLVs is considered a “DOCSIS 1.0 style” configurationfile. A TFTP configuration file containing Service Flow TLVs is considered a “DOCSIS 1.1/2.0 style”configuration file. A TFTP configuration file containing both Class of Service and Service Flow TLVs will berejected by the CMTS (see Section 11.2.9).

If a DOCSIS 2.0 CM is provisioned with a DOCSIS 1.0-style TFTP configuration file, it will register as specifiedin Section G.1.2, although in the REG-REQ it MUST still specify “DOCSIS 2.0” in the DOCSIS VersionModem Capability and MAY specify additional advanced (i.e., DOCSIS 1.1) Modem Capabilities that itsupports. Thus, a DOCSIS 2.0 CM can be provisioned to work seamlessly on either a DOCSIS 1.0, a DOCSIS1.1, or a DOCSIS 2.0 network. However, a DOCSIS 2.0 modem on a DOCSIS 1.x network would be clearlyunable to support any DOCSIS 2.0-specific features.

If a DOCSIS 2.0 CM supports certain advanced capabilities when registered as a DOCSIS 1.0 CM (as indicatedby the Modem Capabilities Encoding), those features MUST function according to the requirements defined inthe DOCSIS 2.0 specifications.

On the other hand, DOCSIS 1.0 CMs do not recognize (and ignore) many of the new TLVs in a DOCSIS 1.1/2.0style config file, and will be unable to register successfully if provisioned with a DOCSIS 1.1/2.0 configurationfile. To prevent any functionality mismatches, a DOCSIS 2.0 CMTS MUST reject any Registration Request withDOCSIS 1.1/2.0-specific configuration parameters that are not supported by the associated Modem Capabilitiesencoding in the REG-REQ (see Section C.1.3.1).

411


G.1.2 Registration

A DOCSIS 2.0 CMTS is designed to handle the registration TLVs from DOCSIS 1.0 CMs as well as the TLVsfrom DOCSIS 1.1 (TLV types 22 to 38) or DOCSIS 2.0 (TLV types 22 to 39) CMs. Furthermore a DOCSIS 2.0CM can handle any TLVs in a configuration file usable by a DOCSIS 1.0 CM.

There is a slight difference in the registration-related messaging procedure when the DOCSIS 2.0 CMTS isresponding to a DOCSIS 1.1 or 2.0 CM as opposed to a DOCSIS 1.0 CM (or a DOCSIS 1.1 CM using a 1.0-styleconfiguration file). There is a further difference in the way a DOCSIS 2.0 CMTS handles registration from aDOCSIS 2.0 CM using a 1.0-style configuration file depending on whether the upstream on which theregistration is occurring has DOCSIS 2.0 features.

A DOCSIS 1.1 or 2.0 CM could be configured to use the Service Class Name which is statically defined at theCMTS instead of explicitly asking for the service class parameters. When the DOCSIS 2.0 CMTS receives sucha Registration-Request, it encodes the actual parameters of that service class in the Registration-Response andexpects the Registration-Acknowledge MAC message from the CM. If the detailed capabilities in theRegistration-Response message exceed those the CM is capable of supporting, the CM is required to indicate thisto the CMTS in its Registration-Acknowledge.

When a DOCSIS 1.0 CM (or a 1.1 CM using a 1.0-style configuration file) registers with the same CMTS, theabsence of Service Class Names eliminates the need for the DOCSIS 2.0 CMTS to explicitly specify the serviceclass parameters in the Registration-Response using DOCSIS 1.1 or 2.0 TLVs. The Registration-Request from aDOCSIS 1.0 CM explicitly requests all non-default service class parameters in the Registration-Request per itsprovisioning information. When a DOCSIS 2.0 CMTS receives a Registration-Request containing DOCSIS 1.0Class of Service Encodings, it will respond with the DOCSIS 1.0-style Registration-Response and, if the CM is aDOCSIS 1.x CM, not expect the CM to send the Registration-Acknowledge MAC message. A DOCSIS 1.0 CMcan be further identified by the absence of the “DOCSIS Version” Modem Capabilities encoding in theRegistration-Request.

In the case where a DOCSIS 2.0 CM is using a DOCSIS 1.0-style configuration file there is an additionalconsideration. This is because in the case where the upstream is a type 2 upstream (see Section 11.2.2) andtherefore supports both TDMA and A-TDMA features the Registration-Acknowledge message is also used tosynchronize switching from TDMA (DOCSIS 1.x) operation to A-TDMA (DOCSIS 2.0) operation. It isimportant that this switch be coordinated correctly between the CM and the CMTS in order for the CMTS to beable to correctly interpret bandwidth requests from the CM (see Section 11.2.9). Therefore, when a DOCSIS 2.0CM registers using a 1.0-style configuration file on a type 2 or type 3 upstream, it transmits a Registration-Acknowledgment with a confirmation code of OK/SUCCESS (since 1.0-style registration does not allow for theCM to reject the Registration-Response). The CMTS knows to expect this because the modem capabilities fieldin the Registration-Request indicated that the CM was a 2.0 CM. The following table summarizes registrationbehavior for all cases involving a DOCSIS 2.0 CM.

412


Another minor issue is that a DOCSIS 1.0 CM will request for a bi-directional (with Upstream/Downstreamparameters) service class from the CMTS using a Class-of-Service Configuration Setting.

Since a DOCSIS 2.0 CMTS typically operates with unidirectional service classes, it can easily translate aDOCSIS 1.0 Class-of-Service Configuration Setting into DOCSIS 1.1 or 2.0 Service Flow Encodings for settingup unidirectional service classes in local QoS implementation. However, for DOCSIS 1.0 modems, the DOCSIS2.0 CMTS MUST continue to maintain the QoSProfile table (with bi-directional Class parameters) for backwardcompatibility with the DOCSIS 1.0 MIB.

Thus, if properly provisioned, a DOCSIS 1.0, a DOCSIS 1.1, and a DOCSIS 2.0 CM can all successfully registerwith the same DOCSIS 2.0 CMTS, and a DOCSIS 2.0 CM can register with a 1.0 CMTS. Furthermore, aDOCSIS 2.0 CM can use a DOCSIS 1.0-style configuration file, register on a DOCSIS 2.0 CMTS and still useDOCSIS 2.0 enhanced physical-layer features with DOCSIS 1.0 class-of-service features.

G.1.3 Dynamic Service Establishment

There are 8 MAC messages that relate to Dynamic Service Establishment. A DOCSIS 1.0 CM will never sendthem to any CMTS since they are unsupported. A DOCSIS 1.1 or 2.0 CM will never send them to a DOCSIS 1.0CMTS because (a) to register successfully it has to be provisioned as a DOCSIS 1.0 CM and (b) whenprovisioned as a DOCSIS 1.0 CM it acts identically. When a DOCSIS 1.1 or 2.0 CM is connected to a DOCSIS1.1 or 2.0 CMTS these messages work as expected.

Table G-1 Registration Behavior for a DOCSIS 2.0 CM

Configuration file DOCSIS 1.0 CMTS

DOCSIS 2.0 CMTS with atype 1 upstream or a

DOCSIS 1.1 CMTSDOCSIS 2.0 CMTS with atype 2 or type 3 upstream

1.1/2.0-style configurationfile that does not disableDOCSIS 2.0 mode

N/A CM sends 1.1/2.0-styleREG-REQ. CMTS sends1.1/2.0-style REG-RESPand CM responds withREG-ACK.

CM sends 1.1/2.0-styleREG-REQ. CMTS sends1.1/2.0-style REG-RESPand CM responds withREG-ACK.

1.0-style configuration filethat does not disableDOCSIS 2.0 mode.

CM sends 1.0-style REG-REQ. CMTS sends 1.0-styleREG-RESP. CM MUSTNOT send REG-ACK.

CM sends 1.0-style REG-REQ. CMTS sends 1.0-styleREG-RESp. CM MUSTNOT send REG-ACK.

CM sends 1.0-style REG-REQ. CMTS sends 1.0-styleREG-RESP. CM MUSTsend REG-ACK withSUCCESS confirmationcode. CMTS MUST wait forREG-ACK.

1.1/2.0-style configurationfile that disables DOCSIS2.0 mode.

N/A CM sends 1.1/2.0-styleREG-REQ. CMTS sends1.1/2.0-style REG-RESPand CM responds withREG-ACK.

CM sends 1.1/2.0-styleREG-REQ. CMTS sends1.1/2.0-style REG-RESPand CM responds withREG-ACK.

1.0-style configuration filethat disables DOCSIS 2.0mode.




413


G.1.4 Fragmentation

Fragmentation is initiated by the CMTS. Thus, a DOCSIS 1.0 CMTS will never initiate fragmentation since itknows nothing about it. A DOCSIS 1.1 or 2.0 CMTS can only initiate fragmentation for DOCSIS 1.1 or 2.0CMs. A DOCSIS 1.1 or 2.0 CMTS MUST NOT attempt to fragment transmissions from a DOCSIS v1.0 CM thathas not indicated a Modem Capabilities encoding for Fragmentation Support with a value of 1.

G.1.5 Multicast Support

It is mandatory for DOCSIS 1.0 CMs to support forwarding of multicast traffic. However, the specification issilent on IGMP support. The only standard mechanism for controlling IP-multicast on DOCSIS 1.0 CMs isthrough SNMP and packet filters. Designers of DOCSIS 1.0 networks will have to deal with these limitationsand expect no different from DOCSIS 1.0 CMs on a DOCSIS 2.0 network.

G.1.6 Changing Upstream Channels

A DOCSIS 2.0 CMTS is capable of specifying the level of re-ranging to be performed only when it issues aDCC-Request to the CM. This re-ranging technique parameter is specified by the DOCSIS 2.0 CMTS using aTLV in the DCC-Request MAC message.

DOCSIS 1.1 or 2.0 CMs can benefit by only re-ranging to the level specified by this TLV. This can help inreducing the reinitialization time following a DCC, for the DOCSIS 1.1 or 2.0 CM carrying a voice call. ADOCSIS 2.0 CMTS is aware of the type of CM to which it is issuing the channel change request. It MUSTrefrain from sending a DCC-Request for DOCSIS 1.0 CMs, instead choosing to send a UCC-Request. If aDOCSIS 2.0 CMTS sends the UCC-Request, the DOCSIS 1.0 CMs will perform the default DOCSIS 1.0 re-ranging from start (Initial-Ranging) with its existing non-zero primary sid.

G.2 Hybrid Devices

Some DOCSIS 1.0 CM designs may be capable of supporting individual DOCSIS 1.1 features via a softwareupgrade. Similarly, some DOCSIS 1.0 CMTSes may be capable of supporting individual DOCSIS 1.1 features.To facilitate these “hybrid” devices, the majority of DOCSIS 1.1 features are individually enumerated in theModem Capabilities.

DOCSIS 1.0 hybrid CMs MAY request DOCSIS 1.1 features via this mechanism. However, unless a CM is fullyDOCSIS 1.1 compliant (i.e., not a hybrid), it MUST NOT send a “DOCSIS Version” Modem Capability whichindicates DOCSIS 1.1. Similarly, unless a CM is fully DOCSIS 2.0 compliant, it MUST NOT send a “DOCSISVersion” Modem Capability which indicates DOCSIS 2.0.

If a hybrid CM intends to request such 1.1 capabilities from the CMTS during registration, it MUST send theASCII coded string in Option code 60 of its DHCP request, “docsis1.0:xxxxxxx”. Where xxxxxxx MUST be anASCII representation of the hexadecimal encoding of the Modem Capabilities. Refer to Sections C.1.3.1 andD.1.1 for details. The DHCP server MAY use such information to determine what configuration file the CM is touse.

In order to control the hybrid operation of modems, if a DOCSIS 2.0 CMTS receives a 1.0-style RegistrationRequest message from a CM, the CMTS MUST, by default, force the modem to operate in a “pure” 1.0 modewith respect to certain features by disabling those features via the Modem Capabilities Encoding in theRegistration Response. Specifically, the CMTS MUST support the six default values given in square brackets inTable G-2. The CMTS MAY provide switches, as indicated in Table G-2, for the operator to selectively allowcertain hybrid features to be enabled.

414


Table G-2 Hybrid Mode Controls

Normally, a DOCSIS 1.0 CMTS sets all unknown Modem Capabilities to “Off” in the Registration Responseindicating that these features are unsupported and MUST NOT be used by the CM. A DOCSIS 1.0 hybrid CMTSMAY leave supported Modem Capabilities set to “On” in the Registration Response. However, unless a CMTS isfully DOCSIS 1.1- or 2.0-compliant (i.e., not a hybrid), it MUST still set all “DOCSIS Version” ModemCapabilities to DOCSIS 1.0.

As always, any Modem Capability set to “Off” in the Registration Response must be viewed as unsupported bythe CMTS and MUST NOT be used by the CM.

G.3 DOCSIS 2.0 TDMA Interoperability

G.3.1 Mixed-mode operation with TDMA

In mixed-mode operation with both DOCSIS 1.x and DOCSIS 2.0 TDMA, a single channel is defined with asingle UCD that contains both type 4 and type 5 burst descriptors. DOCSIS 1.x and 2.0 modems use the type 4burst descriptors; DOCSIS 2.0 modems MUST also use the type 5 burst descriptors. DOCSIS 2.0 modems willuse IUCs 9 and 10.

The following rules of operation apply:

1. Prior to and during registration a DOCSIS 2.0 TDMA capable modem operating on a channel of type 1 or 2(refer to Section 11.2.2) MUST calculate its request size based on DOCSIS 1.x IUC parameters, and theCMTS MUST make all grants using DOCSIS 1.x IUCs.

2. On a type 2 channel, a DOCSIS 2.0 TDMA CM MUST switch to DOCSIS 2.0 TDMA mode aftertransmission of the Registration Acknowledgement (REG-ACK) message. If the CM receives a RegistrationResponse (REG-RSP) message after transmission of the REG-ACK message, the CM MUST switch back toDOCSIS 1.1 mode before it continues with the registration process (see Figure 11-12).

3. A CM in DOCSIS 2.0 TDMA mode MUST calculate its request size based on IUC types 9 & 10. The CMTSMUST make grants of IUC types 9 & 10 to that CM after it receives the Registration Acknowledgementmessage from the CM (see Section 11.2.9).

4. On a type 2 channel, the CM MUST ignore grants with IUCs that are in conflict with its operational mode(e.g., the CM receives a grant with IUC 5 when it is in DOCSIS 2.0 TDMA mode).

5. On a type 3 channel, the CMTS MUST use type 5 burst descriptors in order to prevent DOCSIS 1.x modemsfrom attempting to use the channel. All data grants are in IUC types 9 & 10.

6. On a type 2 channel, only Advanced PHY Short (IUC 9) and Advanced PHY Long (IUC 10) bursts may beclassified as burst descriptor type 5.

7. A DOCSIS 1.x modem that does not find appropriate type 4 burst descriptors for long or short data grantintervals MUST consider the UCD, and the associated upstream channel, unusable.

Concatenation Support Fragmentation Support Privacy Support1.0 CM allow/[deny] allow/[deny] allow BPI+/[force BPI]1.1 or 2.0 CMin 1.0 mode

allow/[deny] allow/[deny] allow BPI+/[force BPI]

415


G.3.2 Interoperability & Performance

This section addresses the issue of performance impact on the upstream channel when DOCSIS 1.x CMs areprovisioned to share the same upstream MAC channel as DOCSIS 2.0 TDMA CMs.

Since the Initial maintenance, Station maintenance, Request, and Request/Data IUCs are common to bothDOCSIS 2.0 TDMA and DOCSIS 1.x CMs, the overall channel will experience reduced performance comparedto a dedicated DOCSIS 2.0 TDMA upstream channel. This is due to broadcast/contention regions not beingcapable of taking advantage of improved physical layer parameters.

G.4 DOCSIS 2.0 S-CDMA Interoperability

G.4.1 Mixed mode operation with S-CDMA

In mixed mode operation with both TDMA and S-CDMA, two logically separate upstream channels areallocated by the CMTS, one for TDMA modems, and another for DOCSIS 2.0 modems operating in S-CDMAmode. Each channel has its own upstream channel ID, and its own UCD. However, these two channels are bothallocated the same RF center frequency on the same cable plant segment. The CMTS controls allocation to thesetwo channels in such a way that the channel is shared between the two groups of modems. This can beaccomplished by reserving bandwidth through the scheduling of data grants to the NULL SID on all channelsother than the channel which is to contain the potential transmit opportunity. Using this method, an upstreamchannel can support a mixture of differing physical layer DOCSIS modems, with each type capitalizing on theirindividual strengths. The channel appears as a single physical channel that provides transmission opportunitiesfor both 1.x and DOCSIS 2.0 modems. The mixed-mode configuration of the channel will be transparent to theCMs.

The following rule of operation applies:

1. The CMTS MUST use only type 5 burst descriptors on the S-CDMA channel in order to prevent DOCSIS 1.xmodems from attempting to use the channel.

G.4.2 Interoperability & Performance

This section addresses the issue of performance impact on the S-CDMA upstream channel when the upstreamcenter frequency is shared with an upstream TDMA channel.

Due to the lack of ability to share the upstream transmit opportunities, the channels will not experience thestatistical multiplexing benefits during contention regions across the CMs. Dedicated Initial Maintenance regionswill be required on both logical MAC channels slightly reducing the overall performance available. Request andRequest/Data regions will also not be capable of being shared although an intelligent CMTS scheduler will beable to reduce most performance impact.

416


Annex H The DOCSIS MAC/PHY Interface (DMPI)

H.1 Scope

Integrated circuit (IC) chip sets with separate MAC and PHY chips used in the implementation of a CMTSSHOULD implement DMPI. DMPI does not apply to IC chip sets which integrate MAC and PHY componentstogether into one chip.

Any usage of “MUST”, “SHOULD”, or “MAY” within the DMPI specification applies only if DMPI isimplemented.

H.2 Conventions

H.2.1 Terminology

Throughout this annex, the terms MAC and PHY are used extensively. MAC is used to refer to the device whichprovides the interface between the PHY devices and the system. The term PHY refers to the device whichperforms the physical layer processing for a single RF channel. It is important to note that both of these termsrefer to physical devices as opposed to layers in the IP protocol stack. For the purposes of this specification,integrated circuit chips which handle multiple RF channels simultaneously are considered to contain multiplePHY devices.

H.2.2 Ordering of Bits and Bytes

The following rules control the order of transmission of bits and bytes over all the interfaces specified in thedocument. In all cases, fields of Data Blocks are transmitted in the order in which they appear in the Data Blockformat description.

• Multibyte quantities are transmitted most significant byte first (big endian byte ordering). This byte orderingapplies regardless of the width of the interface (byte, nibble, single bit).

• On nibble wide interfaces, the most significant nibble (bits 7:4) is transmitted first.

• On bit wide interfaces, the most significant bit of each field is transmitted first.

H.2.3 Signal Naming Conventions

Signal names which end with an “_N” are active low. Signals without this suffix are active high.

H.2.4 Active Clock Edge

All signals are driven and sampled on the rising edge of the clock except where otherwise noted.

417


H.2.5 Timing Specifications

The timing specs for DMPI use the following terminology:

Following are some usage notes for these timing parameters:

• Setup and hold time specifications are given from the point of view of the DMPI Interface and not from thepoint of view of a device on the DMPI Interface. The clock to output, on the other hand, specifies the timingrequirement of a DMPI device.

• The tsu parameter specifies the minimum guaranteed amount of setup time provided by the DMPI interfacemeasured at the receiving device. Therefore, inputs on DMPI devices should require no more than thisamount of setup time.

• The th parameter specifies the minimum guaranteed amount of hold time provided by the DMPI interfacemeasured at the receiving device. Therefore, inputs on DMPI devices should require no more than thisamount of hold time.

• The tcq parameter specifies the minimum and maximum clock to output time at the driving device. The pur-pose of the minimum specification is to allow for clock skew between the driving and receiving DMPIdevice. For example, a 1ns minimum spec and a 0ns DMPI hold time requirement allows for at most 1ns ofclock skew between devices. The maximum specification is to allow for the settling time of signals from thedriving device to the receiving device and clock skew between devices.

H.3 Overview

This annex describes the DOCSIS MAC/PHY Interface (DMPI). DMPI is used to connect a DOCSIS MACdevice to DOCSIS downstream and upstream PHY devices. While DMPI is a single interface, for the purposes ofclarity, DMPI signals have been grouped into four separate groups. Each group serves a specific purpose and isindependent of the others. For this reason, each group of signals is also referred to as an interface.

A Downstream PHY MUST include a Downstream Data Interface and an SPI Bus Interface. An Upstream PHYmust include an Upstream Data Interface, an Upstream Control Interface, and an SPI Bus Interface. PHY Chipswhich integrate multiple PHYs into a single package MUST have one set of interfaces for each PHY which hasbeen integrated with the following exception:

An integrated PHY device MAY use a single select and a single SPI Bus for all internal PHYs (using the SPI Busprotocol described in Section H.8.4). An integrated Upstream PHY device MAY have only one TS_CLK inputand only one US_CLK input.

Table H-1 Timing Parameters

Parameter Symbol Description

Clock Frequency f The frequency of the interface clock.

Clock Low Pulse Width tlpw The low time of the interface clock.

Clock High Pulse Width thpw The high time of the interface clock.

Clock rise/fall time trf The transition time of the clock.

Input Setup Time to Clock tsu From when an interface signal is valid to the following rising clockedge.

Input Hold Time from Clock th From the rising clock edge to when an interface signal becomesinvalid.

Clock to Signal Valid Delay tcq From the rising edge of the interface clock to an interface signalbecoming valid.

418


A MAC MUST include one Downstream Data Interface for each Downstream PHY it supports and one set ofUpstream Interfaces (Upstream Data and Upstream Control) for each Upstream PHY it supports. It MUSTinclude at least one SPI Bus Interface.

DMPI has been defined with the following goals in mind:

• Vendor independence

• Flexibility for future growth and vendor differentiation

• Minimization of PHY specific logic in the MAC

Figure H-1 shows an example application of DMPI. Note that this figure shows the connections required for asingle DS PHY and a single US PHY. Obviously, other applications with multiple DS and US PHYs arepossible.

419


Figure H-1 DMPI Application

MAC

DS PHY

DS_DATAP

DS_VALID_N

DS_CLK

DS_MSYNC_N

US PHY

UD_DATA[3:0]

UD_SOB_N

UD_DATAP

UD_DV_N

INT_N

TS_FS_N

UC_DATA

UC_DV_N

UC_RDY_N

DS_DATA[3:0]

SPI_MOSI

SPI_MISO

SPI_SS0_N

SPI_SS1_N

SPI_CLK

TS_CLK

US_CLK

INT_N

420


H.3.1 Downstream Data

The Downstream Data Interface carries data from the MAC to the PHY for transmission on the Downstream. Allsignals on the interface are synchronous with respect to a clock driven by the PHY and received by the MAC.Four bits of data are transferred on each clock. The frequency of this clock is proportional to the Downstream bitrate. Its precise frequency is a function of the Downstream Symbol Rate, the modulation type (64QAM or256QAM), and the physical layer framing in use (ITU-T Recommendations J.83 Annex A or ITU-TRecommendations J.83 Annex B).

H.3.2 Upstream Data

The Upstream Data Interface carries data from the PHY to the MAC which has been received on the Upstream.The interface is synchronous to a dedicated interface clock whose frequency is not directly related to theupstream bit rate.

Data is transferred over the interface using a mixture of TLV’s and TV’s (a TLV for which the length is impliedby the type). Along with the DOCSIS burst data, certain status information about the burst is also transferred tothe MAC. There is also a TLV which allows the PHY to indicate that it didn’t receive a burst when one wasexpected.

H.3.3 Upstream Control

The Upstream Control Interface is used for two purposes. The first is to initialize the PHY’s timestamp counter,frame counter, and mini-slot counter and to check that the PHY’s timestamp counter remains synchronized to theMAC’s during operation. The second is to allow the MAC to pass information to the PHY regarding upcomingbursts.

This interface uses two clocks. The clock used for the counter synchronization is the 10.24 MHz CMTS masterclock. A single signal, that is synchronized to this clock, is used to perform this counter synchronization. Theother clock used for this interface is shared with the Upstream Data Interface and has a frequency unrelated to theupstream modulation clock or the 10.24 MHz CMTS master clock. This clock, along with an associated set ofsignals, is used to transfer descriptions of future bursts.

H.3.4 SPI Bus

The Serial Peripheral Interconnect (SPI) Bus is used to read and write registers in the PHYs. The system MAYuse one or more SPI Buses to provide register access to the PHYs. The number of SPI Buses in the system is afunction of the system’s SPI Bus performance requirements. Each SPI Bus has a single master device whichMAY be the MAC. Alternatively, an SPI Bus master MAY be some other device in the system (e.g., amicroprocessor). References to the SPI Bus in this specification assume that the MAC is the master. The PHYsMUST only be slave devices. Each PHY MUST have one SPI Bus Interface. Multiple PHYs MAY share thesame SPI Bus.

The SPI Bus definition includes an interrupt signal (INT_N). Each PHY MUST drive an interrupt. The interruptsignals MAY be received by an SPI Bus master or they MAY be received by some other device in the systemwhich provides the ability to monitor their state.

421


H.4 Signals


The signals used for the Downstream Data Interface are defined in Table H-2.

H.4.2 Upstream Data

The signals used for the Upstream Data Interface are defined in Table H-3.

Table H-2 Downstream Data Interface Signals

Signal Description

DS_CLK DS transmit clock

Driven by the Downstream PHY

see Section H.5.1 and Section H.5.2 for detailed requirements for this clock

DS_MSYNC_N Downstream MPEG Sync

Driven by the MAC

marks first nibble of sync byte; active low

DS_VALID_N Downstream Data Valid

Driven by the MAC

indicates that valid data is present on DS_DATA

DS_DATA[3:0] DS transmit data

Driven by the MAC

DS_DATAP Downstream Parity

Driven by the MAC

Even parity for DS_DATA (the number of 1’s across DS_DATA and DS_DATAP is even)

DS_DATA and its corresponding DS_DATAP are driven on the same clock. Parity is notdelayed a clock as it is in some interfaces.

Table H-3 Upstream Data Interface Signals

Signal Description

US_CLK Upstream Data/Control Clock

Driven by external clock source (input to MAC and PHY)

UD_SOB_N Upstream Data Start of Data Block

Driven by Upstream PHY

asserted when the first nibble or first byte of the Data Block is on UD_DATA

UD_DV_N Upstream Data Valid


indicates valid data on UD_DATA

UD_DATA[3:0] Upstream Data


UD_DATAP Upstream Data Parity


Even parity for UD_DATA (the number of 1’s across UD_DATA and UD_DATAP is even)

UD_DATA and its corresponding UD_DATAP are driven on the same clock. Parity is notdelayed a clock as it is in some other interfaces.

422



Table H-4 lists the signals that are used for the Upstream Control Interface.

H.4.4 SPI Bus

Table H-4 Upstream Control Interface Signals

Signal Description

US_CLK Upstream Clock


UC_DV_N Upstream Control Data Valid

Driven by the MAC

Indicates valid Upstream Control Message data on UC_DATA

UC_DATA Upstream Control Data

Driven by the MAC

UC_RDY_N Upstream Control Ready

Driven by the PHY

Indicates that the PHY is ready to receive an Interval Description Message

TS_CLK 10.24 MHz master clock


TS_FS_N Timestamp Frame Sync

Driven by the MAC

Table H-5 SPI Bus Signals

Signal name Description

SPI_CLK SPI Bus Clock

Driven by a source external to the MAC and PHY or driven by the MAC

SPI_MOSI Master out/Slave in

Serial data from the MAC to the PHY

SPI_MISO Slave out/Master in

Serial data from the PHY to the MAC

MAY be driven by the PHY from the falling edge of SPI_CLK.

SPI_SSx_N Slave Select

Selects a slave for a transaction.

One Slave Select signal is provided by the MAC for each PHY (x = 1 to N). Addressing of deviceswithin a package is provided by the protocol layer described in Section H.8.4

MAY be sampled by the PHY on the falling edge of SPI_CLK

INT_N Interrupt

Driven by PHYs

Open drain

423


H.4.5 Parity

The Downstream Data, Upstream Data, and Upstream Control Interfaces use parity to maintain data integrity onthe interface. Parity SHOULD be implemented.

The SPI Bus does not have parity.

Parity is even and covers only the data lines of the interface. Specific rules for parity checking are detailed in thefollowing sections.

H.4.5.1 Downstream Data

Parity must be checked by the Downstream PHY and covers DS_DATA. Since the Downstream transmit data isprotected (DOCSIS frame HCS and CRC), detection of a parity error is not considered fatal and MUST NOTcause the processing of transmit data to halt. The PHY must generate an interrupt to the system when it detects aparity error so that the system can be made aware of its occurrence. Parity checking on this interface provides away to distinguish between data errors on the interface and those in other parts of the data path.

H.4.5.2 Upstream Data

Parity is checked by the MAC and covers UD_DATA. Since the Upstream receive data is protected (DOCSISframe HCS and CRC), detection of a parity error is not considered fatal and MUST NOT cause the processing ofreceive data to halt. The MAC must generate an interrupt to the system when it detects a parity error so that thesystem can be made aware of its occurrence. Parity checking on this interface provides a way to distinguishbetween data errors on the interface and those in other parts of the data path.

H.4.5.3 Upstream Control

Parity is checked by the Upstream PHY and covers the entire Upstream Control Message. A parity error on thisinterface is considered a fatal error. The PHY MUST NOT process the Upstream Control message which wasreceived with a parity error as well as any subsequently received message. The PHY MAY process any UpstreamControl messages received prior to the occurrence of the parity error. This processing MAY include the passageof various types of Upstream Data Blocks to the MAC.

H.4.6 Interrupts

Various places in the specification make reference to the assertion of an interrupt by the PHY. The characteristicsof this interrupt MUST be as follows:

• One active low interrupt line of level type

• Driven open drain

• Cause of interrupt line assertion determined by software read(s) of PHY register(s) which contains one bit foreach interrupt source

• No hardware prioritization of interrupt sources

• Each interrupt source separately cleared by software write(s) to PHY register(s)

• Asserted until all interrupt source bits are cleared (interrupt line is a simple OR of all interrupt sources)

424


H.5 Protocol

H.5.1 Downstream Data (ITU-T Recommendations J.83 Annex A)

Figure H-2 shows the protocol for ITU-T Recommendations J.83 Annex A operation.

The following behavior of DS_CLK and DS_VALID_N is required:

• DS_CLK MUST NOT be gapped (it must have a constant frequency)

• DS_CLK frequency MUST be 1/4 of the Downstream Line Rate. The DS Line Rate is the data rate includingthe ITU-T Recommendations J.83 Annex A framing overhead.

• The MAC MUST assert DS_VALID_N for the entire 188 byte MPEG frame transfer and then MUST de-assert it for exactly 32 clocks following the transfer of the last nibble of the MPEG frame

Figure H-2 Downstream Data Signal Protocol for ITU-T Recommendations J.83 Annex A Operation

DS_CLK

DS_MSYNC_N

DS_DATA

DS_VALID_N

SYNCH SYNCL 1L 187H 187L2L SYNCH SYNCL1H 2H

DS_DATAP

425


H.5.2 Downstream Data (ITU-T Recommendations J.83 Annex B)

Figure H-3 shows the protocol used to transfer data across this interface for ITU-T Recommendations J.83Annex B operation.

The following behavior of DS_CLK and DS_VALID_N is required:

• DS_CLK MUST NOT be gapped (it must have a constant frequency)

• DS_CLK frequency MUST be 1/4 of the Downstream Payload Rate. The Downstream Payload Rate is thedata rate excluding the ITU-T Recommendations J.83 Annex B framing overhead.

• The MAC MUST keep DS_VALID_N always asserted

H.5.3 Upstream Data

Figure H-4 shows the signaling protocol for this interface.

Figure H-3 Downstream Data Signal Protocol for ITU-T Recommendations J.83 Annex B Operation

Figure H-4 Upstream Data Protocol

DS_CLK

DS_MSYNC_N

DS_DATA

DS_VALID_N

SYNCH SYNCL 1L 187H 187L2L1H 2H SYNCH SYNCL

DS_DATAP

US_CLK

UD_SOB_N

UD_DATA

UD_DV_N

B0H B0L B1H BNH BNLB1L B0H B0L

UD_DATAP

426


It is a very simple protocol in which the Upstream PHY indicates the presence of valid data on UD_DATA byasserting UD_DV_N. The MAC has no ability to control the flow of data and is required to sample UD_DATAon every rising clock edge on which UD_DV_N is asserted. The start of a Data Block is indicated by the PHY’sassertion of UD_SOB_N. This signal MUST be asserted when the first nibble of the first byte of the Data Blockis driven onto UD_DATA.

The MAC MUST keep track of length of each Data Block as it relates to the assertion of UD_SOB_N. IfUD_SOB_N is asserted before the entire previous Data Block has been transferred, the MAC MUST drop theassociated burst and generate an interrupt.

If the FIRST_STATUS byte indicates the absence of a PHY_STATUS Data Block but the PHY transfers one, thePHY_STATUS Data Block MUST be discarded by the MAC and an error MUST be signaled to the system.


H.5.4.1 Counter Synchronization

The master timestamp counter MUST reside in the MAC. The master mini-slot counter and master frame counterMUST reside in the PHY. The PHY MUST capture a timestamp snapshot on every frame boundary. When thesystem needs a Timestamp Snapshot for a UCD, it MUST read this snapshot using a single SPI bus transaction.The PHY MUST ensure that the timestamp snapshot does not change during the SPI Bus read transaction.

A common timestamp clock, TS_CLK, MUST be externally provided to the upstream PHYs and the MACs. Thefrequency of this timestamp clock MUST be 10.24 MHz ±5 ppm. The MAC MUST synchronize all PHYs to thetimestamp value of the MAC. To accomplish this, the MAC MUST provide a frame sync pulse, TS_FS_N, to thePHYs that is synchronous to the positive edge of TS_CLK and has a pulse width equal to one period of TS_CLK.

The 32 bit timestamp counter consists of a group of upper bits and a group of lower bits. The MAC and PHYMUST provide at least the following choices of upper and lower bit boundaries shown in Table H-6.

Figure H-5 shows an example of the proper assertion of the TS_FS_N signal. Note that the TIMESTAMP isshown for reference and is not part of the Upstream Control Interface. In this example, Upper Bits = 8.

Table H-6 Timestamp Counter Initialization Options

Upper Bits Lower Bits Frame Sync Interval

8 24 1638.4 ms

9 23 819.2 ms

10 22 409.6 ms

11 21 204.8 ms

12 20 102.4 ms

Figure H-5 Counter Synchronization

TS_CLK

TS_FS_N

XXFFF8 XXFFF9 XXFFFA XXFFFB XXFFFC XXFFFD XXFFFE XXFFFF XX0000 XX0001TIMESTAMP

427


The MAC MUST assert TS_FS_N two 10.24 MHz clock periods prior to the lower bits of the MAC timestampcounter equaling all zeros. The MAC SHOULD provide some sort of maskable indication to the system whenTS_FS_N occurs so that the system will have time to program the registers of the PHYs prior to the nextassertion of TS_FS_N. The period of TS_FS_N is a function of the timestamp bit time and the number of lowerbits from Table H-6. The variation of the TS_FS_N period is to allow the system designer to trade off systemresponse time versus the time available to initialize a PHY chip.

The PHY MUST provide all combinations of the following three initialization options when TS_FS_N isasserted:

• the upper bits of the timestamp counter are specified and the lower bits are set to zero

• the full 8 bits of the frame counter are specified

• the full 32 bits of the mini-slot counter are specified

The specification of these counters is supplied across the SPI Bus prior to the next frame sync pulse. TwoTS_CLK clock cycles after TS_FS_N occurs, the PHY chip MUST initialize the specified counters. Thesecounters are loaded at configuration time, and not on every assertion of TS_FS_N. A single PHY may be re-initialized without the need to re-initialize or otherwise interrupt the operation of other PHYs or the MAC.

During normal operation, the PHY MUST check that the lower bits of the PHY timestamp counter are exactly allzeros two 10.24 MHz clock cycles following every assertion of TS_FS_N. If the check is negative, the PHYMUST generate an interrupt and MUST provide status accessible over the SPI bus.

H.5.4.2 Upstream Control Messages

Figure H-6 shows a sample transaction.

The Upstream Control Interface is used to transfer time critical configuration information (messages) to the PHY.The most common type of message is an Interval Description message. This message informs the PHY of thearrival time and characteristics of an upcoming burst. The protocol of this interface is very simple. Following is adescription of how this interface works:

• A transaction transfers a single Upstream Control message.

• UC_DV_N MUST remain asserted for the entire duration of the Upstream Control message transfer.

• The length of each Upstream Control message is inferred by its type.

• UC_DV_N MUST be de-asserted for a minimum of one US_CLK clock period to indicate the end of a trans-action.

Figure H-6 Upstream Control Message Transfer

US_CLK

UC_DV_N

UC_DATA

UC_RDY_N

428


• UC_RDY_N MAY be used to stop and start the flow of Interval Description messages. UC_RDY_N does notaffect the transfer of other message types. If the PHY is receiving an interval description and does not want toreceive a subsequent interval description, the PHY MUST de-assert UC_RDY_N at least two clock cycles ofUS_CLK prior to the end of the current interval description. This de-assertion behavior is shown in Figure H-6. The MAC MUST transfer a new Interval Description Message within 10 US_CLK periods of the assertion

of UC_RDY_N if a new Interval Description Messages is available.1

H.5.5 SPI Bus

Figure H-7 shows a SPI Bus transaction.

A transaction proceeds as follows:

• The master asserts the select (SPI_SSx_N) of the desired slave device.

• The master drives SPI_MOSI with the appropriate command and data as described in Section H.8.4.

• For write commands, the first byte of data driven on SPI_MOSI is written to the register specified by theaddress in the command. The second byte of data (if it exists), is written to the next higher numbered address.Writes continue in this way until the master terminates the transaction by de-asserting SPI_SSx_N.

• For read commands, the slave drives the read data on SPI_MISO which is indicated by the address in thecommand. The first bit of this read data is driven one clock after the last bit of the command has been sam-pled. Read data from consecutively numbered addresses is driven until the master terminates the transactionby de-asserting SPI_SSx_N.

SPI_CLK MUST be driven (oscillate) for at least one clock period prior to the assertion of SPI_SSx_N, duringthe entire SPI Bus transaction, and for one clock after the deassertion of SPI_SSx_N. SPI_CLK MAY be drivenhigh or low at all other times.

1. Replaced bulleted paragraph per ECN RFI2-N-02218, chg #1, by GO, on 12/03/02.

Figure H-7 SPI Bus Transaction

SPI_CLK

SPI_SSx_N

SPI_MOSI

SPI_MISO

MSB

429


H.6 Electrical Specifications

H.6.1 DC Specifications

Devices which connect to DMPI must meet the requirements listed in Table H-7. Note that Output High Voltageand Output High Current specifications do not apply to the INT_N output as it is open drain.

Table H-7 DC Characteristics

Parameter Symbol Min. Max Units Comments

Input Capacitance 10 pf

Input Low Voltage Vil 0.8 v

Input High Voltage Vih 2.0 v

Output Low Voltage Vol 0.4 v

Output High Voltage Voh 2.4 v

Output Low Current Iol 4 ma

Output High Current Ioh -4 ma

430


H.7 Timing Specifications


H.7.2 Upstream Data


Table H-8 DS Data Interface Timing

Parameter Symbol Min. Max. Units

DS_CLK Frequency f 25 MHz

DS_CLK Low Pulse Width tlpw 10 ns

DS_CLK High Pulse Width thpw 10 ns

DS_CLK rise/fall time trf 4 ns

DS_CLK Jitter tj 97.66 ns

Input Setup Time to DS_CLK tsu 10 ns

Input Hold Time from DS_CLK th 0 ns

DS_CLK to Signal Valid Delay tcq 1 15 ns

Table H-9 US Data Interface Timing


US_CLK Frequency f 33 40.96 MHz

US_CLK Low Pulse Width tlpw 6.5 ns

US_CLK High Pulse Width thpw 6.5 ns

US_CLK rise/fall time trf 3 ns

Input Setup Time to US_CLK tsu 6 ns

Input Hold Time from US_CLK th 0 ns

US_CLK to Signal Valid Delay tcq 1 12 ns

Table H-10 Upstream Control Interface Timing


Input Setup Time to US_CLK tsu 6 ns

Input Hold Time from US_CLK th 0 ns

US_CLK to Signal Valid Delay tcq 1 12 ns

TS_CLK rise/fall time trf 3 ns

Input Setup Time to TS_CLK tsu 10 ns

Input Hold Time from TS_CLK th 0 ns

TS_CLK to Signal Valid Delay tcq 1 15 ns

431


H.7.4 SPI Bus

H.8 Data Format and Usage


The data which passes from the MAC to the PHY is a stream of MPEG frames. The start of the SYNC byte isindicated by the assertion of the DS_MSYNC_N signal. Including the SYNC byte, each MPEG frame is 188bytes in length.

The MAC MUST generate NULL MPEG frames when there are no DOCSIS frames to be transmitted.

H.8.2 Upstream Data

H.8.2.1 Block Format

Data is passed from the Upstream PHY to the MAC using a combination variable sized units called UpstreamData Blocks. Each of these Data Blocks has the generic format described in Table H-12 (except for theCHANNEL Data Block Type as indicated in Section H.8.2.8.5).

Table H-11 SPI Bus Timing


SPI_CLK Frequency f 10.24 MHz

SPI_CLK Low Pulse Width tlpw 43.91

1.Can be achieved with a 45/55 duty cycle 10.24Mhz clock

ns

SPI_CLK High Pulse Width thpw 43.92

2.Can be achieved with a 45/55 duty cycle 10.24Mhz clock

ns

SPI_CLK rise/fall time trf 4 ns

SPI_MOSI or SPI_MISO Setup Time toSPI_CLK

tsu 15 ns

SPI_MOSI or SPI_MISO Hold Time fromSPI_CLK

th 0 ns

SPI_SSx_N Setup Time to SPI_CLK rising3

3.Applies to PHYs which sample SPI_SSx_N with the rising edge of SPI_CLK. Ignored otherwise.

tsu 50 ns

SPI_SSx_N Setup Time to SPI_CLK falling4

4.Applies to PHYs which sample SPI_SSx_N with the falling edge of SPI_CLK. Ignored otherwise.

tsu 25 ns

SPI_SSx_N Hold Time from SPI_CLK th 0 ns

SPI_CLK to Signal Valid Delay5

5. For SPI_MISO, this timing is referenced to the driving edge of the clock (rising or falling, dependingon the device).

tcq 1 12 ns

Table H-12 Upstream Data Block Format

Size (bytes) Name Description

1 Block Type identifies the type of Block

2 Block Length length of Block data field in bytes (N)

Not present for CHANNEL Block Type

N Block Data Block data

432


As can be seen from this table, each Data Block starts with a Data Block type. This type is used by the MAC todetermine which type of Data Block data is being transferred. The Data Block length field contains the length inbytes of the Data Block data and is used by the MAC to find the end of the Data Block data field. In most cases,the Data Block type determines the format of the Data Block data field. The exception to this is thePHY_STATUS type where the format of the Data Block data field is PHY specific.

Table H-13 gives a complete list of all Block Types.

H.8.2.2 FIRST_DATA Block

Table H-14 shows the format of the FIRST_DATA Block.

The FIRST_DATA Block is used by the PHY to transfer the beginning of a received burst. This block MUSTcontain the seven bytes of status information defined in the table. It MAY contain burst data as well. The BlockLength of the FIRST_DATA block MUST NOT be less than seven. Note that N=7 is allowed.

Table H-13 Upstream Data Block Types

Type Name Description

0x00 Reserved Reserved

0x01 FIRST_DATA First data of burst

contains 7 bytes of fixed format status data and first data of burst

0x02 MIDDLE_DATA Middle data of burst

0x03 LAST_DATA Last data of burst

contains 4 bytes of fixed format status data and last data of burst

0x04 PHY_STATUS Status which should be passed to software

The maximum length of this Block is 128 bytes

0x05 NO_BURST Indicates that no burst was received during a transmit opportunity

0x06 CHANNEL Used to indicate the channel to which the next Data Block belongs.

0x07-0xff Reserved Reserved

Table H-14 FIRST_DATA Data Format


1 FIRST_STATUS bit 7:6, reserved, MUST be zero

bit 5, New UCD, 1=> First burst received on new UCD

bit 4, PHY_STATUS Data Block present, 1=> PHY_STATUS Data Blockpresent

bit 3:0, IUC, taken from the Upstream Control Interval Descriptionmessage

2 SID bit 15:14, reserved, MUST be zero

bit 13:0, SID, taken from the Upstream Control Interval Descriptionmessage

4 START_MINISLOT Derived from the Upstream Control Interval Description messageparameters

N-7 BURST_DATA First data of burst

433


H.8.2.3 MIDDLE_DATA Block

Table H-15 shows the format of the MIDDLE_DATA Block. The MIDDLE_DATA block is used to transferburst data.

H.8.2.4 LAST_DATA Block

Table H-16 shows the format of the LAST_DATA Block. The LAST_DATA block is used to transfer burst data.This block MUST contain the four bytes of status information defined in the table. It MAY also contain burstdata. The Block Length of the LAST_DATA block MUST NOT be less than four. Note that N=4 is allowed.

H.8.2.5 PHY_STATUS Block

Table H-17 shows the format of the PHY_STATUS Block. The PHY_STATUS block is used to transfer PHYunique status to the MAC. The contents of this block are vendor unique and are unrestricted.

Table H-15 MIDDLE_DATA Data Format


N BURST_DATA Middle data of burst

Table H-16 LAST_DATA Data Format


N-4 BURST_DATA Last data of burst

1 LAST_STATUS bit 7:3, reserved, must be zero

bit 2, internal PHY error, 1=> internal PHY error

bit 1, low energy; indicates that the burst power was below the desiredthreshold, 1 => low energy

bit 0, high energy; indicates that the burst power was above the desiredthreshold, 1 => high energy

1 GOOD_FEC the number of good FEC blocks in the burst

must stop incrementing when count reaches 255

must be zero if FEC is disabled for associated interval

1 CORRECTED_FEC the number of corrected FEC blocks in the burst



1 UNCORRECTED_FEC the number of uncorrected FEC blocks in the burst



Table H-17 PHY_STATUS Data Format


N PHY_STATUS PHY specific status information such as channel characteristics (e.g.timing error, power error, frequency error, EQ coefficients)

434


H.8.2.6 NO_BURST Block

Table H-18 shows the format of the NO_BURST Block. This block is used by the PHY to indicate that a validburst was not received when one was expected. Absence of a valid burst may be caused by either no transmitter,multiple transmitters, or a noise corrupted transmission. DMPI does not specify the criteria by which the PHYdistinguishes between these cases.

H.8.2.7 CHANNEL Block

Table H-19 shows the format of the CHANNEL Block. The Channel Block is used by the PHY to indicate towhich logical channel subsequent blocks belong.

H.8.2.8 Block Usage

H.8.2.8.1 Overview

At least one Data Block MUST be transferred for every Transmit Opportunity. If a burst is received during atransmit opportunity, the appropriate series of Data Blocks MUST be transferred to the MAC (FIRST_DATA,MIDDLE_DATA, LAST_DATA, PHY_STATUS). If no burst is received, a NO_BURST Data Block MUST betransferred unless the region was allocated to a SID which the system has reserved for no CM (e.g. the null SID

as defined in A.2.1).1 Note that since contention regions have multiple transmit opportunities, more than one setof Data Blocks will likely be transferred to over the interface for each region (interval).

Table H-18 NO_BURST Data Format


2 SID_STATUS bit 15, collision, collision occurred

bit 14, no energy, no energy detected

bit 13:0, SID, taken from the Upstream Control Interval Descriptionmessage

4 START_MINISLOT Derived from the Upstream Control Interval Description messageparameters

1 IUC bit 7:5, reserved, must be zero

bit 4: New UCD, 1=> First NO_BURST block received on new UCD

bit 3:0, IUC, taken from the Upstream Control Interval Descriptionmessage

2 LENGTH Taken from the Upstream Control Interval Description message

Note that for Contention Intervals, this is the length of the interval and notthe length of each individual transmit opportunity in the interval.

Table H-19 CHANNEL Data Format


1 CHANNEL bit 7:3, reserved, must be zero

bit 2:0, Channel Number

1. Replaced sentence per ECN RFI2-N-02217, chg #2, by GO, on 12/03/02.

435


The minimum amount of payload in a Data Block (the length of the Block Data field) MUST be 16 bytes withthe following exceptions:

• Data Blocks for bursts which are less than 16 bytes in length

• Any LAST_DATA Data Block

The Upstream PHY SHOULD minimize the number of Data Blocks required to transfer a burst so as to minimizethe amount of overhead on DMPI. However, nothing specific other than what is mentioned above is required.

For Non-contention Intervals, the START_MINISLOT MUST be equal to the START_MINISLOT which waspassed to the PHY in the corresponding Interval Description Message (described in Section H.8.3). ForContention Intervals (IE types REQ and REQ/Data), the PHY MUST calculate an accurate START_MINISLOTvalue and return it in the appropriate Data Block (FIRST_DATA or NO_BURST). In general terms, this meansthat PHY MUST calculate the START_MINISLOT for each Data Block by taking into account the number ofmini-slots which have passed since the start of the Interval. Specifically, the Upstream PHY SHOULD use theIUC and SID in the Upstream Control Interval Description message to calculate a burst start offset from theoriginal START_MINISLOT value received in this message. The offset is then added to thisSTART_MINISLOT and returned to the MAC as the START_MINISLOT in the appropriate Upstream DataBlock.

H.8.2.8.2 Burst Data Transfer

The transfer of a burst MUST be accomplished by transferring the following Data Blocks in the following order:

• one FIRST_DATA Block

• zero to N MIDDLE_DATA Blocks

• one LAST_DATA Block

• zero or one PHY_STATUS Block

The only Data Block type which MAY be transferred after a FIRST_DATA Data Block and before aLAST_DATA Data Block is a MIDDLE_DATA Data Block. Any other Data Block transferred between thesetwo Data Blocks MUST be discarded by the MAC.

In general, each Data Block will contain one FEC block of data. However, there is no specific requirement as towhich Data Block types contain which parts of the burst data. The data MAY be distributed between the variousData Block types at the discretion of the PHY as long as the Data Block ordering shown above is maintained andthe minimum block length requirements are respected. A Data Block type with a length of zero is also allowed.Every burst, regardless of size, MUST be transferred to the MAC using at least a FIRST_DATA Block and aLAST_DATA Data Block. The PHY_STATUS Data Block is optional with its presence indicated in theFIRST_STATUS byte in the FIRST_DATA Data Block. The MIDDLE_DATA Data Block is optional.

Typically, there will be some arbitrary delay between the transfer of one Data Block and the transfer of the next.It is the PHY’s responsibility to assure that these delays do not interfere with the PHY’s ability to keep up withthe incoming data rate.

Note that this series of Data Blocks is passed to the MAC any time a burst is received regardless of the type ofinterval in which the burst was received (contention or non-contention).

436


H.8.2.8.3 No Burst Status Transfer

It is sometimes useful for the system to know when no usable burst was received during a transmit opportunity.This can happen when there is no transmitter (no energy) in the opportunity, there is more than one transmitter (acollision), or noise corrupted a transmission. For a contention region, knowledge of unused opportunities orthose with collisions helps software optimize its scheduling of contention regions (their duration and frequency).For non-contention regions, these same events could be an indication of a problem with a CM. Or, they could bea result of illegal or malicious use of the US bandwidth.

The NO_BURST Data Block contains two status bits. The one called “collision” indicates that a collisionoccurred during the transmit opportunity. The other, called “no energy”, indicates that there was no energydetected during the transmit opportunity. If neither is set, it means that there was energy but that no preamble wasfound. Both of these bits must not be set at the same time.

H.8.2.8.4 UCD Change Indication

In order to allow the system to properly size grants for bandwidth requests which were received prior to a UCDchange but are granted after such a UCD change, the MAC needs to be notified that a new UCD is in effect. Thisnotification is achieved via “New UCD” status bits in the NO_BURST and FIRST_DATA Data Blocks. ThePHY MUST set the New UCD bit of the first Data Block sent to the MAC after a UCD change (FIRST_DATA orNO_BURST, whichever is sent first). The New UCD bit of these Data Blocks MUST be zero at all other times.

H.8.2.8.5 Logical Channel Support

For Upstream PHYs which support multiple logical channels, a Data Block Type called CHANNEL is used tospecify to which logical channel each Data Block belongs. This Data Block contains a single byte of payloadwhich is the channel number (zero to seven inclusive). Since the Data Block is a fixed length and is potentiallyrequired for every other Data Block transferred, the length bytes are omitted from the normal Data Block formatand only the Data Block Type and Block Data are transferred. So, a CHANNEL Block is always two bytes long(including the Type byte).

It is important to note that the Channel Data Block is only used to distinguish between data received on logicalchannels within the same RF channel. Since each PHY has its own DMPI interface, the RF channel to which databelongs is inferred by the PHY’s connection to the MAC.

The CHANNEL Data Block is used as follows:

• The CHANNEL Data Block sets the “current” channel for transmitted Data Blocks. After reset, the MACmust set the current channel to zero.

• The current channel is always the channel number contained in the most recently transmitted CHANNELData Block. For this reason, transmission of a CHANNEL Data Blocks is only required when a change in thecurrent channel is desired.

Since the MAC sets the current channel to zero prior to receipt of any CHANNEL Data Blocks, PHYs whichsupport a single channel are not required to support this Data Block Type. In cases where multiple CHANNELData Blocks are transferred in succession, the last one received prior to the transfer of one of the other DataBlocks will be considered valid and the others that preceded it will be ignored. NO_BURST Data Blocks may bepreceded by a CHANNEL Data Block. If a series of NO_BURST Data Blocks for the same channel aretransmitted to the MAC, only one CHANNEL Data Block is required (transferred prior to the first NO_BURSTData Block).

All Data Blocks associated with a single burst MUST be transferred contiguously over the Upstream Datainterface. Specifically, this would mean that FIRST_DATA, MIDDLE_DATA, LAST_DATA, PHY_STATUS

437


would all be transferred for a given burst of a given channel before any other Data Blocks were transferred foranother channel. A CHANNEL Data Block MUST precede the first Data Block (NO_BURST or FIRST_DATA)that belongs to a channel which is different than the one which preceded it. The PHY MAY transfer aCHANNEL Data Block prior to the FIRST_DATA block of every burst. CHANNEL Data Blocks MUST NOTbe transferred immediately before any of the other Data Block associated with a burst.

438



The Upstream Control Interface carries two different messages. One of them is used to describe upcomingbursts. The other is used to indicate UCD changes.

The format of an Upstream Control Message is shown in Table H-20.

Table H-21 shows the Message Type encoding.

H.8.3.1 Interval Description Message

Table H-22 describes the format of the Interval Description Message Payload.

The MAC builds these Interval Description Messages from the information present in the DOCSIS MAPs thathave been generated for the logical channels which the PHY is servicing. The MAC MUST transfer only oneInterval Description Message to the PHY for an Interval Allocation which might describe an interval which hasmore than one transmit opportunity (e.g. REQ, REQ/DATA). The MAC MAY generate Interval DescriptionMessages for Interval Allocations to the NULL SID, but MUST NOT generate Interval Description Messages forInterval Allocations for the NULL SID if they overlap with Interval Allocations for non-NULL SIDs on otherlogical channels being serviced by the same PHY. Interval Description Messages for the NULL SID MAY beassociated with any currently active logical channel. In contrast to MAP messages, the set of all IntervalDescription Messages from the MAC taken together need not describe every minislot on the logical channels inquestion; the MAC MAY refrain from sending Interval Description messages to describe inactive time periodson any or all logical channels. So as to minimize the complexity and buffering requirements of the PHY, theMAC MUST sort the Interval Descriptions from all logical channels, putting them into chronological order, anddeliver them to the PHY in this order. Note that Interval Description Messages MUST NOT be transferred for the

NULL IE, Data Acknowledgement IE's, or Data Grants Pending (since none of these is an Interval Allocation).1

Table H-20 Upstream Control Message Format

Size (bits) Name Description

3 TYPE Message Type

3 CHANNEL Logical Channel Number

N PAYLOAD Payload of Message

1 PARITY Even parity for all bits in the Message (the number of 1’s across all bitsin {TYPE, CHANNEL, PAYLOAD, PARITY} is even)

Table H-21 Upstream Message Types

Type Name Description

0x0 INTERVAL_DESCRIPTION Describes an interval

0x1 UCD_CHANGE Indicates a UCD change has occurred

0x2-0x7 Reserved Reserved

Table H-22 Upstream Control Interval Description PAYLOAD Format


14 SID expected SID from MAP IE

4 IUC IUC from MAP IE

14 LENGTH length in mini-slots

32 START_MINISLOT starting mini-slot of interval (alloc start time + offset of IE)

3 PSC PHY_STATUS Control

1. Replaced paragraph per ECN RFI2-N-02217, chg #1, by GO, on 12/03/02.

439


The system is allowed to schedule the Initial Maintenance regions of all logical channels of a physical channel tooccur simultaneously. This type of overlap MUST be handled as follows:

• The MAC MUST transfer an Interval Description for only one of the logical channels

• The Interval Description which is transferred MUST be the one with the earliest start time. If more than oneInterval Description has the earliest start time, the MAC MAY choose any of these overlapping intervaldescriptions to pass to the PHY

• The PHY MUST accept any of the logical channel numbers it supports for this interval description

The system software is responsible for knowing that bursts received during initial ranging could be from CMs onany of the logical channels.

It is possible for there to be illegal overlap of intervals for the logical channels. An illegal overlap is defined to bean overlap of intervals other than Initial Maintenance. The PHY MAY detect these illegal overlaps. If the PHYperforms this function, it MUST generate an interrupt to alert the system of such an event. It MUST capture theillegally overlapped Interval Description and hold it in SPI Bus accessible registers until software acknowledgesits receipt.

The PSC field of the Interval Description Message is used to control the contents of the PHY_STATUS block.The usage of this field is summarized below:

• If PSC = 000, the contents of the PHY_STATUS block is determined through PHY programmable registers.

• If PSC is any other value, the contents of the PHY_STATUS block are vendor specific

The MAC and PHY MUST support PSC = 000.

The MAC and PHY MAY support other values.

H.8.3.2 UCD Change Message

Table H-23 describes the format of the UCD Change Message Payload.

The MAC MUST send this message before sending the first Interval Description message after a UCD change.This message MUST NOT be sent at any other time.

H.8.4 SPI Bus

In order to perform an SPI Bus transaction, the master MUST drive SPI_MOSI with a bitstream of the followingformat:

The DEVICE_ID is used to address PHY devices which are integrated into the same physical package and sharea single SPI select. DEVICE_ID MUST be zero for accesses to single PHY devices.

Table H-23 UCD Change PAYLOAD Format


8 CCC Configuration Change Count from the MAP

Table H-24 SPI Bus Transaction Format


4 DEVICE_ID Device ID

3 RSVD Reserved

1 WRITE 1=Write, 0=Read

16 REGISTER_ADD Register Address

N*8 WRITE_DATA Write Data; ignored for Reads

440


Appendix I MAC Service Definition

This section is informative. In case of conflict between this section and any normative section of thisspecification, the normative section takes precedence.

I.1 MAC Service Overview

The DOCSIS MAC provides a protocol service interface to upper-layer services. Examples of upper-layerservices include a DOCSIS bridge, embedded applications (e.g., Packetcable/VOIP), a host interface (e.g., NICadapter with NDIS driver), and layer three routers (e.g., IP router).

The MAC Service interface defines the functional layering between the upper layer service and the MAC. Assuch it defines the functionality of the MAC which is provided by the underlying MAC protocols. This interfaceis a protocol interface, not a specific implementation interface.

The following data services are provided by the MAC service interface:

• A MAC service exists for classifying and transmitting packets to MAC service flows.

• A MAC service exists for receiving packets from MAC service flows. Packets may be received with sup-pressed headers.

• A MAC service exists for transmitting and receiving packets with suppressed headers. The headers of trans-mitted packets are suppressed based upon matching classifier rules. The headers of received suppressed pack-ets are regenerated based upon a packet header index negotiated between the CM and CMTS.

• A MAC service exists for synchronization of grant timing between the MAC and the upper layer service. Thisclock synchronization is required for applications such as embedded Packetcable VOIP clients in which thepacketization period needs to be synchronized with the arrival of scheduled grants from the CMTS.

• A MAC service exists for synchronization of the upper layer clock with the CMTS Controlled Master Clock.

It should be noted that a firewall and policy based filtering service may be inserted between the MAC layer andthe upper layer service, but such a service is not modeled in this MAC service definition.

The following control services are provided by the MAC service interface:

• A MAC service exists for the upper layer to learn of the existence of provisioned service flows and QoS traf-fic parameter settings at registration time.

• A MAC service exists for the upper layer to create service flows. Using this service the upper layer initiatesthe admitted/activated QoS parameter sets, classifier rules, and packet suppression headers for the serviceflow.

• A MAC service exists for the upper layer to delete service flows.

• A MAC service exists for the upper layer to change service flows. Using this service the upper layer modifiesthe admitted/activated QoS parameter sets, classifier rules, and packet suppression headers.

• A MAC service exists for controlling the classification of and transmission of PDUs with suppressed head-ers. At most a single suppressed header is defined for a single classification rule. The upper layer service isresponsible for defining both the definition of suppressed headers (including wild-card don’t-suppress fields)and the unique classification rule that discriminates each header. In addition to the classification rule, theMAC service can perform a full match of all remaining header bytes to prevent generation of false headers ifso configured by the upper layer service.

• A MAC service exists for controlling two-phase control of QoS traffic resources. Two phase activation iscontrolled by the upper layer service provide both admitted QoS parameters and active QoS parameterswithin the appropriate service request. Upon receipt of an affirmative indication the upper layer service

441


knows that the admitted QoS parameter set has been reserved by the CMTS, and that the activated QoSparameter set has been activated by the CMTS. Barring catastrophic failure (such as resizing of the band-width of the upstream PHY), admitted resources will be guaranteed to be available for activation, and activeresources will be guaranteed to be available for use in packet transmission.

A control function for locating an unused service flow and binding it or a specific identified service flow to aspecific upper layer service may also exist. The details of such a function are not specified and areimplementation dependent.

Other control functions may exist at the MAC service interface, such as functions for querying the status ofactive service flows and packet classification tables, or functions from the MAC service to the upper layerservice to enable the upper layer service to authorize service flows requested by the peer MAC layer service, butthose functions are not modeled in this MAC service definition.

Other MAC services that are not service flow related also exist, such as functions for controlling the MACservice MAC address and SAID multicast filtering functions, but those functions are not modeled in this MACservice definition.

I.1.1 MAC Service Parameters

The MAC service utilizes the following parameters. For a full description of the parameters consult the Theoryof Operation and other relevant sections within the body of the RFI specification.

• Service Flow QoS Traffic Parameters

MAC activate-service-flow and change-service-flow primitives allow common, upstream, and downstream QoStraffic parameters to be provided. When such parameters are provided they override whatever values wereconfigured for those parameters at provisioning time or at the time the service flow was created by the upperlayer service.

• Active/Admitted QoS Traffic Parameters

If two-phase service flow activation is being used, then two complete sets of QoS Traffic Parameters arecontrolled. The admitted QoS Parameters state the requirements for reservation of resources to be authorized bythe CMTS. The activated QoS Parameters state the requirements for activation of resources to be authorized bythe CMTS. Admitted QoS parameters may be activated at a future time by the upper layer service. ActivatedQoS parameters may be used immediately by the upper layer service.

• Service Flow Classification Filter Rules

Zero or more classification filter rules may be provided for each service flow that is controlled by the upper layerservice. Classifiers are identified with a classifier identifier.

• Service Flow PHS Suppressed Headers

Zero or more PHS suppressed header strings with their associated verification control and mask variables may bedefined for each service flow. When such headers are defined, they are associated 1-to-1 with specificclassification rules. In order to regenerate packets with suppressed headers a payload header suppression index isnegotiated between the CM and CMTS.

442


I.2 MAC Data Service Interface

MAC services are defined for transmission and reception of data to and from service flows. Typically an upperlayer service will utilize service flows for mapping of various classes of traffic to different service flows.Mappings to service flows may be defined for low priority traffic, high priority traffic, and multiple specialtraffic classes such as constant bit rate traffic which is scheduled by periodic grants from the CMTS at the MAClayer.

The following specific data service interfaces are provided by the MAC service to the upper layer service. Theserepresent an abstraction of the service provided and do not imply a particular implementation:

MAC_DATA.requestMAC_DATA.indicateMAC_GRANT_SYNCHRONIZE.indicateMAC_CMTS_MASTER_CLOCK_SYNCHRONIZE.indicate

I.2.1 MAC_DATA.request

Issued by the upper-layer service to request classification and transmission of an IEEE 802.3 or DIX formattedPDU to the RF.

Parameters:

• PDU - IEEE 802.3 or DIX encoded PDU including all layer two header fields and optional FCS. PDU is theonly mandatory parameter.

• padding - is used when the PDU is less than 60 bytes and it is desired to maintain ISO8802-3 transparency.

• ServiceFlowID - if included the MAC service circumvents the packet classification function and maps thepacket to the specific service flow indicated by the ServiceFlowID value.

• ServiceClassName, RulePriority - if included this tuple identifies the service class name of an active serviceflow to which the packet is to be mapped so long as a classifier does not exist at a rule priority higher than therule priority supplied.

Expanded Service Description:

Transmit a PDU from upper-layer service to MAC/PHY. The only mandatory parameter is PDU. PDU containsall layer-2 headers, layer-3 headers, data, and (optional) layer-2 checksum.

If PDU is the only parameter, the packet is subjected to the MAC packet classification filtering function in orderto determine how the packet is mapped to a specific service flow. The results of the packet classificationoperation determine on which service flow the packet is to be transmitted and whether or not the packet shouldbe transmitted with suppressed headers.

If the parameter ServiceFlowID is supplied the packet can be directed to the specifically identified service flow.

If the parameter tuple ServiceClassName, RulePriority is supplied the packet is directed to the first active serviceflow that matches the service class name so long as a classifier does not exist at a rule priority higher than therule priority supplied. This service is used by upper layer policy enforcers to allow zero or more dynamic rules tobe matched for selected traffic (e.g., voice) while all other traffic is forced to a service flow within the namedServiceFlowClass. If no active service flow with the Service Class Name exists, then the service perform normalpacket classification.

In all cases, if no classifier match is found, or if none of the combinations of parameters maps to a specificservice flow, the packet will be directed to the primary service flow.

443


The following pseudo code describes the intended operation of the MAC_DATA.request service interface:

MAC_DATA.requestPDU[ServiceFlowID][ServiceClassName, RulePriority]

FIND_FIRST_SERVICE_FLOW_ID (ServiceClassName) returns ServiceFlowID of first service flow whoseServiceClassName equals the parameter of the procedure or NULL if no matching service flow found.

SEARCH_CLASSIFIER_TABLE (PriorityRange) searches all rules within the specified priority range andreturns either the ServiceFlowID associated with the rule or NULL if no classifier rule found.

TxServiceFlowID = NULL

IF (ServiceFlowID DEFINED)TxServiceFlowID = MAC_DATA.ServiceFlowID

ELSEIF (ServiceClassName DEFINED and RulePriority DEFINED)TxServiceFlowID = FIND_FIRST_SERVICE_FLOW_ID (ServiceClassName)SearchID = SEARCH_CLASSIFIER_TABLE (All Priority Levels)IF (SearchID not NULL and ClassifierRule.Priority >= MAC_DATA.RulePriority)

TxServiceFlowID = SearchID

ELSE [PDU only]TxServiceFlow = SEARCH_CLASSIFIER_TABLE (All Priority Levels)

IF (TxServiceFlowID = NULL)TRANSMIT_PDU (PrimaryServiceFlowID)

ELSETRANSMIT_PDU (TxServiceFlowID)

I.2.2 MAC_DATA.indicate

Issued by the MAC to indicate reception of an IEEE 802.3 or DIX PDU for the upper-layer service from the RF.

Parameters:

• PDU - IEEE 802.3 or DIX encoded PDU including all layer two header fields and FCS.

I.2.3 MAC_GRANT_SYNCHRONIZE.indicate

Issued by the MAC service to the upper layer service to indicate the timing of grant arrivals from the CTMS. It isnot stated how the upper layer derives the latency if any between the reception of the indication and the actualarrival of grants (within the bounds of permitted grant jitter) from the CMTS. It should be noted that in UGSapplications it is expected that the MAC layer service will increase the grant rate or decrease the grant rate basedupon the number of grants per interval QoS traffic parameter. It should also be noted that as the number of grantsper interval is increased or decreased that the timing of grant arrivals will change also. It should also be notedthat when synchronization is achieved with the CMTS downstream master clock, this indication may only berequired once per active service flow. No implication is given as to how this function is implemented.

Parameters:

• ServiceFlowID - unique identifier value for the specific active service flow receiving grants.

444


I.2.4 MAC_CMTS_MASTER_CLOCK_SYNCHRONIZE.indicate

Issued by the MAC service to the upper layer service to indicate the timing of the CMTS master clock. Noimplication is given as to how often or how many times this indication is delivered by the MAC service to theupper layer service. No implication is given as to how this function is implemented.

Parameters:

• No parameters specified.

I.3 MAC Control Service Interface

A collection of MAC services are defined for control of MAC service flows and classifiers. It should be notedthat an upper layer service may use these services to provide an upper layer traffic construct such as“connections” or “subflows” or “micro-flows”. However, except for the ability to modify individual classifiers,no explicit semantics is defined for such upper layer models. Thus control of MAC service flow QoS parametersis specified in the aggregate.

The following specific control service interface functions are provided by the MAC service to the upper layerservice. These represent an abstraction of the service provided and do not imply a particular implementation:

MAC_REGISTRATION_RESPONSE.indicateMAC_CREATE_SERVICE_FLOW.request/response/indicateMAC_DELETE_SERVICE_FLOW.request/response/indicateMAC_CHANGE_SERVICE_FLOW.request/response/indicate

I.3.1 MAC_REGISTRATION_RESPONSE.indicate

Issued by the DOSCIS MAC to the upper layer service to indicate the complete set service flows and serviceflow QoS traffic parameters that have been provisioned and authorized by the registration phase of the MAC.Subsequent changes to service flow activation state or addition and deletion of service flows are communicatedto the upper layer service with indications from the other MAC control services.

Parameters:

• Registration TLVs - any and all TLVs that are needed for service flow and service flow parameterdefinition including provisioned QoS parameters. See the normative body of the specification formore details.

I.3.2 MAC_CREATE_SERVICE_FLOW.request

Issued by the upper-layer service to the MAC to request the creation of a new service flow within the MACservice. This primitive is not issued for service flows that are configured and registered, but rather fordynamically created service flows. This primitive may also define classifiers for the service flow and supplyadmitted and activated QoS parameters. This function invokes DSA signaling.

Parameters:

• ServiceFlowID - unique id value for the specific service flow being created.

• ServiceClassName - service flow class name for the service flow being created.

• Admitted QoS Parameters - zero or more upstream, downstream, and common traffic parameters forthe service flow.

445


• Activated QoS Parameters - zero or more upstream, downstream, and common traffic parameters forthe service flow.

• Service Flow Payload Header Suppression Rules - Zero or more PHS rules for each service flow thatis controlled by the upper layer service.

• Service Flow Classification Filter Rules - Zero or more classification filter rules for each serviceflow that is controlled by the upper layer service. Classifiers are identified with a classifier identifier.

I.3.3 MAC_CREATE_SERVICE_FLOW.response

Issued by the MAC service to the upper layer service to indicate the success or failure of the request to create aservice flow.

Parameters:

• ServiceFlowID - unique identifier value for the specific service flow being created.

• ResponseCode - success or failure code

I.3.4 MAC_CREATE_SERVICE_FLOW.indicate

Issued by the MAC service to notify the upper-layer service of the creation of a new service flow within theMAC service. This primitive is not issued for service flows that have been administratively pre-configured, butrather for dynamically defined service flows. In this draft of the specification this notification is advisory only.

Parameters:

• ServiceFlowID - unique id value for the specific service flow being created.

• ServiceClassName - service flow class name for the service flow being created.




• Service Flow Classification Filter Rules - Zero or more classification filter rules for each serviceflow that is controlled by the upper layer service. Classifiers are identified with a classifier identifier.

I.3.5 MAC_DELETE_SERVICE_FLOW.request

Issued by the upper-layer service to the MAC to request the deletion of a service flow and all QoS parametersincluding all associated classifiers and PHS rules. This function invokes DSD signaling.

Parameters:

• ServiceFlowID(s) - unique identifier value(s) for the deleted service flow(s).

446


I.3.6 MAC_DELETE_SERVICE_FLOW.response

Issued by the MAC service to the upper layer service to indicate the success or failure of the request to delete aservice flow.

Parameters:


I.3.7 MAC_DELETE_SERVICE_FLOW.indicate

Issued by the MAC service to notify the upper-layer service of deletion of a service flow within the MACservice.

Parameters:

• ServiceFlowID(s) - unique identifier value(s) for the deleted service flow(s).

I.3.8 MAC_CHANGE_SERVICE_FLOW.request

Issued by the upper-layer service to the MAC to request modifications to a specific created and acquired serviceflow. This function is able to define both the complete set of classifiers and incremental changes to classifiers(add/remove). This function defines the complete set of admitted and active QoS parameters for a service flow.This function invokes DSC MAC-layer signaling.

Parameters:

• ServiceFlowID - unique identifier value for the specific service flow being modified.

• zero or more packet classification rules with add/remove semantics and LLC, IP, and 802.1pqparameters.




I.3.9 MAC_CHANGE_SERVICE_FLOW.response

Issued by the MAC service to the upper layer service to indicate the success or failure of the request to change aservice flow.

Parameters:

• ServiceFlowID - unique identifier value for the specific service flow being released.


447


I.3.10 MAC_CHANGE_SERVICE_FLOW.indicate

Issued by the DOSCIS MAC service to notify upper-layer service of a request to change a service flow. In thisspecification the notification is advisory only and no confirmation is required before the service flow is changed.Change-service-flow indications are generated based upon DSC signaling. DSC signaling can be originatedbased upon change-service-flow events between the peer upper-layer service and its MAC service, or based uponnetwork resource failures such as a resizing of the total available bandwidth at the PHY layer. How the upperlayer service reacts to forced reductions in admitted or reserved QoS traffic parameters is not specified.

Parameters:

• ServiceFlowID - unique identifier for the service flow being activated.

• packet classification rules with LLC, IP, and 802.1pq parameters, and with zero or morePHS_CLASSIFIER_IDENTIFIERs.




I.4 MAC Service Usage Scenarios

Upper layer entities utilize the services provided by the MAC in order to control service flows and in order tosend and receive data packets. The partition of function between the upper-layer-service and the MAC serviceservice is demonstrated by the following scenarios.

I.4.1 Transmission of PDUs from Upper Layer Service to MAC DATA Service

• Upper layer service transmits PDUs via the MAC_DATA service.

• MAC_DATA service classifies transmitted PDUs using the classification table, and transmits the PDUs onthe appropriate service flow. The classification function may also cause the packet header to be suppressedaccording to a header suppression template stored with the classification rule. It is possible for the upper layerservice to circumvent this classification function.

• MAC_DATA service enforces all service flow based QoS traffic shaping parameters.

• MAC_DATA service transmits PDUs on DOCSIS RF as scheduled by the MAC layer.

I.4.2 Reception of PDUs to Upper Layer Service from MAC DATA Service

PDUs are received from the DOCSIS RF.

If a PDU is sent with a suppressed header, the header is regenerated before the packet is subjected to furtherprocessing.

In the CMTS, the MAC_DATA service classifies the PDU’s ingress from the RF using the classification tableand then polices the QoS traffic shaping and validates addressing as performed by the CM. In the CM, no per-packet service flow classification is required for traffic ingress from the RF.

Upper layer service receives PDUs from the MAC_DATA.indicate service.

448


I.4.3 Sample Sequence of MAC Control and MAC Data Services

A possible CM-oriented sequence of MAC service functions for creating, acquiring, modifying, and then using aspecific service flow is as follows:

• MAC_REGISTER_RESPONSE.indicate

Learn of any provisioned service flows and their provisioned QoS traffic parameters.

• MAC_CREATE_SERVICE_FLOW.request/response

Create new service flow. This service interface is utilized if the service flow was learned as not provi-sioned by the MAC_REGISTER_RESPONSE service interface. Creation of a service flow invokesDSA signaling.

• MAC_CHANGE_SERVICE_FLOW.request/response

Define admitted and activated QoS parameter sets, classifiers, and packet suppression headers. Changeof a service flow invokes DSC signaling.

• MAC_DATA.request

Send PDUs to MAC service for classification and transmission.

• MAC_DATA.indication

Receive PDUs from MAC service.

• MAC_DELETE_SERVICE_FLOW.request/response

Delete service flow. Would likely be invoked only for dynamically created service flows, not provi-sioned service flows. Deletion of a service flow uses DSD signaling.

449



450


Appendix II Example Preamble Sequence

II.1 Introduction

A programmable preamble superstring, up to 1536 bits long, is part of the channel-wide profile or attributes,common to the all burst profiles on the channel (Section 8.3.3, Table 8-18), but with each burst profile able tospecify the start location within this sequence of bits and the length of the preamble (Section 8.3.3, Table 8-19).The first bit of the Preamble Pattern is designated by the Preamble Value Offset as described in Table 8-19,Section 8.3.3. The first bit of the Preamble Pattern is the first bit into the symbol mapper (Figure 6-2, “TDMAUpstream Transmission Processing,” on page 42 and Figure 6-3, “S-CDMA Upstream TransmissionProcessing,” on page 43), and is the first symbol of the burst (see Section 6.2.13, “Symbol Mapping,” onpage 64). As an example, per Table 8-19, for Preamble Offset Value = 100, the 101st bit of the preamblesuperstring is the first bit into the symbol mapper, and the 102nd bit is the second bit into the mapper, and ismapped to Q1, and so. An example 1536-bit-long preamble superstring is given in Section II.2.

II.2 Example Preamble Sequence

The following is the example1536-bit preamble sequence:

Bits 1 through 128:

1100 0011 1111 0000 0011 0011 1111 1100 0011 0011 0000 0011 1100 0000 0011 0000

0000 1110 1101 0001 0001 1110 1110 0101 0010 0101 0010 0101 1110 1110 0010 1110

Bits 129 through 256:

0010 1110 1110 0010 0010 1110 1110 1110 1110 1110 0010 0010 0010 1110 1110 0010

1110 1110 1110 0010 1110 0010 1110 0010 0010 0010 0010 1110 0010 0010 1110 0010


0010 1010 0110 0110 0110 1110 1110 1110 0010 1110 0010 1110 0010 1110 0110 1010

0010 1110 1110 1010 0110 1110 0110 0010 0110 1110 1010 1110 0010 1010 0110 0010


0010 1110 0110 1110 0010 1010 1010 0110 0010 1110 0110 0110 1110 0010 0010 0110

0010 1110 0010 1010 0010 1110 0110 0010 0010 1010 0010 0110 0010 1010 0010 1010


0010 1110 0110 1110 0110 0110 1110 0010 0110 1010 0110 0010 1110 1110 1010 0010

1110 1110 0010 1110 1110 1110 0010 1110 1110 0010 1110 0010 0010 1110 0010 0010

451



1110 1110 1110 0010 0010 0010 1110 0010 1110 1110 1110 1110 0010 0010 1110 0010

1110 0010 0010 0010 1110 1110 0010 0010 0010 0010 1110 0010 0010 0010 0010 1110


0011 0000 1111 1100 0000 1100 1111 1111 0000 1100 1100 0000 1111 0000 0000 1100

0000 0000 1111 1111 1111 0011 0011 0011 1100 0011 1100 1111 1100 1111 0011 0000


1100 0011 1111 0000 0011 0011 1111 1100 0011 0011 0000 0011 1100 0000 0011 0000

0000 1110 1101 0001 0001 1110 1110 0101 0010 0101 0010 0101 1110 1110 0010 1110


0010 1110 1110 0010 0010 1110 1110 1110 1110 1110 0010 0010 0010 1110 1110 0010

1110 1110 1110 0010 1110 0010 1110 0010 0010 0010 0010 1110 0010 0010 1110 0010


0010 0010 1110 1110 1110 1110 1110 1110 0010 1110 0010 1110 0010 1110 1110 0010

0010 1110 1110 0010 1110 1110 1110 0010 1110 1110 0010 1110 0010 0010 1110 0010

Bits 1281 through 1408

1100 1100 1111 0000 1111 1111 1100 0000 1111 0011 1111 0011 0011 0000 0000 1100

0011 0000 0011 1111 1111 1100 1100 1100 1111 0000 1111 0011 1111 0011 1100 1100


0011 0000 1111 1100 0000 1100 1111 1111 0000 1100 1100 0000 1111 0000 0000 1100

0000 0000 1111 1111 1111 0011 0011 0011 1100 0011 1100 1111 1100 1111 0011 0000

452


Appendix III Multiple Upstream Channels

This section is informative. In case of conflict between this section and any normative section of thisspecification, the normative section takes precedence.

Section 7.2 describes support for multiple upstream and multiple downstream channels within a DOCSISdomain. The permutations that a CM may see on the cable segment it is attached to include:

• single downstream and single upstream per cable segment

• single downstream and multiple upstreams per cable segment

• multiple downstreams and single upstream per cable segment

• multiple downstreams and multiple upstreams per cable segment

A typical application that will require one upstream and one downstream per CM is web browsing. Webbrowsing tends to have asymmetrical bandwidth requirements that match closely to the asymmetrical bandwidthof DOCSIS.

A typical application that will require access to one of multiple upstreams per CM is IP Telephony. IP Telephonytends to have symmetrical bandwidth requirements. If there is a large concentration of CMs in a geographicalarea all served by the same fiber node, more than one upstream may be required in order to provide sufficientbandwidth and prevent call blocking.

A typical application that will require access to one of multiple downstreams per CM is IP streaming video. IPstreaming video tends to have extremely large downstream bandwidth requirements. If there is a largeconcentration of CMs in a geographical area all served by the same fiber node, more than one downstream maybe required in order to provide sufficient bandwidth and to deliver multiple IP Video Streams to multiple CMs.

A typical application that will require multiple downstreams and multiple upstreams is when the aboveapplications are combined, and it is more economical to have multiple channels than it is to physically subdividethe HFC network.

The role of the CM in these scenarios would be to be able to move between multiple upstreams and betweenmultiple downstreams. The role of the CMTS would be to manage the traffic load to all attached CMs, andbalance the traffic between the multiple upstreams and downstreams by dynamically moving the CMs basedupon their resource needs and the resources available.

This appendix looks at the implementation considerations for these cases. Specifically, the first and lastapplication are profiled. These examples are meant to illustrate one topology and one implementation of thattopology.

III.1 Single Downstream and Single Upstream per Cable Segment

This section presents an example of a single downstream channel and four upstream channels. In Figure III-1, thefour upstream channels are on separate fibers serving four geographical communities of modems.

453


The CMTS has access to the one downstream and all four upstreams, while each CM has access to the onedownstream and only one upstream.

In this topology, the CMTS transmits Upstream Channel Descriptors (UCDs) and MAPs for each of the fourupstream channels related to the shared downstream channel.

Unfortunately, each CM cannot determine which fiber branch it is attached to because there is no way to conveythe geographical information on the shared downstream channel. At initialization, the CM randomly picks aUCD and its corresponding MAP. The CM then chooses an Initial Maintenance opportunity on that channel andtransmits a Ranging Request.

The CMTS will receive the Ranging Request and will redirect the CM to the appropriate upstream channelidentifier by specifying the upstream channel ID in the Ranging Response. The CM MUST then use the channelID of the Ranging Response, not the channel ID on which the Ranging Request was initiated. This is necessaryonly on the first Ranging Response received by the CM. The CM SHOULD continue the ranging processnormally and proceed to wait for station maintenance IEs.

From then on, the CM will be using the MAP that is appropriate to the fiber branch to which it is connected. Ifthe CM ever has to redo initial ranging, it may start with its previous known UCD instead of choosing one atrandom.

Figure III-1 Single Downstream and Single Upstream Channels per CM

CMTS CMsFiber Nodes

fD0

fU0

fU3

fU2

fU1

Fiber CoaxCoax

Downstream Laser &Upstream Receiver

454


A number of constraints are imposed by this topology:

• All Initial Maintenance opportunities across all fiber nodes must be aligned. If there are multiple logicalupstreams sharing the same spectrum on a fiber, then the Initial Maintenance opportunities for each of thelogical upstreams MUST align with the initial Maintenance opportunity of at least one logical upstream withthe same center frequency on each fiber node.When the CM chooses a UCD to use and then subsequentlyuses the MAP for that channel, the CMTS must be prepared to receive a Ranging Request at that Initial Main-tenance opportunity. Note that only the initialization intervals must be aligned. Once the CM is successfullyranged on an upstream channel, its activities need only be aligned with other users on the same upstreamchannel. In Figure III-1, ordinary data transmission and requests for bandwidth may occur independentlyacross the four upstream channels.

• All of the upstream channels on different nodes should operate at the same frequency or frequencies unless itis known that no other upstream service will be impacted due to a CM transmission of a Ranging Request ona “wrong” frequency during an Initial Maintenance opportunity. If the CM chooses an upstream channeldescriptor arbitrarily, it could transmit on the wrong frequency if the selected UCD applied to an upstreamchannel on a different fiber node. This could cause initial ranging to take longer. However, this might be anacceptable system trade-off in order to keep spectrum management independent between cable segments.

• All of the upstream channels may operate at different modulation rates. However, there is a trade-off involvedbetween the time it takes to acquire ranging parameters and flexibility of upstream channel modulation rate.If upstream modulation rates are not the same, the CMTS would be unable to demodulate the RangingRequest if it was transmitted at the wrong modulation rate for the particular upstream receiver of the channel.The result would be that the CM would retry as specified in the RFI specification and then would eventuallytry other upstream channels associated with the currently used downstream. Increasing the probability ofattempting ranging on multiple channels increases CM initialization time but using different modulation rateson different fiber nodes allows flexibility in setting the degree of burst noise mitigation.

• All Initial Maintenance opportunities on different channels may use different burst characteristics so that theCMTS can demodulate the Ranging Request. Again, this is a trade-off between time to acquire ranging andexercising flexibility in setting physical layer parameters among different upstream channels. If upstreamburst parameters for Initial Maintenance are not the same, the CMTS would be unable to demodulate theRanging Request if it was transmitted with the wrong burst parameters for the particular channel. The resultwould be that the CM would retry the Ranging Request as specified in the RFI specification and then wouldeventually try other upstream channels associated with the currently used downstream. Increasing the proba-bility of attempting ranging on multiple channels increases CM initialization time but using different burstparameters for Initial Maintenance on different fiber nodes allows the ability to set parameters appropriate forplant conditions on a specific node.

III.2 Multiple Downstreams and Multiple Upstreams per Cable Segment

This section presents a more complex set of examples of CMs which are served by several downstream channelsand several upstream channels and where those upstream and downstream channels are part of one MACdomain. The interaction of initial ranging, normal operation, and Dynamic Channel Change are profiled, as wellas the impact of the multiple downstreams using synchronized or unsynchronized timestamps.

Synchronized timestamps refer to both downstream paths transmitting a time stamp that is derived from acommon clock frequency and have common time bases. The timestamps on each downstream do not have to betransmitted at the same time in order to be considered synchronized.

III.2.1 Topologies

Suppose two downstream channels are used in conjunction with four upstream channels as shown in Figure III-2.In all three topologies, there are two geographical communities of modems, both served by the same twodownstream channels. The difference in the topologies is found in their upstream connectivity.

455


Figure III-2 Multiple Downstream and Multiple Upstream Channels per CM

CMTS CMsFiber NodesDownstream Laser &Upstream ReceiverfD0

fD1

fU0

fU3

fU2

fU1

Topology

#1

fD0

fD1

fU0

fU3

fU2

fU1

Topology

#2

Fiber CoaxCoax

fD0

fD1

fU0

fU3

fU2

fU1

Topology

#3

456


Topology #1 has the return path from each fiber node connected to a dedicated set of upstream receivers. A CMwill see both downstream channels, but only one upstream channel which is associated with one of the twodownstream channels.

Topology #2 has the return path from each fiber node combined and then split across all upstream receivers. ACM will see both downstream channels and all four upstream channels in use with both downstream channels.

Topology #3 has the return path from each fiber node split and then sent to multiple upstream receivers, eachassociated with a different downstream channel. A CM will see both downstream channels, and one upstreamchannel associated with each of the two downstream channels.

Topology #1 is the typical topology in use. Movement between downstreams can only occur if the timestamps onboth downstreams are synchronized. Topology #2 and Topology #3 are to compensate for downstreams whichhave unsynchronized timestamps, and allow movement between downstream channels as long as the upstreamchannels are changed at the same time.

The CMs are capable of single frequency receive and single frequency transmit.

III.2.2 Normal Operation

Table III-1 lists MAC messages that contain Channel IDs.

With unsynchronized timestamps:

• Since upstream synchronization relies on downstream timestamps, each upstream channel must be associatedwith the time stamp of one of the downstream channels.

• The downstream channels should only transmit MAP messages and UCD messages that pertain to their asso-ciated upstream channels.

With synchronized timestamps:

• Since upstream synchronization can be obtained from either downstream channel, all upstreams can be asso-ciated with any downstream channel.

• All MAPs and UCDs for all upstream channels should be sent on all downstream channels. The UCD mes-sages contains a Downstream Channel ID so that the CMTS can determine with the RNG-REQ messagewhich downstream channel the CM is on. Thus the UCD messages on each downstream will contain differentDownstream Channel IDs even though they might contain the same Upstream Channel ID.

Table III-1 MAC Messages with Channel IDs

MAC Message Downsteam Channel ID Upstream Channel ID

UCD Yes Yes

MAP No Yes

RNG-REQ Yes No

RNG-RSP No Yes

DCC-REQ Yes Yes

457


III.2.3 Initial Ranging

When a CM performs initial ranging, the topology is unknown and the timestamp consistency betweendownstreams is unknown. Therefore, the CM chooses either downstream channel and any one of the UCDs senton that downstream channel.

In both cases:

• The upstream channel frequencies within a physical upstream or combined physical upstreams must be dif-ferent.

• The constraints specified in Section III.1 apply.

III.2.4 Dynamic Channel Change

With unsynchronized timestamps:

• When a DCC-REQ is given, it must contain new upstream and new downstream frequency pairs that are bothassociated with the same timestamp.

• When the CM resynchronizes to the new downstream, it must allow for timestamp resynchronization withoutre-ranging unless instructed to do so with the DCC-REQ command.

• Topology #1 will support channel changes between local upstream channels present within a cable segment,but will not support changes between downstream channels. Topology #2 and #3 will support upstream anddownstream channel changes on all channels within the fiber node as long as the new upstream and down-stream channel pair are associated with the same timestamp.

With synchronized timestamps:

• Downstream channel changes and upstream channel changes are independent of each other.

Topologies #1, #2, and #3 will support changes between all upstream and all downstream channels present withinthe cable segment.

458


Appendix IV DOCSIS Transmission and Contention Resolution

IV.1 Introduction

This appendix clarifies how the DOCSIS transmission and contention-resolution algorithms work. It contains afew minor simplifications and assumptions, but should be useful to help clarify this area of the specification.

The simplifications include:

• The text does not explicitly discuss packet arrivals while deferring or waiting for pending grants, nor thesizing of piggyback requests.

• The CM always sends a Piggyback Request for the next frame in the last fragment and not inside one of theheaders of the original frame.1

• Much of this applies to concatenation, but no attempt is made to address all the subtleties of that situation.

The assumptions include, among others:

• The assumption is made that a Request always fits in any Request/Data region.

• When a piggyback request is sent with a contention data packet, the state machine only checks for the Grantto the Request and assumes the Data Ack for the contention data packet was supplied by the CMTS.

Figure IV-1 Transmission & Deference State Transition Diagram

1. This bulleted item added per RFI2-N-02093 by RKV on 10/28/02.

Idle

Deferring

Data AckPending

GrantPending

Tx Request OR

Tx Cont.

!Queue_Empty

Data Ack’ed OR

Map:Defer

Tx Resv.Request

Data w/o

Tx Resv. Data w/o

Tx Resv.Data w/o

Piggyback OR

Tx Resv.Data w/Piggyback

Piggyback

Piggyback

Tx Resv./Cont. Dataw/Piggyback OR

Grant Pending

Too ManyRetries OR

Too ManyRetries ORMap Lost

GrantPending

Retry

Retry

(TX Frag w/oPiggyback && Last)TX Frag w/Piggyback OR

(TX Frag w/o Piggyback&& !Last) OR

459


IV.2 Variable Definitions

Start = Data Backoff Start field from Map “currently in effect”

End = Data Backoff End field from Map “currently in effect”

Window = Current backoff window

Random[n] = Random number generator that selects a number between 0 and n-1

Defer = Number of Transmit Opportunities to defer before transmitting

Retries = Number of transmissions attempted without resolution

Tx_time = Saved time of when Request or Request/Data was transmitted

Ack_time = Ack Time field from current Map

Piggyback = Flag set whenever a piggyback REQ is added to a transmit pkt

Queue_Empty = Flag set whenever the data queue for this SID is empty

Lost_Map = Flag set whenever a MAP is lost & we’re in state Data Ack Pending

my_SID = Service ID of the queue that has a packet to transmit

pkt size = Data packet size including MAC and physical layer overhead (including piggyback if used)

frag_size = Size of the fragment

Tx_Mode = {Full_Pkt; First_Frag; Middle_Frag; Last_Frag}

min_frag = Size of the minimum fragment

IV.3 State Examples

IV.3.1 Idle — Waiting for a Packet to Transmit

Window = 0;Retries = 0;

Wait for !Queue_Empty; /* Packet available to transmit */CalcDefer();go to Deferring

460


IV.3.2 Data Ack Pending — Waiting for Data Ack only

Wait for next Map;

if (Data Acknowledge SID == my_SID) /* Success! CMTS received data packet */go to state Idle;

else if (Ack_time > Tx_time) /* COLLISION!!! or Pkt Lost or Map Lost */{

if (Lost_Map)go to state Idle; /* Assume pkt was ack’ed to avoid sending duplicates */

elseRetry();

}

stay in state Data Ack Pending;

IV.3.3 Grant Pending — Waiting for a Grant

Wait for next Map;

while (Grant SID == my_SID)UtilizeGrant();

if (Ack_time > Tx_time) /* COLLISION!!!!! or Request denied/lost or Map Lost */Retry();

stay in state Grant Pending

IV.3.4 Deferring — Determine Proper Transmission Timing & Transmit

if (Grant SID == my_SID) /* Unsolicited Grant */{

UtilizeGrant();}else if (unicast Request SID == my_SID) /* Unsolicited Unicast Request */{

transmit Request in reservation;Tx_time = time;

go to state Grant Pending;}else{

for (each Request or Request/Data Transmit Opportunity){

if (Defer != 0)Defer = Defer - 1; /* Keep deferring until Defer = 0 */

else{

if (Request/Data tx_op) and (Request/Data size >= pkt size)/* Send data in contention */

{transmit data pkt in contention;Tx_time = time;

if (Piggyback)go to state Grant Pending;

elsego to state Data Ack Pending;

}else /* Send Request in contention */{

transmit Request in contention;

461


Tx_time = time;

go to state Grant Pending;}

}}

}

Wait for next Map;stay in state Deferring

IV.4 Function Examples

IV.4.1 CalcDefer() — Determine Defer Amount

if (Window < Start)Window = Start;

if (Window > End)Window = End;

Defer = Random[2^Window];

IV.4.2 UtilizeGrant() — Determine Best Use of a Grant

if (Grant size >= pkt size) /* CM can send full pkt */{

transmit packet in reservation;Tx_time = time;Tx_mode = Full_pkt

if (Piggyback)go to state Grant Pending

elsego to state Idle;

}else if (Grant size < min_frag && Grant Size > Request size)

/* Can’t send fragment, but can send a Request */{

transmit Request in reservation;Tx_time = time;go to state Grant Pending;

}else if (Grant size == 0) /* Grant Pending */

go to state Grant Pending;else{

while (pkt_size > 0 && Grant SID == my_SID){

if (Tx_mode == Full_Pkt)Tx_mode = First_frag;

elseTx_mode = Middle_frag;

pkt_size = pkt_size - frag_size;if (pkt_size == 0)

Tx_mode = Last_frag;

if (another Grant SID == my_SID) /* multiple grant mode */piggyback_size = 0

else

462


piggyback_size = pkt_size /* piggyback mode */

if (piggyback_size > 0)transmit fragment with piggyback request for remainder of packet in reservation

elsetransmit fragment in reservation;

}go to state Grant Pending;

}

IV.4.3 Retry()

Retries = Retries + 1;if (Retries > 16){

discard pkt, indicate exception conditiongo to state Idle;

}

Window = Window + 1;

CalcDefer();

go to state Deferring;

463



464


Appendix V IGMP Example

Section 5.3.1 defines the requirements for CMTS and CM support of IGMP signaling. This appendix provides anexample CM passive-mode state machine for maintaining membership of a single multicast group.

Figure V-1 IGMP Support – CM passive mode

V.1 Events

E1: MR received on CPE I/f

E2: M1 timer expired

E3: MQ received on RF I/f

E4: MR received on RF I/f

E5: M2 timer expired

E6: Auth Failure1

1. SA-MAP response returns an error code of 7 - “not authorized for requested downstream traffic flow”

Idle(No members)

Joining

Joined

E1/A1

E1/A2

E1/A3E2/A4

E3/A5

E4/A6

E5/A7

E6/A7

E6/A7

465


V.2 Actions

A1: MQI= 125 sec; QRI = 10 sec; Start M1 timer with random value between 0 and 3 sec; start M2 timer =

2*MQI+QRI; start TEK machine, if necessary1; add multicast addr to multicast filter

A2: discard MR packet

A3: reset M2 timer = 2*MQI+QRI; start M1 timer with random value between 0 and 3 sec

A4: transmit MR on RF I/f; set I = current time

A5: recompute MQI = MAX(125, current time – I); set I = current time, forward MQ on CPE i/f

A6: cancel M1 timer

A7: delete multicast addr from multicast filter

1. If the multicast traffic is encrypted, a TEK machine needs to be started to decrypt the encrypted multicastpackets. To determine whether the multicast is encrypted, the CM makes a SA-MAP request to the CMTS toget the associated SAID of the multicast group address. If the SA-MAP response returns an SAID, then a TEKmachine is started. No TEK machine is necessary, if the SA-MAP response indicates that the multicast trafficis not encrypted. The SA-MAP response may also indicate that the CM is not authorized to receive this multi-cast traffic. In which case, the CM terminates the multicast state machine and stops forwarding the multicasttraffic.

466


Appendix VI Unsolicited Grant Services

This appendix discusses the intended use of the Unsolicited Grant Service (UGS) and Unsolicited Grant Servicewith Activity Detection (UGS-AD) and includes specific examples.

VI.1 Unsolicited Grant Service (UGS)

VI.1.1 Introduction

Unsolicited Grant Service is an Upstream Flow Scheduling Service Type that is used for mapping constant bitrate (CBR) traffic onto Service Flows. Since the upstream is scheduled bandwidth, a CBR service can beestablished by the CMTS scheduling a steady stream of grants. These are referred to as unsolicited because thebandwidth is predetermined, and there are no ongoing requests being made.

The classic example of a CBR application of interest is Voice over Internet Protocol (VoIP) packets. Otherapplications are likely to exist as well.

Upstream Flow Scheduling Services are associated with Service Flows, each of which is associated with a singleService ID (SID). Each Service Flow may have multiple Classifiers. Each Classifier may be associated with aunique CBR media stream. Classifiers may be added and removed from a Service Flow. Thus, the semantics ofUGS must accommodate single or multiple CBR media streams per SID.

For the discussion within this appendix, a Subflow will be defined as the output of a Classifier. Since a VoIPsession is identified with a Classifier, a Subflow in this context refers to a VoIP session.

VI.1.2 Configuration Parameters

• Nominal Grant Interval

• Unsolicited Grant Size

• Tolerated Grant Jitter

• Grants per Interval

Explanations of these parameters and their default values are provided in Annex C.

VI.1.3 Operation

When a Service Flow is provisioned for UGS, the Nominal Grant Interval is chosen to equal the packet intervalof the CBR application. For example, VoIP applications with 10 ms packet sizes will require a Nominal GrantInterval of 10 ms. The size of the grant is chosen to satisfy the bandwidth requirements of the CBR applicationand relates directly to the length of the packet.

When multiple Subflows are assigned to a UGS service, multiple grants per interval are issued. There is noexplicit mapping of Subflows to grants. The multiple grants per interval form a pool of grants in which anysubflow can use any grant.

It is assumed in this operational example the default UGS case of no concatenation and no fragmentation.

467


VI.1.4 Jitter

Figure VI-1 shows the relationship between Grant Interval and Tolerated Grant Jitter, and shows an example ofjitter on subflows.

For only one Grant per Interval, the Tolerated Grant Jitter is the maximum difference between the actual granttime (ti’) and the nominal grant time (ti). For multiple Grants per Interval, the Tolerated Grant Jitter is themaximum difference between the actual time of the last grant in the group of grants and the nominal grant time(ti). If the arrival of any grant is at ti’, then ti <= ti’ <= ti+jitter.

Figure VI-1 demonstrates how a Subflow will be jittered even though the individual grants may not move fromtheir relative position. During the first interval, three VoIP sessions are established, and they happen fall on thethree grants. In the second interval, VoIP session 3 has been torn down. Since the CMTS does not know whichSubflow is associated with which grant, it decides to remove the first grant. The remaining two calls shift to theother two grants. In the third interval, a new VoIP session 4 and a new grant have been added. The new callhappens to fall on the new grant. The net effect is that the Subflows may move around within their jitter interval.

The advantage of a small jitter interval is that the VoIP receive jitter buffer may be kept small. The disadvantageis that this places a scheduling constraint on the CMTS.

The boundary of a Nominal Grant Interval is arbitrary and is not communicated between the CMTS and the CM.

Note: More dramatic events like the loss of a downstream MAP, or the frequency hopping of an upstream may cause subflowsto jitter outside of this jitter window.

VI.1.5 Synchronization Issues

There are two synchronization problems that occur when carrying CBR traffic such as VoIP sessions across anetwork. The first is a frequency mismatch between the source clock and the destination clock. This is managedby the VoIP application, and is beyond the scope of this specification. The second is the frequency mismatchbetween the CBR source/sinks, and the bearer channel that carries them.

Specifically, if the clock that generates the VoIP packets towards the upstream is not synchronized with the clockat the CMTS which is providing the UGS service, the VoIP packets may begin to accumulate in the CM. Thiscould also occur if a MAP was lost, causing packets to accumulate.

Figure VI-1 Example Jitter with Multiple Grants per SID

1 141 222 3

Grant Interval

Jitter JitterJitter

ti ti' ti+jittert0

Grant Interval Grant Interval

Grants per SID

Subflows 1 141 222 3

Nominal Grant Interval

Max ToleratedJitter

ti ti' ti+jittert0

Grants per SID

Subflows

Max ToleratedJitter

Max ToleratedJitter

Nominal Grant Interval Nominal Grant Interval

468


When the CM detects this condition, it asserts the Queue Indicator in the Service Flow EH Element. The CMTSwill respond by issuing an occasional extra grant so as to not exceed 1% of the provisioned bandwidth. (Thiscorresponds to a maximum of one extra grant every one hundred grants). The CMTS will continue to supply thisextra bandwidth until the CM deasserts this bit.

A similar problem occurs in the downstream. The far end transmitting source may not be frequency synchronizedto the clock which drives the CMTS. Thus the CMTS SHOULD police at a rate slightly higher than the exactprovisioned rate to allow for this mismatch and to prevent delay buildup or packet drops at the CMTS.

VI.2 Unsolicited Grant Service with Activity Detection (UGS-AD)

VI.2.1 Introduction

Unsolicited Grant Service with Activity Detection (UGS-AD) is an Upstream Flow Scheduling Service Type.This section describes one application of UGS-AD which is the support for Voice Activity Detection (VAD).VAD is also known as Silence Suppression and is a voice technique in which the transmitting CODEC sendsvoice samples only when there is significant voice energy present. The receiving CODEC will compensate forthe silence intervals by inserting silence or comfort noise equal to the perceived background noise of theconversation.

The advantage of VAD is the reduction of network bandwidth required for a conversation. It is estimated that60% of a voice conversation is silence. With that silence removed, that would allow a network to handlesubstantially more traffic.

Subflows in this context will be described as active and inactive. Both of these states of within the MAC LayerQOS state known as Active.

VI.2.2 MAC Configuration Parameters

The configuration parameters include all of the normal UGS parameters, plus:

• Nominal Polling Interval

• Tolerated Poll Jitter

Explanation of these parameters and their default values are provided in Annex C.

VI.2.3 Operation

When there is no activity, the CMTS sends polled requests to the CM. When there is activity, the CMTS sendsUnsolicited Grants to the CM. The CM indicates the number of grants per interval which it currentlyrequires in the active grant field of the UGSH in each packet of each Unsolicited Grant. The CM mayrequest up to the maximum active Grants per Interval. The CM constantly sends this state information so that noexplicit acknowledgment is required from the CMTS.

It is left to the implementation of the CM to determine activity levels. Implementation options include:

• Having the MAC layer service provide an activity timer per Classifier. The MAC layer service would mark aSubflow inactive if packets stopped arriving for a certain time, and mark a Subflow active the moment a newpacket arrived. The number of Grants requested would equal the number of active Subflows.

• Having a higher layer service entity such as an embedded media client which indicates activity to the MAClayer service.

469


When the CM is receiving polled requests and it detects activity, the CM requests enough bandwidth for oneGrant per Interval. If activity is for more than one Subflow, the CM will indicate this in the active grant field ofthe UGSH beginning with the first packet it sends.

When the CM is receiving Unsolicited Grants, then detects new activity, and asks for one more grant, there willbe a delay in time before it receives the new grant. During that delay, packets may build up at the CM. When thenew Unsolicited Grant is added, the CMTS will burst extra Grants to clear out the packet buildup.

When the CM is receiving Unsolicited Grants, then detects inactivity on a Subflow and asks for one less grant,there will be a delay in time before the reduction in Grants occurs. If there has been any build up of packets in theupstream transmit queue, the extra grants will reduce or empty the queue. This is fine, and keeps system latencylow. The relationship of which Subflow is getting which specific grant will also change. This effect appears aslow frequency jitter that the far end must manage.

When the CM is receiving Unsolicited Grants and detects no activity on any of its Subflows, it will send onepacket with the active grants field of the UGSH set to zero grants, and then cease transmission. The CMTS willswitch from UGS mode to Real Time Polling mode. When activity is again detected, the CM sends a request inone of these polls to resume delivery of Unsolicited Grants. The CMTS ignores the size of the request andresumes allocating Grant Size grants to the CM.

It is not necessary for the CMTS to separately monitor packet activity since the CM does this already. Worst case,if the CMTS misses the last packet which indicated zero grants, the CMTS and CM would be back in sync at thebeginning of the next talk spurt. Because of this scenario, when the CM goes from inactive to active, the CMmust be able to restart transmission with either Polled Requests or Unsolicited Grants.

VI.2.4 Example

Figure VI-2 shows an example of a single G.711 (64 kbps) voice call with a packet size of 10 ms, and a receivejitter buffer that requires a minimum of 20 ms of voice (thus 2 packets) before it will begin playout.

Figure VI-2 VAD Start-Up and Stop

20 3010 40 500

G.711CODEC

Tx Queue

Polled Requests

Unsolicited Grants

Data on Upstream

Play Out

Voice

ms

470


Assume voice begins at time zero. After a nominal processing delay and a 10 ms packetization delay, the DSPCODEC generates voice packets which are then transferred to the upstream transmit queue. The next PolledRequest is used which results in the start of the Unsolicited Grants some time later. Additional UnsolicitedGrants are immediately issued to clear out the upstream queue.

These packets traverse the network and arrive at the receive jitter buffer. The 20 ms minimum jitter buffer is metwhen the second packet arrives. Because the packets arrived close together, only an additional few millisecondsof latency has been added. After a nominal processing delay, playout begins.

When the voice spurt ends, the CM sends one remaining packet with no payload and with the active grants fieldof the UGSH set to zero grants. Some time later, UGS stops, and Real Time Polling begins.

VI.2.5 Talk Spurt Grant Burst

The extra burst of Unsolicited Grants when a flow becomes active is necessary because the jitter buffer at thereceiving CODEC typically waits to have a minimum amount of voice samples before beginning the playout.Any delay between the arrival of these initial packets will add to the final latency of the phone call. Thus, thesooner the CMTS recognizes that the CM has packets to send and can empty the CM’s buffer, the sooner thosepacket will reach the receiver, and the lower the latency that will be incurred in the phone call.

It is an indeterminate problem as to how many grants must be burst. When the CM makes its request for anadditional grant, one voice packet has already accumulated. The CM has no idea how many extra grants torequest as it has no idea of the round trip response time it will receive from the CMTS, and thus how manypackets may accumulate. The CMTS has a better idea, although it does not know the far end jitter bufferrequirements.

The solution is for the CMTS to choose the burst size, and burst these grants close together at the beginning ofthe talk spurt. This occurs when moving from Real Time Polling to UGS, and when increasing the number ofUGS Grants per Interval.

A typical start-up latency that will be introduced by the Request to Grant response time is shown in Table VI-1.

Table VI-1 Example Request to Grant Response Time

Variable Example Value

1. The time taken from when the voice packet was created tothe time that voice packet arrives in the CM upstreamqueue.

0 - 1 ms

2. The time until a polled request is received. The worst casetime is the Polled Request Interval.

0 - 5 ms

3. The Request-Grant response time of the CMTS. This valueis affected by MAP length and the number of outstandingMAPS.

5 - 15 ms

4. The round trip delay of the HFC plant including thedownstream interleaving delay.

1 - 5 ms

Total 6 - 26 ms

471


This number will vary between CMTS implementations, but a reasonable number of extra grants to expect fromthe example above would be:

Once again it is worth noting that the CMTS and CM cannot and do not associate individual Subflows withindividual grants. That means that when current Subflows are active and a new Subflow becomes active, the newSubflow will immediately begin to use the existing pool of grants. This potentially reduces the start up latency ofnew talk spurts, but increases the latency of the other Subflows. When the burst of grants arrives, it is shared withall the Subflows, and restores or even reduces the original latency. This is a jitter component. The more Subflowsthat are active, the less impact that adding a new Subflow has.

VI.2.6 Admission Considerations

Note that when configuring the CMTS admission control, the following factors must be taken into account.

VAD allows the upstream to be over provisioned. For example, an upstream that might normally handle 24 VoIPsessions might be over provisioned as high as 36 (50%) or even 48 (100%). Whenever there is over provisioning,there exists the statistical possibility that all upstream VoIP sessions may become active. At that time, the CMTSmay be unable to schedule all the VoIP traffic. Additionally, the talk spurt grant bursts would be stretched out.CM implementations of VAD should recognize this possibility, and set a limit as to how many packets they willallow to accumulate on its queue.

Occasional saturation of the upstream during VAD can be eliminated by provisioning the maximum number ofpermitted VoIP sessions to be less than the maximum capacity of the upstream with all voice traffic (24 in theprevious example). VAD would cause the channel usage to drop from 100% to around 40% for voice, allowingthe remaining 60% to be used for data and maintenance traffic.

Table VI-2 Example Extra Grants for New Talk Spurts

UGS Interval Extra Grants for New Talk Spurts

10 ms 2

20 ms 1

30 ms 0

472


Appendix VII S-CDMA Framing

This appendix is informative. In case of conflict between this section and any normative section of thisspecification, the normative section takes precedence.

Please note that the pseudo-code below is specific to the case of a single burst using all spreading codes.

VII.1 Coded Subsymbol Numbering

The following code sample contains a short algorithmic description of the operation of the address generator forthe coded subsymbols. The address generator for the coded subsymbols fills rows first using the interleaver stepsize parameter (step in the listing) to step through the spreading intervals within a row. Each step is performedusing a modified modulo algorithm which allows the use of interleaver step size and spreading intervals perframe with common divisors. After each row is filled, the next row is begun with the first spreading interval. Inthe following listings, the index “i” is initialize to the value “1” and coded_col0 is defined as “0”.

for( row = FIRST_ROW; row <= LAST_ROW; row++ ){

coded_col = 0;store_coded( row, coded_col );/* Store the coded portion of the symbol (or preamble) to (row,coded_col) */for( i = 1; i < framelen; i++ ){

coded_col = coded_col + Interleaver_step_size;

if( mod( i, framelen / gcd( step, framelen ) ) == 0 )coded_col = coded_col + 1; /* gcd is greatest common divisor */

coded_col = mod( coded_col, framelen );store_coded( row, coded_col );/* Store the coded portion of the symbol (or preamble) to (row,coded_col) */

}}

473


VII.2 Uncoded Subsymbol Numbering

The following is a short algorithmic description of the operation of the address generator for uncodedsubsymbols. The generator fills columns within a subframe first. The row index increments by one for eachuncoded subsymbol. At the end of the subframe, the column index is incremented and the row index set to thefirst row of the subframe. After completing a subframe, the next subframe begins with the next uncodedsubsymbol.

uncoded_col = 0;uncoded_row = FIRST_ROW;while( uncoded_row <= LAST_ROW){

if( ( uncoded_row + R ) > LAST_ROW )Rprime = LAST_ROW - uncoded_row + 1;

elseRprime = R;

for( i = 0; i < Rprime; i++){

/* Check whether (uncoded_row,uncoded_col) is a preamble location.* If it is, go to next location */

if( not_preamble( uncoded_row, uncoded_col ) )store_uncoded( uncoded_row, uncoded_col, unc_sym );

uncoded_row = uncoded_row + 1;}

uncoded_row = uncoded_row - Rprime;uncoded_col = uncoded_col + 1;if (uncoded_col >= framelen){

uncoded_col = 0;uncoded_row = uncoded_row + R;

}}

FIRST_ROW and LAST_ROW are, respectively, the first and last row (i.e., code) in each frame spanned by thegrant. FIRST_ROW can be between 0 and 127 in the first frame of the allocation and is 0 in any other frames thatthe grant may span (if any). LAST_ROW can be between 0 to 127 in the last frame of the burst and is 127 for anyother frame (if any).

VII.3 Framer Output Numbering

The following code sample contains a short algorithmic description of the operation of the address generator forthe output symbols. The address generator for the output symbols is used to access both the coded and uncodedsubsymbol memories. The output address generator accesses all of the rows (codes) of a spreading interval firstfollowed by subsequent spreading intervals.

for( col=0; col < framelen; col++ )for( row=0; row < ACTIVE_CODES; row++ )

outsym = get_data( row, col );

VII.4 Comments

In all of the samples, the number of iterations for the loop is not always correct since an allocation can be lessthan the number of codes. In Section VII.2, the listing supports the case of a shortened sub-frame.

474


Appendix VIII Ambient Temperature and Wind Loading Effects

This appendix discusses possible ambient temperature change and dynamic wind loading effects relevant tooperating a system with DOCSIS 2.0 CMs and CMTSes. The intent of this appendix is to describe possibleapproaches for dealing with these issues. The relationships between the timing variation of the received upstreamsignal and the rate of change of these ambient plant conditions is discussed. However, measured field dataproviding the statistics of the ambient conditions used in these relationships is not available, so it is not possibleat the time of writing to determine the magnitude or frequency of occurrence of these conditions on operationalcable systems. This appendix is not intended to be an exhaustive discussion of either these issues or solutions.

The following issues are discussed in this appendix:

• Synchronization tolerances to plant delay variations

• Changes in propagation delay due to temperature changes

• Changes in propagation delay due to wind in the case of aerial cable plant

VIII.1 Synchronization Tolerances to Plant Delay Variations

The CMTS receiver synchronization requirements for S-CDMA and Advanced TDMA are identical for the samesignal constellation and symbol rates. However, for S-CDMA, burst synchronization is accomplished to a finedegree through the ranging process, while for TDMA, burst synchronization is accomplished to a coarse degreethrough the ranging process and then to a fine degree through a receiver burst timing recovery process. In bothcases, the degree of timing accuracy required in the receiver is tighter for higher symbol rates and higher-orderconstellations.

Because S-CDMA requires a fine degree of timing accuracy to be accomplished solely by the ranging process, itis more sensitive to changes in the propagation delay of the cable plant between ranging intervals, which can beas much as 30 seconds apart. Table VIII-1 lists plant delay variations that can be accommodated in S-CDMA andTDMA modes for a 1 dB degradation under example conditions.

Defined conditions:

• 1 dB degradation at 1e-8 BER

• Uniform ranging offset over ± 1/64 chip

• 63 CMs, each with 2 codes

• Es/No numbers are ideal theoretical values, not including implementation effects

Table VIII-1 Allowable plant timing drift

Constellation Es/No for 1e-8 BER(dB)

Allowable peak-peak plantdelay variation (ns)S-CDMA

mode

Allowable peak-peak plantdelay variation (ns)TDMA

mode

Fully-coded QPSK 5 90 800

TCM QPSK 9 79 N/A

TCM 8QAM 12 57 N/A

Uncoded QPSK 15 38 800

Fully-coded 64QAM 17.7 24 800

TCM 32QAM 19 18 N/A

Uncoded 16QAM 22 9 800


TCM 128QAM 25 6 N/A


475


• 5.12 MHz modulation rate

• Timing variation over 30-second period

• TDMA receiver accepts ± 2 symbol coarse timing offset (implementation-dependent)

This channel impairment should be considered along with all of the other upstream channel characteristicshighlighted in Table 4-2.

DOCSIS requires station maintenance at least every 30 seconds (T4 timeout has a maximum value of 35seconds). For S-CDMA at a given modulation and symbol rate, if there exists a rapid propagation delay variationsuch that the resulting delay change cannot be tracked by station maintenance, then one or more of the followingperformance trade-offs and/or system changes may be enacted: (1) decrease the station maintenance period, (2)decrease the constellation order, (3) decrease the modulation rate, (4) apply additional error correction, (4) applysome combination of 1 through 4, or (5) change the channel to operate in Advanced TDMA mode.

The following sections discuss the relationship of temperature changes and wind loading on the propagationdelay in coaxial and HFC cable plants.

VIII.2 Change in Propagation Delay Due to Temperature Changes

VIII.2.1 Fiber Delay Changes Due to Temperature

In HFC plant design, the number of amplifiers in cascade in the coax portion is kept low in order to keep signaldegradation to an acceptable level. As a result, long runs of cable plant are mainly comprised of fiber. A typicalvalue for propagation delay variation due to temperature change of the fiber is 44 picoseconds per km per degreeC [1]. The delay variation comes mostly from the change in refractive index of the glass with temperature, notthe change in fiber length.

It is assumed that changes in optical cable length due to stretching or expansion will be a negligible factorbecause optical cables are built to isolate the fiber from stresses in the cable itself. The fiber usually sits looselyin a tube inside the cable and quite a bit of relative movement is possible. This construction allows normal cablehandling and aerial deployment without resulting in high stress on the optical fiber.

Assuming 44 picoseconds per km per degree C, any product of optical cable length and temperature changewhich equals 50 results in approximately a 2 nanosecond change in the fiber propagation delay. For example, 25km fiber and a 2 degree temperature change will result in a 2 ns change in propagation delay. For the maximumdistance between CMTS and CM specified in DOCSIS of 100 miles or roughly 160 km, the temperature changeneeded for a 2 ns second change in one-way propagation delay is 0.3 degree C.

Obviously, the issue is how fast the cable core (where the fiber is) will heat up under ambient temperaturechanges. For buried or underground cable, there is no issue. For aerial cable solar loading changes should beconsidered. Black sheathed cable has interior temperatures quite a bit higher than ambient in sunlight, but datais currently unavailable. When the rising sun hits aerial cable on a cold morning, one would expect a temperaturechange. Similarly, sunlight appearing out of cloud cover may have a similar impact although the size of theshadow of the cloud moving out of the way has to be considered. The numerical examples above suggest thatonly long aerial cable runs may have a problem under some combinations of time-of-day and weather.

476


VIII.2.2 Coaxial Cable Delay Changes Due to Temperature

The coaxial cable has a blown foam between the center conductor and the solid shield, and nominal propagationvelocity is about 87% of free space velocity [2]. Propagation velocity does not vary markedly with temperature.Given the relatively short lengths of coaxial cable in most HFC plant (a few miles) this seems unlikely to be asignificant source of delay variation.

VIII.2.3 Delay Change Due to Wind

Aerial cable stretches with wind loading, so it is possible to estimate a propagation delay from the change inlength under various wind loads. As mentioned, the construction of optical cable makes it tolerant of stretching,so it is assumed that optical cable stretching due to wind loading can be ignored. Wind loading will affect aerialcoaxial cables.

Wind loading is a difficult to deal with analytically because it is unlikely to be uniform along the cable. A delaymodel derived from a significant body of measured data is needed to investigate this further. Wind loading maybe a source of fast delay variation and station maintenance may not occur at intervals small enough for theranging mechanism to track this variation accurately.

The effects of wind loading on typical cable was investigated with a publicly available program from a coaxialcable manufacturer [3]. These calculations showed that length changes in the range 0.01% and 0.05% arepossible for various amounts of wind loading. This converts to significant propagation delay variation. As anexample, with 5 miles (8 km) and 0.02% length variation, the change in propagation delay is:

(8/3e5)*(1/0.87)*2e-4 seconds = 6 nanoseconds

This is a peak value, but the length of coax is quite short and the wind load is moderate. While the time durationover which this delay variation occurs is unspecified, it may be noted that wind gust data is readily available formost cities, and wind gust will be the primary mechanism for wind-based timing changes on cable plants. Forexample, in New York City at the time of this writing, wind gusts of up to 40 mph are reported while averagewind speed is about 10 mph. Hence, over a period of 1 to 4 seconds (the typical wind gust measurement interval),the wind speed changed by 30 mph. Much stronger wind gusts are frequently measured in locations prone towindy conditions.

VIII.3 References

[1] P.R. Trischitta and E.L. Varma, "Jitter in Digital Transmission Systems," Artech House, Norwood, MA, 1989.

[2] CommScope catalog for Parameter III cable. (QR cable is listed as 88%.)

[3] SpanMaster, available at www.commscope.com/html/community_access_cable.shtml

477



478


Appendix IX Acknowledgments

On behalf of CableLabs I would like to thank the following key contributors to DOCSIS 2.0 for their outstandingand superb contributions to this valuable program…

Victor Hou of Juniper Networks (formely Pacific Broadband) and Yoav Hebron of Conexant led the PhysicalLayer working groups that rewrote RFI Section 6, and wrote RFI Appendix VII. Ariel Yagil of TexasInstruments, Mike Grimwood of Imedia, Bruce Currivan and Tom Kolze of Broadcom, Hikmet Sari and DavidMunro of Juniper Networks, David Hull and Shimon Tzukerman of Conexant, Elias Nemer and HassanYaghoobi of Intel, and Jack Moran of Motorola participated in those groups.

Dan Crocker of Cisco Systems wrote Annex H with contributions from Niki Pantelias of Broadcom, Guy Cohenand Ariel Yagil of Texas Instruments, Rob Fanfelle and Hunter Donahue of Imedia, and John T. Chapman ofCisco Systems.

Rich Prodan of Terayon led the OSS working group that developed the new MIB for DOCSIS 2.0 as well asreworking the OSSI specification. Aviv Goren of Terayon, David Raftus of Imedia, Greg Nakanishi of Motorola,Adi Shaliv of Intel, Rich Woundy of Cisco, and Jason Schnitzer of Stargus contributed to that group.

Rusty Cashman of Correlant led the MAC layer working group that reworked much of RFI Sections 8, 9, and 11.Jeff Hoffman of Intel; Lisa Denney of Broadcom; Alon Bernstein of Cisco; Gordon Li of Conexant; AsafMatatyaou of Terayon; Robert Fanfelle of Imedia; David Doan, Christiaan Prins, Leo Zimmerman and SimonBrand of Philips contributed to that working group.

Clive Holborow of Motorola led the System Capabilities working group which rewrote RFI Section 3 and AnnexG, and contributed to RFI Sections 6, 9, and 11. Daniel Howard of Broadcom, Noam Geri of TI, and Doug Jonesof YAS contributed to that group.

Clive Holborow of Motorola, Victor Hou of Juniper Networks, Mike Grimwood of Imedia, Bruce Currivan andDaniel Howard of Broadcom, Rich Prodan of Terayon, and Hal Roberts of ADC wrote the informational materialin RFI Appendix VIII.

David Hull of Conexant, Luc Martens and Wim De Ketelaere of tComLabs, the engineers at UPC, and the Euro-DOCSIS Certification Board for their contributions to RFI Annex F.

The engineers at Terayon, Imedia, Broadcom, Texas Instruments, and Conexant, as well as the members of theIEEE 802.14a Hi-PHY working group (chaired by Roger Durant of Cabletron (now Riverstone)) developed thetechnology proposals that became DOCSIS 2.0.

George Hart of Rogers Cable, Oleh Sniezko of AT&T Broadband, Dan Rice of Stargus for their guidance andcontributions on behalf of CableLabs member companies.

I would also like to recognize Greg White, Mukta Kar, John Eng, Doug Jones, Eduardo Cardona, DorothyRaymond, Alex Ball, and Cynthia Metsker from CableLabs for their leadership and first class work.

CableLabs and the cable industry as a whole are grateful to these individuals and organizations for theiroutstanding, first class contributions.

Rouzbeh YassiniCEO of YAS ventures, LLC

Exec Consultant to CableLabs

479



480


Appendix X Revisions

X.1 ECNs included in SP-RFIv2.0-I02-020617

Table X-1 Incorporated ECN Table

ECN Date Accepted Summary

rfi2-n-02001 02/20/02 Provide consistent description for raised cosine filters.

rfi2-n-02002 02/13/02 Replace sections 8 and 11.

rfi2-n-02004 02/13/02 Eliminate burst profile type mixing.

rfi2-n-02015 02/20/02 Remove 2.0 mode TLV from CMTS MIC.

rfi2-n-02020 02/27/02 Minor S-CDMA change.

rfi2-n-02025 04/17/02 Corrections to MER requirements.

rfi2-n-02026 03/06/02 Add test mode requirements.

rfi2-n-02027 04/03/02 Clarify amplitude flatness requirements.

rfi2-n-02028 03/06/02 Clarify preamble support in 1.x bursts.

rfi2-n-02029 03/06/02 Specify exactly placement of return-to-zero bits.

rfi2-n-02031 04/03/02 Disable protocols on CPE port.

rfi2-n-02034 03/13/02 Delete carrier phase randomization of contention bursts.

rfi2-n-02035 03/13/02 Define bit ordering in figures.

rfi2-n-02038 03/20/02 Delete initialization techniques.

rfi2-n-02039 03/20/02 Correct initial ranging channel selection.

rfi2-n-02044 03/27/02 Bring consistency to authorization/authentication failure responses.

rfi2-n-02047 04/03/02 REG-ACK clarifications, chapter 11 clarification.

rfi2-n-02049 04/03/02 Clarify spreader on/off in station maintenance.

rfi2-n-02050 04/17/02 Clarify the RS interleaver parameters.

rfi2-n-02052 05/01/02 Clarify transmit pre-EQ coeff. normalization.

rfi2-n-02055 04/10//02 Clarification of BPI/BPI+ provisioning.

rfi2-n-02056 04/03/02 Update CM REG-REQ config file settings.

rfi2-n-02057 05/22/02 Clarify symbol rate inconsistencies.

rfi2-n-02065 04/24/02 Clarify CM response to an incorrect DCC-REQ.

rfi2-n-02066 05/08/02 Clarify 2.0 mode registration details.

rfi2-n-02070 05/01/02 Clarifiy switch between 1.x and 2.0 IUCs.

rfi2-n-02095 05/29/02 Corrections and clarifications.

rfi2-n-02096 05/22/02 Add Test Mode config file TLV.

rfi2-n-02100 05/22/02 Replace Annex H.

rfi2-n-02103 05/29/02 Correct mini-slot minimum capacity.

481


X.2 ECNs included in SP-RFIv2.0-I03-021218

Table X-2 Incorporated ECN Table

ECN Date Accepted Summary

rfi2-n-02085 06/12/02 Resolve contradicting definitions of guard time.

rfi2-n-02089 07/24/02 Explicitly state the burst descriptors that must be present in a valid UCD.

rfi2-n-02090 06/12/02 Clarify what should happen if Maximum Traffic Burst is less than MaximumConcatenated Burst.

rfi2-n-02093 07/31/02 Clarify use of Piggy Back requests during fragmentation and concatenation.

rfi2-n-02102 08/07/02 Create CM test mode for testing phase noise and jitter of CM carrier and symboltiming.

rfi2-n-02104 07/03/02 Clarify description of user-unique burst parameters.

rfi2-n-02105 06/05/02 Rectify inconsistency in CDMA transmit power example in section 6.2.18.2.

rfi2-n-02111 06/12/02 Clarify mechanism of RS zero filling in presence of TCM return-to-zero bits.

rfi2-n-02123 07/10/02 Clarify code hopper synchronization after a UCD change.

rfi2-n-02130 07/10/02 Correct typographical error in ECN# RFI2-N-02070.

rfi2-n-02135 08/14/02 Address and clarify zero filling mechanism in CM transmitter when R-S FEC isdisabled.

rfi2-n-02137 08/14/02 Replace Annex F, Euro-DOCSIS; editorial changes and one new requirement.

rfi2-n-02161 08/21/02 Clarify packet forwarding requirement.

rfi2-n-02145 8/14/02 Correct editorial error in Figure 11-48. NOTE: This ECN superceded by rfi2-n-02171.

rfi2-n-02171 08/14/02 Clarify CM forwarding rules, particularly for frames that arrive from a higher-layerembedded application.

rfi2-n-02173 09/18/02 Delete requirement to set Guard Time for SCDMA channels.

rfi2-n-02178 10/09/02 Specify CM timing offsets when making modulation rate chgnes.

rfi2-n-02187 11/06/02 Clarify reaction of DSx Dynamic state machines.

rfi2-n-02200 11/20/02 Apply classifier parameter requirement clarifications.

rfi2-n-02210 11/20/02 Make corrections and clarifications.

rfi2-n-02215 11/27/02 Correct two figures that contradict the text by requiring backoff on first transmission.

rfi2-n-02216 11/27/02 Allow for the absence of some non-critical options in a DHCP renew or rebind.

rfi2-n-02217 11/27/02 Clarify/change functionality related to the use of Interval Description Messages.

rfi2-n-02218 11/27/02 Specify the maximum latency of Interval Description Message delivery.

482