HDBaseT Specification · HDBaseT Specification Version 1.45D 1 Confidential HDBaseT™ Specification Draft Version 1.45D November 12, 2010

HDBaseT Specification Version 1.45D

1

Confidential

HDBaseT™

Specification

Draft Version 1.45D

November 12, 2010

HDBaseT Specification Draft Version 1.45D

2

Confidential

Table of Contents 1 Introduction .............................................................................................................. 17

1.1 HDBaseT Specification Organization .............................................................................................17 1.2 HDBaseT Objectives.....................................................................................................................18

1.2.1 HDBaseT Network Objectives ...................................................................................................................... 18 1.2.2 HDBaseT Link Objectives ............................................................................................................................. 18

1.3 Terminology, Definitions and Conventions .....................................................................................19 1.3.1 Terminology & Definitions ............................................................................................................................. 19

1.3.1.1 T-Adaptor ............................................................................................................................ 19 1.3.1.2 T-Network & T-Services ...................................................................................................... 20 1.3.1.3 Session ................................................................................................................................ 20 1.3.1.4 T-Stream .............................................................................................................................. 20 1.3.1.5 Multi T-Stream T-Adaptor .................................................................................................... 21 1.3.1.6 T-Group ............................................................................................................................... 21 1.3.1.7 HDBaseT Transmitter Function ............................................................................................ 22 1.3.1.8 HDBaseT Receiver Function ................................................................................................ 22 1.3.1.9 HDBaseT Port Device .......................................................................................................... 22 1.3.1.10 HDBaseT Switching Elements and Switch Device Definitions ............................................... 22 1.3.1.11 HDBaseT Daisy Chain Device Definition ............................................................................. 24 1.3.1.12 HDBaseT End Node Device Definition ................................................................................. 24 1.3.1.13 HDBaseT Control Point Function ......................................................................................... 25 1.3.1.14 HDBaseT Devices Map ........................................................................................................ 25 1.3.1.15 Edge/Intra Link/Port/Switch ................................................................................................. 26 1.3.1.16 Sub Network ........................................................................................................................ 27

1.3.2 Acronyms ....................................................................................................................................................... 28 1.3.3 Glossary ......................................................................................................................................................... 29 1.3.4 Conformance Levels ..................................................................................................................................... 31

1.4 References ...................................................................................................................................31 1.5 HDBaseT Overview ......................................................................................................................32

2 Link Layer ................................................................................................................. 36

2.1 General ........................................................................................................................................36 2.1.1 T-Network Services ....................................................................................................................................... 36

2.1.1.1 Transfer-Quality and Scheduling-Priority .............................................................................. 37 2.1.1.2 Clock Measurement Service ................................................................................................. 38 2.1.1.3 Propagation of Bad CRC Notification Service ....................................................................... 38 2.1.1.4 Nibble Stream Service .......................................................................................................... 39

2.1.2 Variable Bit Rate / Error Resistance Level Link Tokens .............................................................................. 39

2.2 Downstream Link ..........................................................................................................................40 2.2.1 Local Retransmission .................................................................................................................................... 40

2.2.1.1 Increasing the Retransmitted Packet Error Resistance ............................................................ 42 2.2.1.2 Triggering a Retransmission Request .................................................................................... 43

2.2.2 Dynamic Payload Error Resistance Level .................................................................................................... 43 2.2.3 Downstream Packet Format ......................................................................................................................... 46

2.2.3.1 Non Retransmission-Protected Packet Format ....................................................................... 46 2.2.3.2 Retransmission-Protected Packet Format ............................................................................... 47 2.2.3.3 Downstream Packet Type Token ........................................................................................... 48 2.2.3.4 Defined Packet Types ........................................................................................................... 48 2.2.3.5 Support for Future Packet Types ........................................................................................... 50


3

Confidential

2.2.3.6 Session ID Token ................................................................................................................. 51 2.2.3.7 Retransmission Header Token .............................................................................................. 51 2.2.3.8 Payload Length Token .......................................................................................................... 51 2.2.3.9 Downstream Packet CRC-8 Token ........................................................................................ 52 2.2.3.10 Downstream Packet CRC-32 Token ...................................................................................... 53 2.2.3.11 Extended Info Tokens........................................................................................................... 53

2.2.4 Downstream Control Packets ....................................................................................................................... 56 2.2.4.1 HDBaseT Status and Control Packet ..................................................................................... 56 2.2.4.2 Bulk Acknowledge General Status packet ............................................................................. 58 2.2.4.3 Frame Abort RX General Status packet ................................................................................. 58 2.2.4.4 Frame Abort TX General Status packet ................................................................................. 59 2.2.4.5 Bulk Head ............................................................................................................................ 59 2.2.4.6 HDBaseT Status Packet Example.......................................................................................... 59

2.2.5 Downstream Link Scheduler ......................................................................................................................... 62

2.3 Upstream Link Version 1 ...............................................................................................................62 2.3.1 Upstream Packet Format .............................................................................................................................. 62 2.3.2 Upstream Packet Type.................................................................................................................................. 63 2.3.3 Upstream Ethernet Data ............................................................................................................................... 64

2.3.3.1 Full Ethernet Payload ........................................................................................................... 64 2.3.3.2 Partial Ethernet Payload ....................................................................................................... 65

2.3.4 Upstream Control Data ................................................................................................................................. 65 2.3.4.1 A/V Controls........................................................................................................................ 66 2.3.4.2 HDBaseT Status ................................................................................................................... 68 2.3.4.1 Bulk Acknowledge General Status packet ............................................................................. 70 2.3.4.2 Frame Abort RX General Status packet ................................................................................. 70 2.3.4.3 Frame Abort TX General Status packet ................................................................................. 70 2.3.4.4 Bulk Head ............................................................................................................................ 71 2.3.4.5 HDBaseT Status Packet Example.......................................................................................... 71

2.3.5 Upstream CRC-8 Token................................................................................................................................ 73

2.4 Upstream Link Ver 2 .....................................................................................................................75 2.4.1 Upstream Ver 2 Packet Format .................................................................................................................... 75

2.4.1.1 Upstream Ver 2 Packet Type ................................................................................................ 75 2.4.2 Upstream Ethernet Data ............................................................................................................................... 76 2.4.3 Upstream Data Sub-packets ......................................................................................................................... 78 2.4.4 Upstream CRC-8 Token................................................................................................................................ 82 2.4.5 Upstream IDLE Token................................................................................................................................... 83

2.5 HDSBI Link Layer .........................................................................................................................83 2.5.1 HDBaseT Stand by Interface (HDSBI) Overview ......................................................................................... 83 2.5.2 Start-Up ......................................................................................................................................................... 83

2.5.2.1 Start-Up Sequence ................................................................................................................ 84 2.5.2.2 Partner Detection Initiative ................................................................................................... 85 2.5.2.3 Swap Resolving ................................................................................................................... 85 2.5.2.4 Collisions ............................................................................................................................. 85 2.5.2.5 Link-Down Events ............................................................................................................... 85 2.5.2.6 Break Link Time-Out ........................................................................................................... 86 2.5.2.7 Gender Mismatch ................................................................................................................. 86

2.5.3 Packet Delimiter ............................................................................................................................................ 86 2.5.4 Short Packets ................................................................................................................................................ 87

2.5.4.1 Short Packets Format............................................................................................................ 87 2.5.4.2 Short Packet Types ............................................................................................................... 87 2.5.4.3 DDC over HDSBI Link ........................................................................................................ 88 2.5.4.4 CEC and HPD / 5V over HDSBI Link .................................................................................. 89 2.5.4.5 HDSBI Set Stream ID .......................................................................................................... 89


4

Confidential

2.5.4.6 HDSBI Mode Change........................................................................................................... 90 2.5.4.7 HDSBI Active/Silent Change ............................................................................................... 91 2.5.4.8 HDSBI Bulk Acknowledge ................................................................................................... 92 2.5.4.9 HDSBI Frame Abort ............................................................................................................ 92 2.5.4.10 HDSBI Info Packet .............................................................................................................. 93

2.5.5 Long Packets ................................................................................................................................................. 94 2.5.5.1 Long Packets Format ............................................................................................................ 94 2.5.5.2 Long Packet Payload Formats ............................................................................................... 95 2.5.5.3 Long Packet Example ........................................................................................................... 96

2.6 HDMI-HDCP Link Layer ................................................................................................................99 2.7 Ethernet/Switch MAC ....................................................................................................................99

3 Physical Layer ........................................................................................................ 100

3.1 General ...................................................................................................................................... 100 3.1.1 Physical Media Impairments ....................................................................................................................... 100 3.1.2 Master / Slave Clocking Scheme ................................................................................................................ 101 3.1.3 Channels / Polarity Swaps Considerations ................................................................................................ 101

3.2 Downstream Phy ........................................................................................................................ 102 3.2.1 Variable Bit Rate / Protection Level s4dPxx Symbols ............................................................................... 102 3.2.2 Downstream Physical Coding Sub Layer (PCS) ........................................................................................ 105

3.2.2.1 Downstream Scrambler / De-Scrambler .............................................................................. 106 3.2.2.2 Downstream Training ......................................................................................................... 107 3.2.2.3 Downstream Idles .............................................................................................................. 108 3.2.2.4 Downstream Link Tokens to Symbols Modulation .............................................................. 109

3.2.3 Downstream Physical interface tests.......................................................................................................... 111 3.2.3.1 Downstream Isolation requirement...................................................................................... 111 3.2.3.2 Downstream Test modes..................................................................................................... 111 3.2.3.3 Downstream Test Fixtures .................................................................................................. 115

3.2.4 Downstream Transmitter electrical specifications ...................................................................................... 116 3.2.4.1 Downstream Transmitter Peak differential output voltage and level accuracy ....................... 117 3.2.4.2 Downstream Transmitter Maximum output droop ............................................................... 117 3.2.4.3 Downstream Transmitter timing jitter.................................................................................. 117 3.2.4.4 Downstream Transmitter distortion ..................................................................................... 117 3.2.4.5 Downstream Transmitter Power Spectral Density ................................................................ 117 3.2.4.6 Downstream Transmit clock frequency ............................................................................... 118

3.2.5 Downstream Receiver electrical specifications .......................................................................................... 118 3.2.5.1 Downstream Receiver Symbol Error Rate ........................................................................... 118 3.2.5.2 Downstream Receiver frequency tolerance .......................................................................... 119 3.2.5.3 Downstream Common-mode noise rejection ....................................................................... 119

3.3 Upstream Phy............................................................................................................................. 119 3.3.1 Upstream Physical Coding Sub Layer (PCS)............................................................................................. 119

3.3.1.1 Token Control .................................................................................................................... 120 3.3.1.2 Upstream Scrambler / De-Scrambler ................................................................................... 121 3.3.1.3 DC Balance ........................................................................................................................ 123 3.3.1.4 Upstream Link Tokens to Symbols Modulation ................................................................... 123 3.3.1.5 Swap Control ..................................................................................................................... 126 3.3.1.6 Data Alignment .................................................................................................................. 126 3.3.1.7 Packet Track ...................................................................................................................... 126

3.3.2 Upstream Physical Interface tests .............................................................................................................. 127 3.3.2.1 Upstream Isolation requirement .......................................................................................... 127 3.3.2.2 Upstream Test modes ......................................................................................................... 128 3.3.2.3 Upstream Test Fixtures ....................................................................................................... 129

3.3.3 Upstream Transmitter electrical specifications........................................................................................... 131 3.3.3.1 Upstream Transmitter Peak differential output voltage and level accuracy ............................ 131


5

Confidential

3.3.3.2 Upstream Transmitter Maximum output droop .................................................................... 131 3.3.3.3 Upstream Transmitter timing jitter ...................................................................................... 132 3.3.3.4 Upstream Transmitter distortion.......................................................................................... 132 3.3.3.5 Upstream Transmitter Power Spectral Density..................................................................... 132 3.3.3.6 Upstream Transmit clock frequency .................................................................................... 132

3.3.4 Upstream Receiver electrical specifications ............................................................................................... 132 3.3.4.1 Upstream Receiver differential input signals ....................................................................... 132 3.3.4.2 Upstream Receiver frequency tolerance .............................................................................. 132 3.3.4.3 Upstream Common-mode noise rejection ............................................................................ 132

3.4 Active Mode Startup ................................................................................................................... 133 3.4.1 Downstream Link Startup Transmission Types ......................................................................................... 133

3.4.1.1 Downstream Silent Mode ................................................................................................... 133 3.4.1.2 Downstream Training Mode ............................................................................................... 133 3.4.1.3 Downstream Idle Mode ...................................................................................................... 134 3.4.1.4 Downstream Data Period .................................................................................................... 134

3.4.2 Upstream Link Startup Transmission Types .............................................................................................. 134 3.4.2.1 Upstream Silent Mode ........................................................................................................ 134 3.4.2.2 Upstream Training Mode .................................................................................................... 134 3.4.2.3 Upstream Idle Mode ........................................................................................................... 134 3.4.2.4 Upstream Data Mode.......................................................................................................... 134

3.4.3 SINK (Downstream RX, Upstream TX) Startup State Machine................................................................. 136 3.4.3.1 Indications ......................................................................................................................... 136 3.4.3.2 States ................................................................................................................................. 137

3.4.4 SOURCE (Upstream RX, Downstream TX) Startup State Machine ......................................................... 139 3.4.4.1 Indications ......................................................................................................................... 139 3.4.4.2 States ................................................................................................................................. 140

3.5 HDBaseT Stand By mode Interface (HDSBI) Phy ........................................................................ 142 3.5.1 HDSBI General ............................................................................................................................................ 142 3.5.2 HDSBI Design for Low Power ..................................................................................................................... 143 3.5.3 HDSBI Physical Coding Sub-Layer (PCS) ................................................................................................. 143

3.5.3.1 HDSBI Symbol Generator .................................................................................................. 144 3.5.3.2 HDSMI Scrambler LFSR.................................................................................................... 145

3.5.4 HDSBI Transmitter electrical specifications ............................................................................................... 145 3.5.4.1 HDSBI Transmitter Output Waveform Mask....................................................................... 145 3.5.4.2 HDSBI Transmit Clock Frequency ..................................................................................... 146 3.5.4.3 HDSBI Common-mode output voltage ................................................................................ 146

3.5.5 HDSBI Receiver electrical specifications ................................................................................................... 146 3.5.5.1 HDSBI Receiver Symbol Error Rate ................................................................................... 146 3.5.5.2 HDSBI Receiver frequency tolerance .................................................................................. 146 3.5.5.3 HDSBI Common-mode noise rejection ............................................................................... 147

4 HDBaseT Link Control and Management ............................................................. 148

4.1 General ...................................................................................................................................... 148 4.2 HDBaseT Configuration Database (HDCD).................................................................................. 148

4.2.1 ELV Structure .............................................................................................................................................. 152 4.2.1.1 Error ELV .......................................................................................................................... 153

4.3 HDBaseT Link Internal Controls (HLIC) ....................................................................................... 154 4.3.1 HLIC General............................................................................................................................................... 155 4.3.2 HLIC Packet Format .................................................................................................................................... 155 4.3.3 HLIC Op Codes ........................................................................................................................................... 156 4.3.4 HLIC Get Transaction ................................................................................................................................. 157

4.3.4.1 HLIC Get - Request Packet ................................................................................................. 157 4.3.4.2 HLIC Get - Reply Packet .................................................................................................... 158


6

Confidential

4.3.5 HLIC Set Transaction .................................................................................................................................. 159 4.3.5.1 HLIC Set - Request Packet ................................................................................................. 159 4.3.5.2 HLIC Set - Reply Packet .................................................................................................... 160

4.3.6 HLIC Change Mode Transaction ................................................................................................................ 161 4.3.7 HLIC Non Ack/Abort Packets ...................................................................................................................... 161

4.3.7.1 HLIC Non Ack / Abort - Request Packet ............................................................................. 162 4.3.7.2 HLIC Non Ack / Abort - Reply Packet ................................................................................ 162

5 Network Layer ........................................................................................................ 164

5.1 General ...................................................................................................................................... 164 5.1.1 T-Network .................................................................................................................................................... 164 5.1.2 E-Network .................................................................................................................................................... 164 5.1.3 HDBaseT Network Objectives .................................................................................................................... 164

5.1.3.1 Network Topology ............................................................................................................. 165 5.1.3.2 Latency Targets.................................................................................................................. 165 5.1.3.3 Control and Management.................................................................................................... 166

5.1.4 Entity Referencing Method.......................................................................................................................... 166 5.1.4.1 T-Adaptors Type Mask Field .............................................................................................. 167 5.1.4.2 Port and T-Group ID (TPG) Field ....................................................................................... 168 5.1.4.3 Device ID .......................................................................................................................... 169 5.1.4.4 Referencing Examples ........................................................................................................ 170

5.1.5 Routing Schemes ........................................................................................................................................ 170 5.1.5.1 Distributed Routing Scheme (DRS) .................................................................................... 170 5.1.5.2 Centralized Routing Scheme (CRS) .................................................................................... 171

5.2 HDBaseT Control & Management Protocol (HD-CMP) ................................................................. 171 5.2.1 HD-CMP Message Format.......................................................................................................................... 172 5.2.2 HD-CMP Message Encapsulation within Ethernet Packet ........................................................................ 173 5.2.3 HD-CMP Message Encapsulation within HLIC Packet .............................................................................. 174

5.2.3.1 Full Form ........................................................................................................................... 174 5.2.3.2 Short Form ......................................................................................................................... 175

5.2.4 Common Payload Sections......................................................................................................................... 176 5.2.4.1 Path Description Section (PDS) .......................................................................................... 176 5.2.4.2 Network Path Availability Section (NPA) ........................................................................... 178 5.2.4.3 Packet Stream Unit (PSU) .................................................................................................. 179 5.2.4.4 Device Info Section (DIS) .................................................................................................. 181

5.2.5 Sub Network Propagation Message (SNPM) ............................................................................................. 185 5.2.5.1 NPA Update....................................................................................................................... 186

5.2.6 Broadcast SNPM ......................................................................................................................................... 188 5.2.6.1 Broadcast SNPM Propagation Rules ................................................................................... 189 5.2.6.2 Broadcast SNPM Types ...................................................................................................... 189 5.2.6.3 Periodic SNPM .................................................................................................................. 189 5.2.6.4 Informative - Periodic SNPM Generation and Propagation Examples ................................... 192 5.2.6.5 Informative – PDS Usage in SNPM Example ...................................................................... 198 5.2.6.6 Update SNPM .................................................................................................................... 199

5.2.7 Unicast SNPM ............................................................................................................................................. 200 5.2.7.1 Unicast SNPM Propagation Rules ....................................................................................... 202 5.2.7.2 Informative – „With Path‟ U_DSPM Propagation Example .................................................. 204 5.2.7.3 Informative – Backwards „By PDS‟ U_USPM Propagation Example ................................... 208

5.3 Devices & T-Network Topology Discovery ................................................................................... 211 5.3.1 General ........................................................................................................................................................ 211 5.3.2 PDME Functions ......................................................................................................................................... 211 5.3.3 SDME Functions ......................................................................................................................................... 212 5.3.4 Control Point Functions ............................................................................................................................... 213


7

Confidential

5.3.5 Routing Processor Functions ...................................................................................................................... 215 5.3.6 Summary of Discovery Methods per Management Entity ......................................................................... 216 5.3.7 Device Status Messages ............................................................................................................................ 216

5.3.7.1 Device Status Request Message .......................................................................................... 217 5.3.7.2 Device Status Notify Message ............................................................................................ 217 5.3.7.3 Active Device Time Out ..................................................................................................... 217

5.3.8 SDMEs Directional Connectivity (SDC) Messages .................................................................................... 218 5.3.8.1 SDME Directional Connectivity Request Message .............................................................. 218 5.3.8.2 SDME Directional Connectivity Notify Message................................................................. 218

5.3.9 SDME Link Status (SLS) Messages ........................................................................................................... 218 5.3.9.1 SDME Link Status Request Message .................................................................................. 218 5.3.9.2 SDME Link Status Notify Message..................................................................................... 219

5.3.10 CPME Registration (CPR) Message .......................................................................................................... 219 5.3.10.1 CPR Message Format ......................................................................................................... 219

5.4 T-Network Sessions .................................................................................................................... 219 5.4.1 General ........................................................................................................................................................ 219

5.4.1.1 Session Requirements from the sub network path ................................................................ 219 5.4.1.2 PSU Limits per sub network path ........................................................................................ 220

5.4.2 Session Routing Overview .......................................................................................................................... 221 5.4.3 Session Creation ......................................................................................................................................... 221

5.4.3.1 DRS Session Creation Examples......................................................................................... 223 5.4.3.2 CRS Session Creation Example .......................................................................................... 226 5.4.3.1 Initiating Entity Session Creation State Diagram ................................................................. 228 5.4.3.2 Session Partner Session Initiation........................................................................................ 230 5.4.3.3 First Partner Session Initiation State Diagram ...................................................................... 232 5.4.3.4 Second Partner Session Initiation State Diagram ................................................................. 233 5.4.3.5 Session Initiation Request ................................................................................................... 235 5.4.3.6 Session Initiation Response ................................................................................................ 237 5.4.3.7 Session Route Query (SRQ) ............................................................................................... 239 5.4.3.8 Session Route Select (SRSL) Request ................................................................................. 242 5.4.3.9 Session Route Select (SRSL) Response ............................................................................... 244 5.4.3.10 Session Route Set (SRST) .................................................................................................. 246 5.4.3.11 Session Creation Completed (SCC) ..................................................................................... 247 5.4.3.12 Session Status (SSTS) Request ........................................................................................... 247 5.4.3.13 Session Status (SSTS) Response ......................................................................................... 248

5.4.4 Session Maintenance .................................................................................................................................. 250 5.4.4.1 Session Maintenance U_SNPM (SMU) ............................................................................... 250

5.4.5 Session Termination ................................................................................................................................... 252 5.4.5.1 Session Termination U_SNPM (STU) ................................................................................. 252 5.4.5.2 Session Termination Request .............................................................................................. 254 5.4.5.3 Session Termination Response ............................................................................................ 254

5.4.6 Session Descriptors .................................................................................................................................... 254 5.4.6.1 Session Descriptor Format .................................................................................................. 254 5.4.6.2 Management Entity Session Database ................................................................................. 255

5.5 Centralized Routing Scheme (CRS) Using Link state Routing ...................................................... 255 5.5.1 Link Status Notify ........................................................................................................................................ 257 5.5.2 RPE for Session Routing ............................................................................................................................ 258 5.5.3 Path Computation for Session Routing ...................................................................................................... 259 5.5.4 Link State Update for Session Routing ...................................................................................................... 260 5.5.5 Session Control Packets for Session Routing............................................................................................ 260

5.5.5.1 Link Status Notify Packet ................................................................................................... 261 5.5.5.2 Link Status Request Packet ................................................................................................. 262 5.5.5.3 Session Status Table ........................................................................................................... 263 5.5.5.4 Session Routing Table ........................................................................................................ 264


8

Confidential

5.5.5.5 Session Routing Table Request ........................................................................................... 265 5.5.5.6 Session Routing Table Response......................................................................................... 265

5.5.6 Bandwidth Assessments and Reservation for Session Routing................................................................ 265 5.5.6.1 Bandwidth Verification for Session Routing ........................................................................ 265

5.5.7 Session Routing Examples ......................................................................................................................... 267 5.5.7.1 Link Status Notify examples ............................................................................................... 269 5.5.7.2 An example of Operation of RPE ........................................................................................ 270 5.5.7.3 An example of Routing Table for Session Routing .............................................................. 271

5.5.8 Dijkstra‟s Algorithm...................................................................................................................................... 272

6 Ethernet over HDBaseT ......................................................................................... 275

6.1 General ...................................................................................................................................... 275 6.1.1 MII/RMII I/F to HDBaseT ............................................................................................................................. 275 6.1.2 HDBaseT to MII/RMII I/F ............................................................................................................................. 277

6.2 Downstream Ethernet Packets .................................................................................................... 278 6.3 Uptream Ethernet Packets .......................................................................................................... 280

7 HDMI over HDBaseT .............................................................................................. 281

7.1.1 DDC over HDBaseT Link ............................................................................................................................ 281 7.1.1.1 I²C Slave I/F in the Source .................................................................................................. 282 7.1.1.2 I²C Master I/F in the Sink ................................................................................................... 283

7.1.2 CEC over HDBaseT Link ............................................................................................................................ 284 7.1.2.1 CEC traffic direction .......................................................................................................... 285 7.1.2.2 Compensating for extra pull up ........................................................................................... 287 7.1.2.3 Acknowledge Bit Sequence ................................................................................................ 289

7.1.3 HPD / 5V Indication Over HDBaseT Link ................................................................................................... 292 7.1.4 HDMI-AV over HDBaseT Link .................................................................................................................... 293

7.1.4.1 HDMI-AV Data over HDBaseT Link .................................................................................. 293 7.1.4.2 TMDS Active Pixels Data TokD16 (PAM16) Packets ......................................................... 295 7.1.4.3 TMDS Active Pixels Data TokD12 (PAM8) Packets ........................................................... 298 7.1.4.4 TMDS Data Island Packets ................................................................................................. 300 7.1.4.5 TMDS Control Data Packets ............................................................................................... 302 7.1.4.6 TMDS Clock over HDBaseT Link ...................................................................................... 305 7.1.4.7 TMDS Clock Info Control Packet ....................................................................................... 305 7.1.4.8 HDMI-AV Controls Packet ................................................................................................ 306

8 USB over HDBaseT ................................................................................................ 308

9 Power over HDBaseT (PoH) .................................................................................. 308

10 Other Interfaces Over HDBaseT ............................................................................ 308

10.1 General ...................................................................................................................................... 308 10.2 Requirements ............................................................................................................................. 308 10.3 IR over HDBaseT ....................................................................................................................... 308

10.3.1 General ........................................................................................................................................................ 308 10.3.2 HDBaseT IR Messages............................................................................................................................... 308 10.3.3 T-Adaptor Info Format ................................................................................................................................. 310 10.3.4 IR Downstream Packets.............................................................................................................................. 310 10.3.5 IR Upstream Sub-packets ........................................................................................................................... 310

10.4 UART over HDBaseT .................................................................................................................. 311 10.4.1 General ........................................................................................................................................................ 311 10.4.2 Error Handling ............................................................................................................................................. 311 10.4.3 T-Adaptor Info Format ................................................................................................................................. 312


9

Confidential

10.4.4 UART Downstream Packets ....................................................................................................................... 314 10.4.5 UART Upstream Sub-packets .................................................................................................................... 314

10.5 SPDIF over HDBaseT ................................................................................................................. 315 10.5.1 General ........................................................................................................................................................ 315 10.5.2 S/PDIF Nibble Stream ................................................................................................................................. 316 10.5.3 Error Handling ............................................................................................................................................. 316 10.5.4 T-Adaptor Info Format ................................................................................................................................. 317 10.5.5 SPDIF Downstream Packets ...................................................................................................................... 318 10.5.6 SPDIF Upstream Sub-packets .................................................................................................................... 319

Appendix A – Use Cases ............................................................................................. 320

Revision History .......................................................................................................... 320

Contact Information ..................................................................................................... 321

Table of Figures Figure 1: HDMI and USB T-Adaptor Examples ...........................................................................................19 Figure 2: T-Network ....................................................................................................................................20 Figure 3: T-Stream Example .......................................................................................................................21 Figure 4: Multi T-Stream Example ..............................................................................................................21 Figure 5: Switch Device Example ...............................................................................................................23 Figure 6: Daisy Chain Device Example ......................................................................................................24 Figure 7: End Node Device Example ..........................................................................................................25 Figure 8: HDBaseT Devices Map ................................................................................................................25 Figure 9: Edge/Intra Link/Port/Switch Example .........................................................................................26 Figure 10: Two HDBaseT Sub Networks Connected via the Ethernet Network Example ..........................27 Figure 11: Multiple Sub Networks Example ...............................................................................................27 Figure 12: Multiple Sub Networks – Connected via Ethernet & HDMI - Example ......................................28 Figure 13: HDBaseT Link – Logical Represenation ...................................................................................32 Figure 14: HDBaseT Link - Sub Links and Link Structure .........................................................................33 Figure 15: HDBaseT Single Stream Source Architecture ..........................................................................34 Figure 16: HDBaseT Single Stream Sink Architecture ...............................................................................35 Figure 17: Bad CRC Triggered Conceptual Local Retransmission............................................................41 Figure 18: PID Gap Detection Triggered Conceptual Local Retransmission.............................................42 Figure 19: Converting TokD16 to TokD12 and TokD8 - example ...............................................................45 Figure 20: Converting TokD12 to TokD16 and TokD8 - example ...............................................................45 Figure 21: Converting TokD8 to TokD12 and TokD16 - example ...............................................................46 Figure 22: HDBaseT Downstream Non Retransmisison-Protected Packet Format ...................................46 Figure 23: HDBaseT Downstream Retransmisison Protected Packet Format ...........................................47 Figure 24: HDBaseT Downstream Packet Type .........................................................................................48 Figure 25: Extended Type Token ................................................................................................................50 Figure 26: Retranssmision Header Token ..................................................................................................51 Figure 27: HDBaseT Packet Structure ........................................................................................................52 Figure 28: HDBaseT Token Values Example ..............................................................................................52 Figure 29: Zero Padding .............................................................................................................................52


10

Confidential

Figure 30: HDBaseT CRC-8 ........................................................................................................................52 Figure 31: HDBaseT CRC-8 Token Assignment .........................................................................................53 Figure 32: Packet Type Token followed by Extended Conrol Info Token Format .....................................53 Figure 33: Generic Extended Info Token Format .......................................................................................54 Figure 34: Bad CRC Indication Location ....................................................................................................55 Figure 35: Packet Header with Max Number Of Extended Info Tokens for currently defined packet types

.............................................................................................................................................................55 Figure 36: Packet Header with Max Number Of Extended Info Tokens for future packet types ...............55 Figure 37: HDBaseT Status Control Packet ...............................................................................................56 Figure 38: Upstream HDBaseT Packet .......................................................................................................63 Figure 39: Upstream - 64B/65B Blocks to Ethernet Token Assignment ...................................................65 Figure 40: Upstream - 64B/65B Blocks to Partial Ethernet Token Assignment ........................................65 Figure 41: Upstream - Control Token Assignment ....................................................................................66 Figure 42: Upstream - HDBaseT Status Token Assignment .....................................................................68 Figure 43: HDBaseT Upstream Packet Structure .......................................................................................74 Figure 44: Upstream CRC-8 ........................................................................................................................74 Figure 45: HDBaseT CRC-8 Token Assignment .........................................................................................74 Figure 46: Upstream Ver 2 HDBaseT Packet ..............................................................................................75 Figure 47: Upstream – Mapping of three 64B/65B Ethernet Blocks onto 17 Ethernet Tokens ..................77 Figure 48: Upstream – Mapping of two 64B/65B Ethernet Blocks onto 11 Ethernet Tokens ....................77 Figure 49: Upstream Data Sub-packet Format ...........................................................................................78 Figure 50: Upstream Data Sub-packet Header Token Format ...................................................................79 Figure 51: Upsteam Auxiliary Data Long Sub-packet Header consisting of an Extended Length Token

and a Sub-packet Header Token..........................................................................................................81 Figure 52: Upstream Auxiliary Data Filler Sub-packet (Token) ..................................................................81 Figure 53: Upstream Data Sub-packet Header Token, and Extended Type Token ....................................82 Figure 54: HDSBI Overview ........................................................................................................................83 Figure 55: HDSBI Short Packet Structure ..................................................................................................87 Figure 56: HDSBI DDC Packet Structure ....................................................................................................88 Figure 57: HDSBI DDC Packet Structure ....................................................................................................89 Figure 58: HDSBI Set Stream ID (Low) Packet Structure ...........................................................................90 Figure 59: HDSBI Set Stream ID (High) Packet Structure ..........................................................................90 Figure 60: HDSBI Mode Change Packet Structure .....................................................................................90 Figure 61: HDSBI Active/Silent Change Packet Structure .........................................................................91 Figure 62: HDSBI Bulk Acknowledge Packet Structure .............................................................................92 Figure 63: HDSBI Frame Abort Packet Structure .......................................................................................93 Figure 64: HDSBI Info Packet Structure .....................................................................................................94 Figure 65: HDSBI Long Packet Structure ...................................................................................................94 Figure 66: Bulk Head Payload ....................................................................................................................95 Figure 67: Bulk Data Payload .....................................................................................................................96 Figure 68: Media impairments of full duplex over four twisted pairs system .......................................... 100 Figure 69: Downstream s4dPxx symbols subsets ................................................................................... 103 Figure 70: Downstream - per channel, mapping bits to s4dP16 symbol ................................................ 104 Figure 71: Downstream - per channel, mapping bits to s4dP8 symbol ................................................... 104 Figure 72: Downstream - per channel, mapping bits to s4dP4 symbol ................................................... 105 Figure 73: Downstream - Source PCS ...................................................................................................... 105 Figure 74: Downstream - Scrambler / De-Scrambler LFSR ...................................................................... 106


11

Confidential

Figure 75: Downstream - per channel, mapping bits to s4dP2 and s4dP2A symbols ............................. 108 Figure 76: Downstream - per channel, mapping bits to s4dPI symbol .................................................... 109 Figure 77: Downstream - per channel, mapping bits to s4dP16 symbol ................................................. 110 Figure 78: Downstream - per channel, mapping bits to s4dP8 symbol ................................................... 110 Figure 79: Downstream, per channel, mapping bits to s4dP4 symbol .................................................... 111 Figure 80: Example of transmitter test mode 1 waveform ....................................................................... 112 Figure 81: Example of transmitter test mode 2 waveform ....................................................................... 113 Figure 82: Example of transmitter test mode 3 waveform ....................................................................... 114 Figure 83: Distortion scrambler generator polynomial level mapping .................................................... 115 Figure 84: Transmitter test fixture 1 ......................................................................................................... 115 Figure 85: Transmitter test fixture 2 ......................................................................................................... 115 Figure 86: Transmitter PSD Mask ............................................................................................................. 118 Figure 87: Upstream - Block Diagram ..................................................................................................... 120 Figure 88: Upstream - Training Packet .................................................................................................... 121 Figure 89: Upstream - Ideal Packet ......................................................................................................... 121 Figure 90: Upstream - Data Packet .......................................................................................................... 121 Figure 91: Upstream - Scrambler ............................................................................................................ 121 Figure 92: Upstream - 4bit to 12bit Scrambler Mode Transition ............................................................. 122 Figure 93: Upstream - Scrambler Modes State Machine ......................................................................... 122 Figure 94: Upstream - DC Balanace Algorithem ..................................................................................... 123 Figure 95: Upstream - 12-bits Token Lane Assignment .......................................................................... 124 Figure 96: Upstream - per channel, mapping bits to s4dP16B symbol.................................................... 124 Figure 97: Upstream - 8-bits Token Lane Assignment ............................................................................ 125 Figure 98: Upstream - per channel, mapping bits to s4dP8B symbol ..................................................... 125 Figure 99: Upstream - 4-bits Token Lane Assignment ............................................................................. 125 Figure 100: Upstream - per channel, mapping bits to s4dPIB symbol .................................................... 126 Figure 101: Upstream - per channel, mapping bits to s4dP4B symbol ................................................... 126 Figure 102: Upstream – Packet Example ................................................................................................. 127 Figure 103: Upstream – Packets in Startup Sequence ............................................................................. 127 Figure 104: Distortion scrambler generator polynomial level mapping .................................................. 129 Figure 105: Transmitter test fixture 1 ....................................................................................................... 130 Figure 106: Transmitter test fixture 2 ....................................................................................................... 130 Figure 107: Startup Sequence Diagram ................................................................................................... 133 Figure 108: Link Startup State Machines ................................................................................................. 135 Figure 109: HDSBI Operation Over C&D pairs ......................................................................................... 143 Figure 110: HDSBI Manchaster II encoding.............................................................................................. 143 Figure 111: HDSBI PCS ............................................................................................................................ 144 Figure 112: The two types of HDSBI Symbols ......................................................................................... 145 Figure 113: HDSBI Scrambler LFSR ......................................................................................................... 145 Figure 114: HDSBI Transmitter Mask ....................................................................................................... 146 Figure 115: ELV Structure ........................................................................................................................ 152 Figure 116: Error ELV Format................................................................................................................... 153 Figure 117: HLIC Packet Format............................................................................................................... 156 Figure 118: HLIC Get – Request Packet Format ....................................................................................... 157 Figure 119: HLIC Get – Reply Packet Format ........................................................................................... 158 Figure 120: HLIC Set – Request Packet Format ....................................................................................... 160 Figure 121: HLIC Set – Reply Packet Format ........................................................................................... 160


12

Confidential

Figure 122: HLIC Abort – Request Packet Format ................................................................................... 162 Figure 123: HLIC Abort – Reply Packet Format ....................................................................................... 162 Figure 124: Entity Referencing Method .................................................................................................... 167 Figure 125: TPG Field ............................................................................................................................... 168 Figure 126: Referencing Examples .......................................................................................................... 170 Figure 127: HD-CMP messages and encapsulation methods mapping ................................................... 172 Figure 128: HD-CMP message Format ..................................................................................................... 172 Figure 129: HD-CMP message encapsulation using Ethernet packet ..................................................... 173 Figure 130: HD-CMP message, full form, encapsulation within HLIC packet .......................................... 174 Figure 131: HD-CMP message, full form reply, over HLIC packet ........................................................... 175 Figure 132: HD-CMP message, short form, encapsulation within HLIC packet ....................................... 175 Figure 133: HD-CMP message, short form reply, over HLIC packet ........................................................ 176 Figure 134: PDS Format ........................................................................................................................... 177 Figure 135: NPA Format ........................................................................................................................... 178 Figure 136: DIS Format ............................................................................................................................. 181 Figure 137: Device Type Format............................................................................................................... 182 Figure 138: Device Status Format ............................................................................................................ 182 Figure 139: Port Type Format ................................................................................................................... 183 Figure 140: Port Status Format ................................................................................................................ 184 Figure 141: SNPM HD-CMP OpCode Format ............................................................................................ 186 Figure 142: Broadcast SNPM HD-CMP OpCode and Payload Formats ................................................... 188 Figure 143: Periodic SNPM HD-CMP OpCode and Payload Format ........................................................ 190 Figure 144: PDMEs Generating Periodic Edge SNPMs – Example .......................................................... 192 Figure 145: Edge SDMEs Generating Periodic Intra SNPMs – Example .................................................. 193 Figure 146: Propagating Periodic Intra SNPMs – Example - Step 1......................................................... 194 Figure 147: Propagating Periodic Intra SNPMs – Example - Step 2......................................................... 194 Figure 148: Propagating Periodic Intra SNPMs – Example - Step 3......................................................... 195 Figure 149: Propagating Periodic Intra SNPMs – Example - Step 4......................................................... 196 Figure 150: Edge SDMEs Generating Periodic Edge SNPMs – Example ................................................. 197 Figure 151: PDS Usage in Periodic DSPM – Example – Step 1 ................................................................ 198 Figure 152: PDS Usage in Periodic DSPM – Example – Step 2 ................................................................ 198 Figure 153: PDS Usage in Periodic DSPM – Example – Step 3 ................................................................ 199 Figure 154: U_SNPM HD-CMP OpCode and Payload Formats................................................................. 200 Figure 155: U_SNPM Session ID Query Format ....................................................................................... 201 Figure 156: ‘With Path’ U_DSPM Propagation – Example – Step 1 - Generation..................................... 204 Figure 157: ‘With Path’ U_DSPM Propagation – Example – Step 2 - First Propagation .......................... 204 Figure 158: ‘With Path’ U_DSPM Propagation – Example – Step 3 - Second Propagation ..................... 205 Figure 159: ‘With Path’ U_DSPM Propagation – Example – Step 4 - Third Propagation ......................... 206 Figure 160: ‘With Path’ U_DSPM Propagation – Example – Step 5 - Fourth Propagation ...................... 207 Figure 161: Backwards ‘By PDS’ U_USPM Propagation – Example – Step 1 - Generation ..................... 208 Figure 162: Backward ‘By PDS’ U_USPM Propagation – Example – Step 1 - Message Format .............. 208 Figure 163: Backward ‘By PDS’ U_USPM Propagation – Example – Step 2 – First Propagation ............ 209 Figure 164: Backward ‘By PDS’ U_USPM Propagation – Example – Step 2 - Message Format .............. 209 Figure 165: Backward ‘By PDS’ U_USPM Propagation – Example – Step 3 – Second Propagation ....... 210 Figure 166: Backward ‘By PDS’ U_USPM Propagation – Example – Step 4 – Third Propagation ........... 210 Figure 167: S1 Partial knowledge base example – Informative ............................................................... 213 Figure 168: Control Point Screen Presenting the Discovered Devices - Example .................................. 214


13

Confidential

Figure 169: DRS Session Creation Process – Example 1 – CP Initiating ................................................ 223 Figure 170: DRS Session Creation Process – Example 2 – TV Initiating ................................................. 224 Figure 171: DRS Session Creation Process – Example 3 – Switch Initiating .......................................... 225 Figure 172: DRS Session Creation Process – Example 4 – CP Initiating & Selecting ............................. 226 Figure 173: CRS Session Creation Process – Example 1 – CP/RPE Initiating & Computing .................. 227 Figure 174: CRS Session Creation Process – Example 2 – CP/RPE Initiating & Computing – No SIR ... 228 Figure 175: Initiating Entity Session Creation State Diagram .................................................................. 229 Figure 176: Partner SIR State Diagram..................................................................................................... 231 Figure 177: First Partner Session Initiation State Diagram ...................................................................... 232 Figure 178: Second Partner Session Initiation State Diagram ................................................................. 233 Figure 179: Session Initiation Request OpCode and Payload Formats ................................................... 235 Figure 180: SRQ Type Field ...................................................................................................................... 236 Figure 181: Session Initiation Response OpCode and Payload Formats ................................................ 237 Figure 182: Session Route Query OpCode and Payload Formats with their Relations to SIR and HLIC 239 Figure 183: Session Route Select Request OpCode and Payload Formats ............................................ 243 Figure 184: Session Route Select Response OpCode and Payload Formats ......................................... 244 Figure 185: Session Route Set OpCode and Payload Formats with their HLIC Encapsulation .............. 246 Figure 186: Session Status Response OpCode and Payload Formats .................................................... 248 Figure 187: Session Maintenance U_SNPM OpCode and Payload Formats with their HLIC Encapsulation

........................................................................................................................................................... 251 Figure 188: Session Termination U_SNPM OpCode and Payload Formats with their HLIC Encapsulation

........................................................................................................................................................... 253 Figure 189: CRS Session Routing Example ............................................................................................. 257 Figure 190: Link Status Notify Example ................................................................................................... 258 Figure 191: Link Status Notify Packet Structure ...................................................................................... 261 Figure 192: Link Status Request Packet Structure .................................................................................. 263 Figure 193: Link Status Table Example .................................................................................................... 263 Figure 194: Session Routing Table Example ........................................................................................... 264 Figure 195: Bandwidth Verification for CRS ............................................................................................ 266 Figure 196: Session Routing Example – BDP is the Initiating Entity with RPE ....................................... 267 Figure 197: Session Routing Example – CP is the Initiating Entity with RPE ......................................... 269 Figure 198: Link Status Notify for Session Routing - Example................................................................ 270 Figure 199: Operation Example of RPE implemented on SDME (ID=C) ................................................... 271 Figure 200: An example of Routing Tables for Session Routing. Source ID = A (BDP), Sink ID = H (TV).

........................................................................................................................................................... 272 Figure 201: An example of Link State Packets for Link State Routing Using Dijkstra’s algorithm ......... 273 Figure 202: An example of Link State Table for Link State Routing Using Dijkstra’s algorithm ............. 273 Figure 203: An example of Routing Tables for Link State Routing Using Dijkstra’s algorithm .............. 274 Figure 204: Ethernet Over HDBaseT Data Octet ...................................................................................... 275 Figure 205: Ethernet Over HDBaseT Control Octet .................................................................................. 276 Figure 206: 64B/65B Scheme ................................................................................................................... 277 Figure 207: Downstream - 64B/65B Blocks to TokD12 Tokens Assignment ........................................... 279 Figure 208: Sparse Ethernet Packet format ............................................................................................. 279 Figure 209: Sparse Packet - 64B/65B Blocks to TokD12 Tokens Assignment - Example ....................... 280 Figure 210: Data Transfer on the I²C Bus ................................................................................................. 281 Figure 211: HDBaseT I

2C Flow ................................................................................................................. 282

Figure 212: An Example of I2C Transaction ............................................................................................ 283


14

Confidential

Figure 213: An Example of I2C Transaction over HDBaseT ..................................................................... 284

Figure 214: CEC over HDBaseT system view example ............................................................................ 287 Figure 215: CEC bit timing violation example .......................................................................................... 288 Figure 216: CEC ACK sequence over HDBaseT....................................................................................... 291 Figure 217: CEC NACK bit sequence over HDBaseT ............................................................................... 292 Figure 218: HDMI-AV (TMDS) Periods ...................................................................................................... 294 Figure 219: Mapping HDMI-AV (TMDS) Periods to Link Tokens .............................................................. 294 Figure 220: Active Pixel TokD16 Packet Type Token ............................................................................... 295 Figure 221: Encoding Two TMDS Cycles of Active Pixels data into Three TokD16 tokens .................... 296 Figure 222: Encoding Two TMDS Cycles of Active Pixels data into Four TokD12 tokens ...................... 296 Figure 223: Max length TMDS Active Pixels Data TokD16 Packet Structure ........................................... 297 Figure 224: Encoding Last TMDS Cycle of odd cycles number Active Pixels line .................................. 298 Figure 225: Active Pixel TokD12 Packet Type Token ............................................................................... 298 Figure 226: Encoding one TMDS Cycle of Active Pixels data into Two TokD12 tokens.......................... 299 Figure 227: Max length TMDS Active Pixels Data Packet Structure ........................................................ 300 Figure 228: Data Island Packet Type Token ............................................................................................. 300 Figure 229: Encoding A TMDS Data Island Cycle into One TokD12 token .............................................. 301 Figure 230: Max length TMDS Data Island Packet Structure ................................................................... 301 Figure 231: Encoding Two TMDS Control Cycles into One TokD12 token .............................................. 302 Figure 232: Max Payload length TMDS Control Data Packet (CC) Structure ........................................... 303 Figure 233: Guard Band Encoding ........................................................................................................... 303 Figure 234: Encoding Last TMDS Cycle before GB of odd cycles number Control period ..................... 304 Figure 235: An Extended Type CG Packet encoding an odd number (15) of TMDS Cycles .................... 304 Figure 236: TMDS Clock Info Control Packet ........................................................................................... 306 Figure 237: TMDS Clock Info Packet arrangenment ................................................................................ 306 Figure 238: HDMI-AV Control Packet ....................................................................................................... 306 Figure 239: HDMI-AV Control Token Assignment .................................................................................... 306 Figure 240: HDBaseT IR Message Format ................................................................................................ 309 Figure 241: IR T-Adaptor Info Format ....................................................................................................... 310 Figure 242: Basic IR Downstream packet (CRC and IDLE tokens not shown) ........................................ 310 Figure 243: Extended IR Downstream packet (CRC and IDLE tokens not shown) .................................. 310 Figure 244: Basic IR Upstream Subpacket ............................................................................................... 310 Figure 245: Extended IR Upstream Subpacket ........................................................................................ 311 Figure 246: UART T-Adaptor Info Format................................................................................................. 312 Figure 247: Basic UART Downstream packet (CRC and IDLE tokens not shown) .................................. 314 Figure 248: Extended UART Downstream packet (CRC and IDLE tokens not shown) ............................ 314 Figure 249: Basic UART Upstream Subpacket ......................................................................................... 315 Figure 250: Extended UART Upstream Subpacket .................................................................................. 315 Figure 251: S/PDIF Subframe Format ....................................................................................................... 315 Figure 252: HDBaseT S/PDIF NibbleStream ............................................................................................. 316 Figure 253: IR T-Adaptor Info Format ....................................................................................................... 317 Figure 254: SPDIF Downstream packet (CRC and IDLE tokens not shown)............................................ 318 Figure 255: SPDIF Clock Downstream packet (CRC and IDLE tokens not shown) ................................. 319 Figure 256: SPDIF Upstream Sub-packet ................................................................................................. 319 Figure 257: SPDIF Clock Upstream Sub-packet ....................................................................................... 319


15

Confidential

Table of Tables Table 1: Acronyms ......................................................................................................................................28 Table 2: Glossary ........................................................................................................................................29 Table 3: Transfer-Quality Codes.................................................................................................................37 Table 4: Scheduling-Priority Codes ...........................................................................................................38 Table 5: Downstream Link Tokens types ...................................................................................................40 Table 6: Selecting the Payload Symbols Error Resitance Level ................................................................44 Table 7: Packet Type Codes with Their Associated Properties .................................................................49 Table 8: Packet Type Mapping to the Priority/Quality Plane ......................................................................49 Table 9: Upstream – Status Word Type ......................................................................................................56 Table 10: Upstream – Status Word Type values ........................................................................................57 Table 11: Upstream – Status Word Data values .........................................................................................57 Table 12: Upstream Token Types ...............................................................................................................63 Table 13: Upstream Packet Types ..............................................................................................................64 Table 14: Upstream - DDC over HDBaseT ..................................................................................................66 Table 15: Upstream - CEC over HDBaseT ..................................................................................................66 Table 16: Upstream - HPD over HDBaseT ..................................................................................................67 Table 17: Upstream – Status Word Type ....................................................................................................68 Table 18: Upstream – Status Word Type values ........................................................................................69 Table 19: Upstream – Status Word Data values .........................................................................................69 Table 20: Upstream Ver 2 Packet Types .....................................................................................................76 Table 21: Sparse Ethernet Block Bitmap Token.........................................................................................78 Table 22: Auxiliary Data Sub-packet Type .................................................................................................80 Table 23: DDC over HDSBI .........................................................................................................................88 Table 24: CEC over HDSBI .........................................................................................................................89 Table 25: HDSBI Mode Change Payload ....................................................................................................90 Table 26: HDSBI Active/Silent Change Payload .........................................................................................92 Table 27: HDSBI Frame Abort Payload.......................................................................................................93 Table 28: Info Packet Payload ....................................................................................................................94 Table 29: Long Packet Tokes .....................................................................................................................95 Table 30: Transmitter Test Mode .............................................................................................................. 111 Table 31: Vd Characteristics .................................................................................................................... 116 Table 32: Transmitter Test Mode .............................................................................................................. 128 Table 33: Vd Characteristics .................................................................................................................... 130 Table 34: Sink State Machine Timer Values ............................................................................................. 137 Table 35: Source State Machine Timer Values ......................................................................................... 142 Table 36: HDCD Device Entities ............................................................................................................... 149 Table 37: HDCD Port Entities ................................................................................................................... 152 Table 38: ELV Error Codes ....................................................................................................................... 154 Table 39: HLIC Op Codes ......................................................................................................................... 156 Table 40: HDCD Referrancing Modes ....................................................................................................... 158 Table 41: HLIC Abort Codes ..................................................................................................................... 161 Table 42: T-Adaptor Types bit mapping ................................................................................................... 168 Table 43: DS Max Packet Size Classes mapping to DPSU ....................................................................... 180 Table 44: Discovery Methods per Entity .................................................................................................. 216


16

Confidential

Table 45: Full DS Path PSU Budget per Priority....................................................................................... 220 Table 46: Full US Path PSU Budget per Priority....................................................................................... 220 Table 47: AI_Type ..................................................................................................................................... 237 Table 48: Link Status Notify ..................................................................................................................... 261 Table 49: Link Status Table ...................................................................................................................... 264 Table 50: Session Routing Table .............................................................................................................. 264 Table 51: Ethernet Control Types ............................................................................................................. 276 Table 52: Ethernet Error Handling ............................................................................................................ 278 Table 53: CEC directions .......................................................................................................................... 286 Table 54: Downstream – DDC over HDBaseT .......................................................................................... 307 Table 55: Downstream – CEC over HDBaseT ........................................................................................... 307 Table 56: Downstream – 5V over HDBaseT .............................................................................................. 307 Table 57: IR Message Type ....................................................................................................................... 308 Table 58: IR Source and Sink T-adaptor Attributes .................................................................................. 309 Table 59: UART T-adaptor Attributes ....................................................................................................... 312 Table 60: UART Baud Rate Fixed Predetermined Values ........................................................................ 313 Table 61: UART T-adaptor Info UART Configuration byte format ............................................................ 314 Table 62: SPDIF T-adaptor Attributes ....................................................................................................... 317 Table 63: SPDIF Maxmimal Frame Rate Byte Values ............................................................................... 318


17

Confidential

1 Introduction

HDBaseT is a packet based; switched networking standard which consolidates networking of high throughput,

time sensitive data and control streams with Ethernet data networking over home span, standard CAT5e/6

structured cabling.

The scope of the HDBaseT specification version 2.0 (this document) is to specify:

1. HDBaseT link between two HDBaseT Ports

2. Services provided by the HDBaseT network to protocol/interface/application end point “clients”,

communicating over the network

3. HDBaseT entities and devices

4. Control & Management scheme

5. End point adaptor entities, which provide communication over HDBaseT, for the following interfaces:

a. HDMI 1.4

b. USB

c. S/PDIF

d. Consumer IR

e. UART

All devices complying with this specification shall interoperate with devices complying with HDBaseT

specification version 1.0, acting both as Direct Peer to Peer and as over the network End Nodes.

1.1 HDBaseT Specification Organization

HDBaseT specification is described in the following sections:

1. Introduction – Specifies the technology objectives and provides an overview of the architecture. It also

provides glossary of terms used in this document and in the references.

2. Link Layer – Specifies the protocol definition and packet formats used to transfer the various data types

for both downstream and upstream directions.

3. Physical Layer – Specifies the physical media impairments, the physical coding sub layer, startup

procedures and the electrical specification of the downstream / upstream transmitter and receiver.

4. Control & Management – Specifies the configuration data base and its related control protocol.

5. Network Layer – Specifies the network layer


18

Confidential

1.2 HDBaseT Objectives

1.2.1 HDBaseT Network Objectives

Support in parallel, over the same home span cabling infrastructure, high quality networking of:

o Time sensitive data streams such as

HDMI 1.4 streams with their associated controls

S/PDIF streams

USB streams

o Ethernet data

Provide transparent network attachment for legacy devices/interfaces – HDMI, Ethernet, USB and S/PDIF

Provide transparent network attachment for future supported devices/interfaces – Generalized core network

services

Self installable - HDBaseT devices do not have to be individually configured in order to operate correctly over

the network

Enable pure Ethernet devices to function as HDBaseT Network Control Points

Enable low cost solutions for the CE price points

1.2.2 HDBaseT Link Objectives

• Operation over up to 100m, point to point, unshielded / shielded four twisted pairs CAT5e/6/6a cable with two

middle RJ45 connectors

• Downstream sub link:

– 8Gbps 500Msymbol/sec PAM16 symbols - same as Spec 1.0 downstream sub link throughput

• Upstream sub link:

– 300Mbps 25Msymbol/sec PAM16 symbols DC Balanced - double the throughput of Spec 1.0

upstream sub link

• 200Mbps bi-directional shared between USB 2.0, S/PDIF, IR and UART

• 100Mbps bi-directional Ethernet – same as Spec 1.0

• Support of 100BaseT auto negotiation with fall back to 100BaseT Ethernet only mode when connected to a

regular 100BaseT device – same as Spec 1.0

• Support backward compatibility with Spec 1.0 devices

Multi Stream support: At the same time, over a single link, support at least:

o 8 HDMI 1.4 down streams


19

Confidential

o 12 USB or S/PDIF bi-directional streams

o 8 IR and 8 UART bi-directional streams

Support for general framing to enable future protocol/interface/application clients for the HDBaseT network

Support for T-Network services

Support link management HLIC commands

Support two Low Power Partial Functionality (LPPF) modes:

o LPPF #1 – Support HDBaseT Stand By mode Interface (HDSBI) to transfer DDC, CEC, HPD, HLIC, IR

and UART

o LPPF #2 – Support HDSBI on pairs C&D and 100BaseTX full duplex on pairs A&B

Compliance with CISPR/FCC Class A and Class B EMC/EMI requirements

Support the optional Power over HDBaseT (PoH) cable

o Co-exists with power transfer in Power over Ethernet (PoE) 802.3af and 802.3at techniques

o Extend PoH power transmission to 100W

1.3 Terminology, Definitions and Conventions

1.3.1 Terminology & Definitions

The following sections provides the terminology used throughout this specifications.

1.3.1.1 T-Adaptor

T-Adaptor: An entity which converts some protocol/interface/application data representation to HDBaseT data

representation and/or vice versa. T-adpators use the T-Network services to communicate with other T-

Adaptors of the same type. The following figure depicts examples of T-Adaptors:

HDMI Native HDMI T-StreamHDMI

Source

T-Adaptor

USB

Host

T-Adaptor

Ethernet Link

HDBaseT Link

HDMI Link

USB Link

T-Stream

HDMI

Sink

T-Adaptor

USB

Dev/Hub

T-Adaptor

USB T-Stream USB T-Stream

HDMI T-Stream

USB Native

HDMI Native

USB Native

Figure 1: HDMI and USB T-Adaptor Examples


20

Confidential

1.3.1.2 T-Network & T-Services

In addition to regular Ethernet services the HDBaseT network provides predictable, stable, high throughput

and low latency services for time sensitive communication streams. These general T-Services are offered for

different protocols/interfaces/application T-Adaptors implemented at the network end nodes (or integrated in

switch/daisy chain devices) and wishing to communicate over the HDBaseT network. According to their native

protocol/interface/application requirements, the T-Adaptors select the proper T-Services to communicate over

a connected group of switch/daisy chain devices. The switch/daisy chain devices are not aware of the T-

Adaptors types and handle their messages strictly according to their selected T-Services.

T-Adaptor

Switch /

Daisy Chain

Switch /

Daisy Chain T-Adaptor

…

HDBaseT Data Representation

Oth

er

Inte

rface / L

ocal D

evic

e

Oth

er

Inte

rface / L

ocal D

evic

e

Switch /

Daisy Chain

Switch /

Daisy Chain

Figure 2: T-Network

1.3.1.3 Session

In order for a T-Adaptor to communicate over the network, with another T-Adaptor, a session must be created.

A session defines the communication network path between them and reserves the proper service along it.

Each active session is marked by a SID token (Session ID, sometimes referred to as Stream ID) which is

being carried by each HDBaseT packet, belonging to this session. The switches along the network path switch

packets according to their SID tokens. The usage of SID tokens minimize the overhead of packet addressing

allowing the use of short packets required to insure low latency variation of a multi stream/hops network path

and to utilize efficiently the available throughput.

1.3.1.4 T-Stream

T-Stream: A collection of HDBaseT packet streams which conveys information belonging to one,

protocol/interface/application T-Adaptor, native session. All packets belonging to a certain T-Stream carry the

same SID token. The T-Stream may be comprised of packets of different types each, optionally, requiring a

different level of service from the T-Network.


21

Confidential

HDMI Native sessionHDMI T-Stream SID=xHDMI

Source

T-Adaptor

Ethernet Link

HDBaseT Link

HDMI Link

USB Link

T-Stream

TMDS Stream

DDC Stream

CEC Stream

T-Packet

SID=x

T-Packet

SID=x

T-Packet

SID=x

HDBaseT TMDS packet stream

C-Packet

SID=x

C-Packet

SID=x

C-Packet

SID=x

HDBaseT AV-Control packet stream

Figure 3: T-Stream Example

1.3.1.5 Multi T-Stream T-Adaptor

For some T-Adaptors the native protocol/interface/application may maintain more than one native session, at

the same time. In these cases, the T-Adaptor may create more than one T-stream. USB is an example for

such a protocol since at the same time a USB host may interact with more than one USB device while each

device may be located at a different location in the network. The multi T-Stream T-Adaptor shall split/merge

its native session to the proper T-Streams according to the native conventions of that protocol/interface.

USB Native sessionsUSB T-Stream SID=x

USB

Host

T-Adaptor

Ethernet Link

HDBaseT Link

HDMI Link

USB Link

T-Stream

USB Packets

For Dev ID 1

U-Packet

SID=x

U-Packet

SID=x

U-Packet

SID=x

HDBaseT USB packet stream

U-Packet

SID=y

U-Packet

SID=y

U-Packet

SID=y

HDBaseT USB packet stream

USB Packets

For Dev ID 2USB T-Stream SID=y

Figure 4: Multi T-Stream Example

1.3.1.6 T-Group

T-Group (T-G) – An entity which provides a network interface point for one or more T-Adaptors of different

types:

Only T-Adaptors which are associated with the same T-Group may be coupled in a single session

Single T-Stream T-Adaptors are associated with one T-Group, Multi T-Stream T-Adaptors may be

associated with more than one T-Group

Two T-Adaptors, which are both receiving/transmitting the same packet type, cannot be associated

with the same T-Group

A session is created between T-Groups over the T-Network, identified by its SID token and may

include all or some of the T-Adaptors which are associated with these T-Groups

Using the SID the network will route the associated T-Streams packets to the proper T-Group, the T-

Group can dispatch the packets to the proper T-Adaptor according to the packet types and the T-

Adaptor can dispatch packets data to the proper native session according to the packet‟s type and

SID


22

Confidential

A T-Group can take part in more than one active session at the same time. For example, in the case

it is associated with a multi T-Stream T-Adaptor or if the different sessions are using different sub

sets of T-Adaptors from the T-Group.

1.3.1.7 HDBaseT Transmitter Function

HDBaseT Transmitter (TX) Function: An entity which includes a Downstream sub link transmitter and (at least)

an Upstream sub link receiver. A Transmitter couples/decouples one or several T-Streams with a single E-

Stream into/out-of the HDBaseT link.

1.3.1.8 HDBaseT Receiver Function

HDBaseT Receiver (RX) Function: An entity which includes a Downstream sub link receiver and (at least) an

Upstream sub link transmitter. A Receiver couples/decouples one or several T-Streams with a single E-

Stream into/out–of the HDBaseT link.

1.3.1.9 HDBaseT Port Device

HDBaseT Port Device – An entity which is related to one HDBaseT physical interface (RJ45) and includes the

following functions:

One and only one TX/RX function (can be one of: A-symmetric, bi-functional, symmetric)

Zero to 63 instances of T-Adaptors

Zero to 8 instances of T-Groups

When located in a switch device it shall support Ethernet connectivity and LPPF #2

When located in an end node device it may support Ethernet connectivity, shall support LPPF #1

and may support LPPF #2

When located in an end node device, it shall contain at least one T-Adaptor, at least one T-Group

and a Port Device Management Entity (PDME)

Only one Port Device can be associated with a certain HDBaseT physical interface

Each Port Device can be identified using a unique identifier within the device it is located in

1.3.1.10 HDBaseT Switching Elements and Switch Device Definitions

T-Switching Element – An entity which performs switching of T-Streams HDBaseT packets according

to their SID tokens.


23

Confidential

Ethernet switching element – An entity which performs native Ethernet MAC addresses switching. In

each network hop the Ethernet data is being encapsulated into HDBaseT packets, at one end and

de-capsulated at the other end, before it is switched by the Ethernet switching element. Such

mechanism insures seamless connectivity of HDBaseT devices to legacy Ethernet networks and

devices.

Switching Device Management element (SDME) – An entity which manages the operation of the

switching device, its interaction with other switching devices in the Network and with the HDBaseT

Control Functions.

HDBaseT Switching Device – A HDBaseT device comprising all of the following:

o one T-Switching Element

o one Ethernet Switching Element

o Switching Device Management Element (SDME)

Embedded T-Adaptors and Virtual Ports:

o A switch device may contain embedded T-Adaptors. These embedded T-Adaptors will be

associated with one or more T-Groups. These T-Groups will be “located” in one or more

virtual port elements inside the switch. The switch device shall choose the internal

connectivity scheme of these virtual ports and the T-Switching element (virtual port is RX/TX

or symmetric).

RX

RX

RX

E-Switching

Entity

SDME

T-Switching

Entity

TX

Ethernet Link

HDBaseT Link

HDMI Link

USB Link

T-Streams

T-StreamsT-Streams

T-Streams

Pure Ethernet

Port Device

HDBaseT

Transmitter

Port Devices

HDBaseT

Receiver Port

Devices

TX

T-Streams

T-Streams

TX

HDMI

Sink

T-Adaptor

USB

Dev/Hub

T-Adaptor

T-Group

HDMI

Source

T-Adaptor

USB

Host

T-Adaptor

T-Group

HDBaseT

Virtual

Transmitter Port

HDBaseT

Virtual

Receiver Port

Figure 5: Switch Device Example


24

Confidential

1.3.1.11 HDBaseT Daisy Chain Device Definition

Daisy Chain Device: A switch device with one port device capable of RX function, another port device capable

of TX function, no other HDBaseT port devices and one or more embedded T-Adaptors with their associated

T-Groups and virtual port elements.

RX

E-Switching

Entity

SDME

T-Switching

Entity

TX

USB

Device

T-Adaptor

HDMI

Source

T-Adaptor

Implemented inside the DVD

Figure 6: Daisy Chain Device Example

1.3.1.12 HDBaseT End Node Device Definition

End Node Device: A device comprising one or more HDBaseT port Devices with no T-Switching functionality

between them. An End Node Device may provide E-Switching functionality. Each end node port device shall

include:

o One or more T-Adaptors associated with one or more T-Groups

o One Port Device Management Entity (PDME)

Each end node port device may provide Ethernet termination (MAC)


25

Confidential

HDMI

Source

T-Adaptor

USB

Host

T-Adaptor

T-Group

HDMI

Source

T-Adaptor TX

Ethernet

Switching

T-Group

PDME

MAC: xxxxxx

E-Stream

Figure 7: End Node Device Example

1.3.1.13 HDBaseT Control Point Function

Control Point (CP) function – An entity which allows the user to control and maintain the T-Network sessions

between the various T-Adaptors in the network. Each CP shall include a Control Point Management Entity

(CPME). A CPME is an entity which communicates with other management entities such as SDMEs, PDMEs

and other CPMEs. CPMEs use regular Ethernet communication therefore a CP can be implemented in any

Ethernet enabled device including pure Ethernet (non HDBaseT) devices. A CP can report the current network

T-Adaptor capabilities, and their directional connectivity and active sessions status. CPs allows the user to

create and control sessions between T-Adaptors/T-Groups. Multiple CPs may exist and operate at the same

time.

1.3.1.14 HDBaseT Devices Map

Devices

Ethernet Devices HDBaseT Devices Other Devices

HDBaseT End Nodes HDBaseT Switches

HDBaseT Daisy Chain

Pure Ethernet Control Point

E-Switching

SDME

T-Switching

Must Have

CPME

Optional

PDME

Must Have

CPME

Optional

E-Switching

CPME

Must Have

Management Entities

Figure 8: HDBaseT Devices Map


26

Confidential

1.3.1.15 Edge/Intra Link/Port/Switch

Edge

o Edge Link – A HDBaseT link which directly connects a switch device with an end node

device

o Edge Port – A HDBaseT Port Device which is the connection point of an Edge Link to a

switch device

o Edge Switch – A HDBaseT switch device which contains at least one edge port or at least

one active T-Adaptor

o Edge SDME – A SDME of an edge switch

Intra

o Intra Link – A HDBaseT link which directly connects a switch device with another switch

device

o Intra Port – A HDBaseT Port Device which is the connection point of an Intra Link to a

switch device

o Intra Switch – A HDBaseT switch device which contains only intra ports and does not

contain active T-Adaptors

o Intra SDME – A SDME of an intra switch

S1

S2

S3 S4

S5

E1E2

E3

E5

E4

E6

E7E8

2

12

34

1

2

34

12

13

1

2

3

3

4

4

S1

S1

1

1

E1

E1

Edge Switch

Intra Switch

Edge Port

Intra Port

End Node device

Embedded T-Adaptors

Edge Link

Intra Link

4

1 Virtual Edge Port

Figure 9: Edge/Intra Link/Port/Switch Example


27

Confidential

1.3.1.16 Sub Network

HDBaseT Sub Network: A group of HDBaseT devices, connected with HDBaseT links between them. The

boundaries of the HDBaseT sub network are defined by the T-Adaptor elements. Legacy networking

interfaces such as Ethernet and HDMI-CEC can be connected to the devices in the HDBaseT Sub Network.

These legacy interfaces may create a connection between HDBaseT Sub Networks over the same legacy

network. In the case of multiple HDBaseT Sub Networks which are connected to the same pure Ethernet

network, they all belong to the same Ethernet broadcast domain.

HDBaseT Sub Network

PC

PVR

Multi user STB

ADSL

Mod

emMulti User Game Box

Ethernet

HDBaseT

HDMI

T-Network

Ethernet

Network

HDBaseT Sub Network

T-Network

Figure 10: Two HDBaseT Sub Networks Connected via the Ethernet Network Example

S1

S2

S3 S4

S5

E1E2

E3

E5

E4

E6

E7E8

2

12

34

1

2

34

12

13

1

2

3

3

4

4

S1

S1

1

1

E1

E1

Edge Switch

Intra Switch

Edge Port

Intra Port

End Node device

Embedded T-Adaptors

Edge Link

Intra Link

4

1 Virtual Edge Port

1 Pure Ethernet

Port

5

S6

E11E10

E9

12

34 Su

b N

etw

ork

A

Sub

Net

wor

k B

Su

b N

etwork

A

Su

b N

etwork

B

Ethernet Link

E3 is connected via Ethernet with E11 but there is no HDBaseT

connectivity between them therefore they are not part of the same

HDBaseT sub network

Figure 11: Multiple Sub Networks Example


28

Confidential

S1

S2

S3 S4

S5

E1E2

E3

E5

E4

E6

E7E8

2

12

34

1

2

34

12

13

1

2

3

3

4

4

S1

S1

1

1

E1

E1

Edge Switch

Intra Switch

Edge Port

Intra Port

End Node device

Embedded T-Adaptors

Edge Link

Intra Link

4

1 Virtual Edge Port

1 Pure Ethernet

Port

5

S6

E11E10

12

34

Ethernet Link

E1 is connected via Ethernet and HDMI with E11 but there is no

HDBaseT connectivity between them therefore they are not part

of the same HDBaseT sub network

E1 is a HDMI

Switch

HDMI Link

Sub Network A

Su

b N

etwork

B

Sub

Net

wor

k A

Sub

Net

wor

k B

E9

Figure 12: Multiple Sub Networks – Connected via Ethernet & HDMI - Example

1.3.2 Acronyms

Table 1: Acronyms

Acronym Definition

AV Audio and Video

BLW Baseline Wander

CEC Consumer Electronics Control

DDC Display Data channel

DS Downstream

FEXT Far End Cross Talk

HDCP High-bandwidth Digital Content Protection

HDSBI HDBaseT Stand By mode Interface

HLIC HDBaseT Link Internal Controls

HPD Hot Plug Detect

ISI Inter Symbol Interference

LPPF Low Power Partial Functionality

Lsb Least significant bit


29

Confidential

Acronym Definition

Msb Most significant bit

MSPS Mega Symbols Per Second

NEXT Near End Cross Talk

PAM Pulse Amplitude Modulation

PCS Physical Coding Sub layer

SER Symbol Error Rate

US Upstream

VESA Video Electronics Standards Association

1.3.3 Glossary

Table 2: Glossary

Term Definition

100BaseT 100 Mbit/s Ethernet under IEEE 802.3

802.3at IEEE future Power over Ethernet standard also known as PoE+

Active pixel data Picture Element. Refers to the actual element of the picture and the data in the digital video stream representing such an element

Auto negotiation An Ethernet procedure by which two connected devices choose common transmission parameters

Cat5e/6/6a Category 5e, Category 6 or Category 6a LAN cables

CEC Consumer Electronics Control - provides high-level control functions between all of the various audiovisual products in a user’s environment

CISPR Set of standards that are oriented primarily toward electromagnetic emissions and electromagnetic emissions measurements

Control period Part of the HDMI link when no video, audio, or auxiliary data needs to be transmitted

Data island Part of the HDMI link when audio and auxiliary data are transmitted using a series of packets

DDC Display Data Channel - used for configuration and status exchange between a single Source and a single Sink

Downstream In the direction of the primary audio and video data flow, i.e. towards the Sink


30

Confidential

Term Definition

(e.g. display)

DVI A video interface standard

Guard band A finite space used as a separator between video tracks

HDBaseT Valens' new digital connectivity

HDCP High-bandwidth Digital Content Protection - a form of digital copy protection

HDMI High-Definition Multimedia Interface - a compact audio/video interface for transmitting uncompressed digital data

HDSBI HDBaseT Stand By mode Interface

HLIC HDBaseT Link Internal Controls

HPD Hot Plug Detection -Used by the sink to indicate its presence to the source

HSYNC Horizontal SYNChronization - a signal given to the monitor telling it to stop drawing the current horizontal line, and start drawing the next line

I2C a multi-master serial computer bus

Link layer Layer 2 of the seven-layer OSI model

LPPF Low Power Partial Functionality

MII Media Independent Interface - a standard interface used to connect a Fast Ethernet (i.e. 100Mb/s) MAC-block to a PHY

PAM Pulse-amplitude modulation - a form of signal modulation where the message information is encoded in the amplitude of a series of signal pulses

PCS Physical Coding Sublayer - a sublayer of layer 1 of the seven-layer OSI model

Physical layer Layer 1 of the seven-layer OSI model

PoE Power over Ethernet - a technology which describes a system to transfer electrical power, along with data, to remote devices over standard twisted-pair cable

RJ45 connector Plugs and sockets typically used to terminate twisted pair cables

RMII Reduced Media Independent Interface - a reduced version of MII, 6-10 pins instead of 16

SCL I2C clock pin

SER Symbol Error Rate

Sink A device with an HDMI input, e.g TV

Source A device with an HDMI output, e.g DVD


31

Confidential

Term Definition

TMDS Transition Minimized Differential Signaling - a technology for transmitting high-speed serial data and is used by the DVI and HDMI video interfaces

Token An information unit used in the interface between the Link Layer and the Physical layer.

Upstream In the direction of the 2nd flow, i.e. towards the Source (e.g. DVD)

UTP Cable Unshielded Twisted Pair cable found in many Ethernet networks and telephone systems

VSYNC Vertical SYNChronization - refers generally to the synchronization of frame changes with the vertical blanking interval

1.3.4 Conformance Levels

may - A keyword which indicates flexibility in the implementation without a preferred option.

shall – A keyword which indicates mandatory requirement.

reserved fields - Data structure fields that are defined in this specification as reserved and therefore they are

not used. Implementation according to this specification shall zero these fields value. Future revisions of this

specification may utilize these fields for other purposes

reserved values - A set of values for fields that are defined in this specification as reserved and therefore an

implementation according to this specification shall not set these values for such field. Future revisions of this

specification may define the meaning of these values and use them.

1.4 References

Philips Semiconductors, the I2C-bus Specification, Version 2.1, January 2000

High-bandwidth Digital Content Protection (HDCP) System Specification, Revision 1.3, December 2006

IEEE Std. 802.3af™-2002

IEEE Std. 802.3-2005 section 2

High-Definition Multimedia Interface (HDMI) Specification Version 1.3a, November 2006

FCC Rules and Regulations, Title 47, Part 15, Subpart B class B

CISPR 22 Class B

Generic framing procedure (GFP) - ITU-T Rec. G.7041/Y.1303 (08/2005)

IEC 60950-1: 2001

VESA, VESA E-DDC Standard, ENHANCED DISPLAY DATA CHANNEL STANDARD Version 1, September

1999


32

Confidential

IEEE 801.1D-2004

UUID RFC 4122, a universally unique identifier (uuid) urn namespace, July 2005

1.5 HDBaseT Overview

HDBaseT is a connectivity link which delivers uncompressed multimedia content, encapsulated using HDMI-

HDCP link layer, from Source to Sink (unidirectional), control data between source and sink (bidirectional) and

100Mbps Ethernet data between the Source and Sink (bidirectional). It can also co-exist with power delivery

over the same cable using Power over Ethernet (PoE) methods.

Multimedia

Source

HDMI - AV

Controls

Ethernet

Multimedia

Sink

Multimedia

Source

HDMI - AV

Controls

Ethernet

Multimedia

Sink

Figure 13: HDBaseT Link – Logical Represenation

HDMI – AV in the above figure represents all the data which, while using regular HDMI physical interface, is

transmitted using the TMDS signals:

HDCP protected Active Pixels Data

HDCP protected Audio and Aux Data

HSYNC and VSYNC signals

CTLxx signals

Guard bands

Controls consist of all controls needed for HDMI-HDCP system and for HDBaseT Link Internal Controls:

DDC

CEC

HPD

5V Indication

TMDS clock related information

HLIC

HDBaseT operates over four twisted pairs, CAT5e/6 UTP cables, terminated with RJ45 connectors, with up to

two middle, passive, RJ45 connectors.


33

Confidential

The HDBaseT link consists of two distinct, asymmetric, unidirectional sub links: the Downstream Sub Link and

the Upstream Sub Link.

Source

SoC

HDBaseT

Src

HDBaseT

Sink

Sink

Soc

UTP Cables Up to 100m

RJ45RJ45Wall plates

Wall mounted link segment

PatchPatch

Downstream Sub Link 4x250M/500M PAM16 Sym/Sec

Upstream Sub Link 4x12.5M PAM16 Sym/Sec

HDMI-AV Data

Controls

Ethernet Data

Controls

Ethernet Data

Source

SoC

HDBaseT

Src

HDBaseT

Sink

Sink

Soc

UTP Cables Up to 100m

RJ45RJ45Wall plates

Wall mounted link segment

PatchPatch

Downstream Sub Link 4x250M/500M PAM16 Sym/Sec

Upstream Sub Link 4x12.5M PAM16 Sym/Sec

HDMI-AV Data

Controls

Ethernet Data

Controls

Ethernet Data

Figure 14: HDBaseT Link - Sub Links and Link Structure

The Downstream Sub Link, directed from source to sink, carries the HDMI-AV data as well as the source to

sink portion of the Ethernet data and the Controls. The various data types are grouped into “data type specific”

packets that are being multiplexed over the downstream sub link.

The Downstream Sub Link Basic Mode provides up to 4Gbps throughput using symbol rate of 250MSPS.

The Downstream Sub Link Enhanced Mode provides up to 8Gbps throughput using symbol rate of

500MSPS.

Since the Downstream Sub Link operates at a symbol rate which is asynchronous to the TMDS clock, the

Downstream Sub Link also provides means to measure the TMDS clock at the Source side, to transfer the

clock related information to the Sink over the HDBaseT Downstream Sub Link and to reconstruct the TMDS

clock using this information at the Sink side.

The Upstream Sub Link, directed from Sink to Source, carries the sink to source portion of the Ethernet data

and the controls of the return channel. It can provide up to 150Mbps at a symbol rate of 12.5MSPS.

Both Sub Links utilize all four twisted pairs of the UTP cable transmitting in full duplex, downstream and

upstream at the same time.

HDBaseT also provides different transmission quality for the various data types by using different modulations

according to the data type which is being transferred.


34

Confidential

HDMI-AV:

Pixel/Aux Encrypted Data V/HSYNC and CTLxx

TMDS Clock

SCL

HDMI-AV

Packetizer

I²C

Slave Inf

Controls

Packetizer

Controls

DePacketizer

Downstream

Link

Scheduler

TMDS Clk

Measure

CEC Data

5V Indication

Ethernet

Packetizer

HPD

Ethernet

DePacketizerUpstream

Link

Dispatcher

Ethernet Data

Ethernet Data

Clock

Info

CEC Data

Downstream Link

Upstream Link

FIFO

HDMI – HDCP

Link Layer

Link

Management

FIFO

CEC

Interface

SDA

CEC

Ethernet

Switch / MAC FIFO

Video

Audio

V/Hsync

CTLxx

PCS RX

PCS TX

Upstream

Downstream

Source Phy

Hybrid

Link Tokens

Link Tokens

RJ45

HLIC

HLIC

DDC Data

DDC Data

HDBaseT Master

Clock Domain

TX

Data

MII / RMII

MII / RMII

MII / RMII /

100BT Phy

Link Layer Physical Layer

Figure 15: HDBaseT Single Stream Source Architecture


35

Confidential

HDMI-AV:

Pixel/Aux Encrypted Data V/HSYNC and CTLxx

TMDS Clock

SCL

HDMI-AV

DePacketizer

I²C

Master Inf

Controls

DePacketizer

Controls

Packetizer

Downstream

Link

DisPatcher

TMDS Clk

Regenerate

CEC Data

5V Indication

Ethernet

DePacketizer

HPD

Ethernet

PacketizerUpstream

Link

Scheduler

Ethernet Data

Ethernet Data

Clock

Info

CEC Data

Downstream Link

Upstream Link

FIFO

HDMI – HDCP

Link Layer

Link

Management

FIFO

CEC

Interface

SDA

CEC

Ethernet

Switch / MAC FIFO

Video

Audio

V/Hsync

CTLxx

PCS TX

PCS RX

Upstream

Downstream

Sink Phy

Hybrid

Link Tokens

Link Tokens

RJ45

HLIC

HLIC

DDC Data

DDC Data

HDBaseT Slave

Clock Domain

TX

Data

MII / RMII

MII / RMII

MII / RMII /

100BT Phy

Link Layer Physical Layer

Figure 16: HDBaseT Single Stream Sink Architecture


36

Confidential

2 Link Layer

Section ‎2.1 – Describes the general services provided by the HDBaseT Link Layer.

Section ‎2.2 - Describes the Downstream Link Layer.

Section ‎2.3 – Describes the Upstream Link as was specified in Spec 1, referred to here as the Upstream Link

Ver 1.

Section ‎2.4 - Describes Upstream Link Ver 2.

2.1 General

The Link Layer defines the general framing format, used by the different T-Adaptors to create their packets T-

Stream and to specify their required T-Network services. The Link Layer, using the services provided by the

Physical Layer, is responsible to provide to these packets the proper T-Network service as conveyed in the

packet header, when transmitted into the link and when received from the link.

2.1.1 T-Network Services

The HDBaseT network core provides general, packet based, T-Network services for the different T-Adaptors

attached to it:

Highest level of, over the network, Transfer-Quality for packet headers

Three levels of, over the network, Transfer-Quality for packet payloads translating into

different packet error rate figures per quality level

Three levels of, over the network, packet Scheduling-Priority translating into different latency

and latency variation figures per priority level

Clock measurement service, enabling the T-Adaptor client to measure the frequency offset

between the originating T-Adaptor clock and the target T-Adaptor clock to enable proper

clock regeneration for mesochronous applications such as video

Bad-CRC-notification propagation to the target T-Adaptor, enabling the T-Adaptor to treat this

packet according to its specific application

Nibble Stream service supporting split and merge of packets going in and out of the upstream

links on their network path


37

Confidential

2.1.1.1 Transfer-Quality and Scheduling-Priority

For each HDBaseT packet type, there are associated Transfer-Quality and Scheduling-Priority properties

according to the requirement of the data type being carried by this packet. Currently specified packet types

(Link Specification ver 1.0 and ver 2.0) have, pre-defined, Quality and Priority associations. Future packet

types/protocols (Link Specification ver 3.0 and higher) shall carry their Quality and Priority in the extended type

token, within each packet header. Packet type, Quality and Priority properties will be used by the switches

along the network path to insure the proper service is provided for this packet.

The, per packet type, Transfer-Quality property creates differentiation in the service provided by the network, for

different data types, in terms of target maximum Packet Error Rate (PER). For packets with higher Transfer-

Quality, the payload will be transmitted using lower order modulation utilizing more channel bandwidth per info

unit. The HDBaseT Link shall set the actual payload modulation order according to the channel condition and

the required Transfer-Quality.

The following table defines the Transfer-Quality Codes:

Table 3: Transfer-Quality Codes

Very High Quality – Data transfer using this quality code shall be

transfer with at least 1e-16 (PER)

1e-163 (11)

High Quality – Data transfer using this quality code shall be


1e-122 (10)

Normal Quality – Data transfer using this quality code shall be


1e-91 (01)

RemarkMax Allowed Packet

Error Rate

Quality Code

Very High Quality – Data transfer using this quality code shall be


1e-163 (11)

High Quality – Data transfer using this quality code shall be


1e-122 (10)

Normal Quality – Data transfer using this quality code shall be


1e-91 (01)

RemarkMax Allowed Packet

Error Rate

Quality Code

The, per packet type, Scheduling-Priority property creates differentiation in the service provided by the network,

for different data types, in terms of max latency and max latency variation over the full network path. Packets

with higher Priority shall be scheduled, for transmission over the HDBaseT link, before packets with lower

Priorities. Per stream, packets transmitted with the same Priority Code, will arrive to their destination, at the

same order as they were transmitted.

The following table defines the Scheduling-Priority Codes:


38

Confidential

Table 4: Scheduling-Priority Codes

Priority

Code

Max BW

per stream

Max DS Packet

Length (inc.

overhead) [tokens]

Max US Packet

Length (inc.

overhead) [tokens]

Remarks

1 (01) Large

(DS BW)

268

(Full Size)

100 Normal Priority – provides low

latency variation for large BW

Down streams such as video

2 (10) Medium

(US BW)

134

(Half Size)

50 High Priority – provides low

latency variation for mid BW

streams such as S/PDIF

3(11) Small 17

(Small Size)

8 Very High Priority – provides low

latency for small BW, latency

sensitive streams such as DDC

2.1.1.2 Clock Measurement Service

In mesochronous applications, such as video, the target T-Adaptor is required to regenerate the App Clock as

was present in the source T-Adaptor. The source T-Adaptor measures the App Clock with its own reference

clock and sends this information into the T-Network marked in a special packet type. Each hop in the T-Network

operates at a master-slave clocking scheme where the downstream transmitter is the master (the downstream

receiver, and upstream transmitter, “lock” their clock to the downstream transmitter clock). When a packet

propagates on its network path, its transmitting symbol rate is retimed according to the master clock of the next

hop. On this special packet type, the T-Switch/Link-Layer “corrects” the clock measurement data, conveyed in

this packet, according to the frequency offsets between the symbol rate of the ingress hop and the symbol rate

of the egress hop (or the reference clock of the T-Adaptor if the packet reaches its target).

2.1.1.3 Propagation of Bad CRC Notification Service

T-Packet headers and tails are transmitted using the highest quality level; therefore normally they are

transmitted using lower order modulation than their packet payload. In these cases upon detection of bad CRC

at the receiver, the probability that the error is at the payload is much higher than that the header/tail is

erroneous. In these cases the packet continues its way on its network path, propagating the fact that it suffers

from a bad CRC along the path. At a high probability this packet will reach its proper target T-Adaptor which can

decide what to do with this erroneous packet according to the information carried in the packet header and the

protocol it conveys. For certain applications, the header information is used (such as the amount of data

transferred or extended info within the header carrying sync points or other controls). For other applications,

such as video, the payload data may still be useful (assuming only few payload symbols are erroneous).


39

Confidential

2.1.1.4 Nibble Stream Service

In order to facilitate packet synchronization and to reduce framing overhead, the HDBaseT upstream link

operates using fixed-size packets which carry a plurality of sub packets of different data types. Since the

upstream channel is also very limited in BW, it is important to use its packets efficiently and to minimize the

number of unused symbols slots. An upstream transmitter should be able to split and merge sub packets, of the

same sub type and session ID, according to the upstream packet utilization. HDBaseT Nibble Stream is a

general service which the T-Network provides enabling a T-Adaptor to send its information, over the T-network,

encoded as a sequence of nibbles (4bit units), with some sync points spread along the stream. The T-Network

can split or merge Nibble Stream packets going into or out from the upstream links on their network path. The

T-Network commits to reconstruct the original sequence of nibbles, including the exact location of its sync

points at the target T-Adaptor.

For T-Adaptors defined in this specification (Ver 2.0) the only Nibble Stream users are USB and S/PDIF. They

shall use Nibble Streams on all kinds of network paths: pure DS, pure US and mixed path. Nibble Stream

payload split and merge is not supported over pure DS paths; Nibble Stream packets sent over pure DS paths

will travel intact all the way to their destination T-Adaptor. Future packet types may use Nibble Streams using

the same mechanism. Link Layer/Switches complying with this specification may use, when needed,

NibbleStream split/merge operations on USB, S/PDIF and all future packet types with Scheduling-Priority codes

1 and 2. All future T-Adaptors which use packet types with Scheduling-Priority codes 1 and 2 shall support

HDBaseT Nibble Stream and assumes that, along the upstream path to their destination, their original sub

packets payload may be split and/or merged. Streams which allows mixed path (combination of downstream

and upstream links on their network path) shall also use this method on their downstream packet headers and

shall assume split and merge along the upstream path.

Streams which use Nibble Stream shall use the Extended Control Info token (see ‎2.2.3.11) in some DS

packets / US sub packet headers, to mark Sync Points. The frequency of transmitting Sync Points, preferably

scarce, is data type dependant and their location is preserved across all splits and merges.

There are two types of sync points: start and end. If a packet/sub-packet is marked with a Start Sync Point, its

payload cannot be merged with a previous packet‟s payload and the Start Sync Point is at the beginning of the

data conveyed in this packet‟s payload. If a packet / sub packet is marked with an End Sync Point, its payload

cannot be merged with a following packet‟s payload and the Sync Point is at the end of the data conveyed in

this packet‟s payload. A packet/sub-packet may contain both Start and End sync points.

A Nibble Stream packet/sub-packet may carry some T-adaptor specific info in the Extended Info sub field of its

Extended Control Info Token and/or Generic Extended Info Tokens (see ‎2.2.3.11, ‎2.4.3). When splitting such

packet/sub-packet the T-adaptor specific info shall be only conveyed in the first resulting packet/sub-packet

(carrying the Start Sync Point of the original packet/sub-packet).

2.1.2 Variable Bit Rate / Error Resistance Level Link Tokens

The Link Layer interfaces with the Physical Layer using Link Tokens. Each Link Token corresponds to one

symbol period of the appropriate physical sub link. For example, a Link Token given by the Source

Downstream Link Layer to the Downstream transmitter will be transmitted during one Downstream Sub Link

symbol period (1/500MHz) on all four channels (pairs) at the same time. Another example is that a Link Token

given by the Upstream receiver to the Sink Upstream Link Layer contains data that was captured in one

Upstream Sub Link period (1/25MHz) on all four channels (pairs).


40

Confidential

In order to accommodate for different transfer quality requirements for different data types, HDBaseT provides

three levels of Error Resistance for Link Tokens. The more bits per Link Token, the higher modulation order

used by the Physical Layer (on all four channels) to transmit the symbol, which results in reduced error

resistance.

The following table specifies the Link Tokens types:

Table 5: Downstream Link Tokens types

Link Token Type Name Number of transferred bits per

symbol (DS/US)

Error Resistance Meaning

TokD16 16 Normal 16 Data bits

TokD12 12 High 12 Data bits

TokD8 8 Very High 8 Data bits

TokPtp 8 / 4 Very High Packet Type

TokCrc 8 Very High Packet CRC

TokIdl 8 / 4 Very High Idle Symbol

TokD4 4 4 Data Bits

2.2 Downstream Link

2.2.1 Local Retransmission

In order to provide the required Transfer-Quality without compromising the transferred throughput, the

downstream sub link utilizes a Local, Single Retransmission mechanism.

The local, single (retransmission shall be done only once) packet retransmission mechanism comprises the

following steps:

Each protected DS packet contains an additional Packet ID (PID) field as a part of its

header, PIDs are transmitted in a sequential order

The receiver detects a CRC error in a received packet with an expected PID or the receiver

receives a good packet and identifies a gap in the PID sequence

The receiver sends a proper retransmission request to the sender via the US sublink

The sender retransmits the packet back to the receiver


41

Confidential

In order to implement such a mechanism without violating the packet sequential order (of the video data for

instance) the receiver must use a buffer that introduces latency on all protected packets, good or bad.

Whenever a retransmitted packet is received it will be inserted into its original location in the receiver buffer

keeping the original packet order. The sender must also use a transmission buffer in case it will need to

retransmit a packet. Since the retransmission mechanism introduces additional latency, per hop, DS packets

with Scheduling-Priority of 3 (highest priority) shall not use this mechanism and DS packets with Scheduling-

Priority of 2 may use this mechanism. All DS packets with Scheduling-Priority of 1 (lowest priority) shall use

this mechanism.

The following figure depicts a conceptual local retransmission mechanism triggered by a bad CRC detection:

PhyDS

Scheduler

123

Retrns

Module Phy DS

Dispatcher

12Source Sink

PhyDS

Scheduler

123

Retrns

Module Phy DS

Dispatcher

123Source Sink

PID: 3 PID: 2

BAD CRC

Retrns

Module

Retrns

Module

PID: 2 PID: 3

Packets not protected

by retransmission

Packets not protected

by retransmission

PhyDS

Scheduler

1234

Retrns

Module Phy DS

Dispatcher

123Source Sink

Retrns

Module

PID: 4 PID: 2 Packets not protected

by retransmission

Retransmission

request PID: 2

request PID: 2

Step 1: Sink detects CRC

error on PID 2 and request

Retransmission

Step 2: Source fetches PID

2 and Retransmit

Step 3: Sink receives the

retransmitted PID 2 and

place it in the right

location in the buffer

0 -1

0

Figure 17: Bad CRC Triggered Conceptual Local Retransmission

The following figure depicts a conceptual local retransmission mechanism triggered by a PID gap detection:


42

Confidential

PhyDS

Scheduler

123

Retrns

Module Phy DS

Dispatcher

13Source Sink

PhyDS

Scheduler

1234

Retrns

Module Phy DS

Dispatcher

134Source Sink

PID: 3 PID: 3 (PID 2 was lost)

Retrns

Module

Retrns

Module


by retransmission

PhyDS

Scheduler

234

Retrns

Module Phy DS

Dispatcher

1234Source Sink

Retrns

Module


by retransmission

Retransmission

request PID: 2

request PID: 2

Step 1: Sink detects that

PID 2 lost and request

Retransmission

Step 2: Source fetches PID

2 and Retransmit

Step 3: Sink receives the

retransmitted PID 2 and

place it in the right

location in the buffer

5

0 -1

0

Figure 18: PID Gap Detection Triggered Conceptual Local Retransmission

If a downstream packet was transmitted as protected by the retransmission mechanism, it shall travel the rest

of its downstream network path (per each network hop) as protected by the retransmission mechanism. Per

session packet stream the T-Adaptor, may preselect to use retransmission-protection for all packets, or for

none of the packets. It shall not change this selection during the session since it may cause packet disorder.

Usage of retransmission shall introduce additional fixed latency of 4000 symbol periods (8uS in 500MSPS) per

hop, while the introduction of additional latency variation shall be minimized.

.

2.2.1.1 Increasing the Retransmitted Packet Error Resistance

Since HDBaseT uses a single retransmission it is desired to increase the error resistance of the retransmitted

data. For this purpose, the retransmitted packet shall use, if possible, payload symbols with lower order

modulation conveying the same data as the original packet:

If the original packet used TokD16 tokens the retransmitted packet shall use TokD12 tokens

If the original packet used TokD12 tokens the retransmitted packet shall use TokD8 tokens

assuming the payload length after the conversion does not exceed 255 symbols

If due to the conversion to lower order tokens the length of the packet payload exceeds 255 symbols, the

packet shall be retransmitted using its original modulation. The max payload length for retransmission-

protected TokD16 packets shall be limited to 190 tokens; therefore the conversion from TokD16 to TokD12 is

guaranteed to not exceed 255 symbols.


43

Confidential

2.2.1.2 Triggering a Retransmission Request

Reception of a retransmission-protected, Good CRC packet with non-consecutive PID (a gap), shall trigger a

retransmission request for the missing PIDs. This gap-detection-triggered request shall be limited to a

maximum of 8 PIDs immediately preceding the recently received PID. For example if a PID of 10 is received

after a PID of 0 (PIDs 1 to 9 are lost), the retransmission request shall include PID 2 to PID 9.

Reception of a Bad CRC packet which appears as a retransmission-protected packet, with non-consecutive PID

shall not trigger a retransmission request and shall be discarded. If it was really a protected packet it will

appear as a PID gap upon the reception of the next good CRC protected packet.

Reception of a Bad CRC packet which appears as a protected packet with TokD8 payload with matching PID,

shall not trigger a retransmission request since the packet header‟s error resistance is the same as the

payload error resistance, and therefore have equivalent probability to be erroneous. This packet shall be

discarded and if it was really a protected packet it will appear as a PID gap upon the reception of the next good

protected packet. Only gap detection shall trigger retransmission requests for packets with TokD8 payload.

Reception of a Bad CRC packet which appears as a retransmission-protected packet, with matching PID and

non-TokD8 payload (TokD16 or TokD12), shall trigger a retransmission request.

2.2.2 Dynamic Payload Error Resistance Level

At each network hop, the Downstream Transmitter shall determine the proper error resistance level per packet

type by selecting TokD16, TokD12 or TokD8 for the packet‟s payload symbols. This selection shall be done

according to the downstream sub link quality, the Transfer-Quality property associated with this packet type and

the usage of retransmission.

When operating in active mode, downstream receivers shall periodically report (to the downstream

transmitters) the quality of the downstream sub link, using Reported Quality Codes (RQC) transferred within the

upstream sub link Idle subtype tokens. The downstream transmitter shall use these reports to assign the proper

error resistance level (TokDx) according to the required Transfer-Quality and retransmission usage:


44

Confidential

Table 6: Selecting the Payload Symbols Error Resitance Level

[TokD12 with RTS, TokD8][TokD12, TokD12][TokD12, TokD12]011

[TokD12 with RTS, TokD8][TokD12, TokD12][TokD16 with RTS, TokD12]100

[TokD12 with RTS, TokD8][TokD12 with RTS, TokD8][TokD12, TokD12] 010

[TokD12 with RTS, TokD8][TokD12 with RTS, TokD8][TokD12 with RTS, TokD8]001

[TokD8 with RTS, TokD8]

[TokD12, TokD12]

[TokD12, TokD12]

[TokD12, TokD12]

Packet Types with Quality

Code 3 will be transmitted at

with max TokDx of:

[RTS able, No RTS]




[TokD16, TokD16]



with max TokDx of:

[RTS able, No RTS]

[TokD12 with RTS, TokD8]000


[TokD16, TokD16] 110

[TokD16, TokD16]111


Code 1 will be transmitted

with max TokDx of:

[RTS able, No RTS]

When Receiver

Reports

Quality Code

(RQC)

[TokD12 with RTS, TokD8][TokD12, TokD12][TokD12, TokD12]011

[TokD12 with RTS, TokD8][TokD12, TokD12][TokD16 with RTS, TokD12]100

[TokD12 with RTS, TokD8][TokD12 with RTS, TokD8][TokD12, TokD12] 010

[TokD12 with RTS, TokD8][TokD12 with RTS, TokD8][TokD12 with RTS, TokD8]001


[TokD12, TokD12]

[TokD12, TokD12]

[TokD12, TokD12]



with max TokDx of:

[RTS able, No RTS]




[TokD16, TokD16]



with max TokDx of:

[RTS able, No RTS]



[TokD16, TokD16] 110

[TokD16, TokD16]111


Code 1 will be transmitted

with max TokDx of:

[RTS able, No RTS]

When Receiver

Reports

Quality Code

(RQC)

TokD16BW:1

TokD16

RTSBW:0.95

TokD12BW:0.75

TokD12

RTSBW:0.71

TokD8BW:0.5

Low Link

Quality

High Link

Quality

Lower

Transfer-Quality Target

Higher

Transfer-Quality Target

When mapping a given set of information bits into different TokDx payload tokens carrying different number of

bits per token, there may be a need to use MSB zero padding in order to fit, the remainder of the information

bits, into the last payload token. When a payload of a packet may dynamically change its number of bits per

symbol (Error Resistance Level) it is important to mark, those MSB zero padding bits, to be able to reconstruct

correctly the information. Since HDBaseT uses TokD16, TokD12 and TokD8 payload symbols, the padding is

in quantas of nibbles (4 bit groups). In the case zero padding is needed an Extended Control Info token, in the

packet‟s header, shall be used to note the number of padding nibbles. The conversion from token type to

another token type shall be done using the “LSB first” approach which means that the data LSBs of the original

token shall be converted first to the new token LSBs, “pushing”, if needed, the remaining original MSBs to the

next new type token LSBs. The following figures shall clarify this approach by some conversion examples:


45

Confidential

Tok1 Tok2

First TokD16 Second TokD16

b15 b0 b0b15

Tok1[11:0] [ Tok2[7:0], Tok1[15:12] ]


b11 b0 b0b11

[ [0,0,0,0],Tok2[15:8] ]

Third TokD12

b11 b0

Tok1[7:0] Tok1[15:8]


b7 b0 b0b7

Tok2[7:0]

Third TokD8

b7 b0

Tok2[15:8]

Fourth TokD8

b0b7

One Nibble

Padding

Figure 19: Converting TokD16 to TokD12 and TokD8 - example

[ Tok2[3:0], Tok1[11:0] ] [ Tok3[7:0], Tok2[11:4] ]


b15 b0 b0b15

Tok1 Tok2


b11 b0 b0b11

Tok3

Third TokD12

b11 b0

Tok1[7:0] [ Tok2[3:0], Tok1[11:8] ]


b7 b0 b0b7

Tok2[11:4]

Third TokD8

b7 b0

Tok3[7:0]

Fourth TokD8

b0b7

[ [0,0,0,0], [0,0,0,0], Tok3[11:8] ]

Third TokD16

b0b15

[ [0,0,0,0], Tok3[11:8] ]

Fifth TokD8

b0b7

Two Nibbles

Padding

One Nibble

Padding



46

Confidential

[ Tok2, Tok1 ] [ [0,0,0,0], [0,0,0,0], Tok3 ]


b15 b0 b0b15

[ Tok2[3:0], Tok1] [ Tok3, Tok2[7:4] ]


b11 b0 b0b11

Tok1 Tok2


b7 b0 b0b7

Tok3

Third TokD8

b7 b0

Two Nibbles

Padding


2.2.3 Downstream Packet Format

Downstream packets are built using the following formats:

2.2.3.1 Non Retransmission-Protected Packet Format

For non retransmission-protected packets the DS sub link uses the same packet format as in Spec 1.0

therefore Spec 1.0 packets are natively supported by this specification and may be sent as-is over Spec 2.0

links. The following figure depicts the non retransmission-protected packet format:

Session ID CRC-8 Idle…

Payload

TokD8TokPtp

Header Tail

Payload

Length

TokD8 TokDxx TokDxx TokDxx TokCrc TokIdl

Optional

Extended Info

0 to 4 Tokens

Packet

Type

TokD8

Figure 22: HDBaseT Downstream Non Retransmisison-Protected Packet Format

The packet starts with a packet header containing:

Packet Type Token (TokPtp) which marks the type of packet, the type of token used for the

packet payload (Error Resistance Level / number of data bits) and if an extended header is

present.


47

Confidential

Optional Extended Header (0 to 4 Extended Info Tokens) which provide additional packet header

info.

Session ID Token (TokD8)

Payload Length Token (TokD8) which specifies the number of payload tokens in this packet.

Each packet contains up to 255 payload tokens. A field in the Packet Type Token marks the Token Type of

the payload tokens and can be one of the following:

TokD8 - All Payload tokens are TokD8 tokens each carrying 8 bits of data.

TokD12 - All Payload tokens are TokD12 tokens each carrying 12 bits of data.

TokD16 – The first 4 payload tokens, if existing, are TokD12 each carrying 12 bits of data, the rest

of the payload tokens are TokD16 carrying 16 bits of data.

The packet tail includes:

One TokCrc token carrying 8 bits of CRC-8 which is being calculated over the packet header and

payload tokens.

One terminating TokIdl (IDLE) token which follows the TokCrc token to complete the packet tail.

After the mandatory terminating TokIdl token, the Downstream Link Layer may start a new packet or, if it has

no data to send, place more TokIdl tokens. Idle tokens shall not be placed during packet transmission

(between Packet Type token and the CRC token) and are allowed only outside the packet boundaries.

The HDBaseT Downstream Link Layer shall zero out all data bits within Idle Tokens (TokIdl).

2.2.3.2 Retransmission-Protected Packet Format

For retransmission-protected packets the DS sub link uses a modified packet format, adding a Retransmission

Header token to the packet header and extending the tail‟s CRC field to CRC-32. The rest of the packet fields

shall use the same exact format as in the non retransmission-protected packet format. The following figure

depicts the retransmission-protected packet format:

Session ID Idle…

Payload

TokD8

Packet

Type

TokPtp

Header Tail

RTS

Header

TokD8 TokDxx TokDxx TokCrc TokIdl

Payload

Length

TokD8 TokCrcTokCrcTokCrc

CRC 32Optional

Extended Info0 to 4 Tokens

TokD8

Figure 23: HDBaseT Downstream Retransmisison Protected Packet Format


48

Confidential

2.2.3.3 Downstream Packet Type Token

The first token in a packet is the Packet Type Token which carries 8 bits of data:

b7 b6

Packet Type

Token

Type

b4b5

Rtrs Packet Type CodeE

Figure 24: HDBaseT Downstream Packet Type

Packet Type Code - 4 bits [b3:b0] : Defining the packet type

Retransmission bit - 1 bit [b4] : If set to one this packet is participating in the retransmission mechanism

and uses the retransmission protected packet format. Note that although in Spec 1.0 the packet type code

field was 5 bits field and included also b4, in all Spec 1.0 defined packet types, b4 is zero therefore this

definition is consistent with Spec 1.0 packet types.

TokenType – 2 bits [b6:b5] : Defines the Token Type of the packet‟s payload tokens:

o 00 – TokD16

o 01 – TokD12

o 10 - TokD8

o 11 – see ‎2.2.3.5

Extended Exist – 1 bit [b7] : If set to one, this token is immediately followed by an Extended TokD8 Token.

2.2.3.4 Defined Packet Types

Each HDBaseT T-Adaptor entity is using one or more packet types for the transmission of its packets T-

Stream. The packet type token, conveys 16 possible packet type codes, some of them are already being used

by Spec 1.0 packets. This specification re-uses the packet types defined in Spec 1.0, adds additional types for

the new T-Adaptors defined in this specification, and reserves the properties of additional packet types to be

used in future specifications. Per packet type, this specification pre defines Transfer-Quality and Scheduling-

Priority properties which shall be used by the link layer and switches along the path when handling packets of

this packet type. The following table specifies the packet type codes allocation with their associated

properties:


49

Confidential

Table 7: Packet Type Codes with Their Associated Properties

Reserved packet type, define in Spec 2.0 1115Reserved



Consumer IR and UART Data, new packet type, define in Spec 2.0 3312CIR / UART Data

S/PDIF Audio Data, new packet type, define in Spec 2.02211S/PDIF Data

USB Data, new packet type, define in Spec 2.01210USB Data

Data Island139HDMI-AV Data Island Data

Active Pixels Data118HDMI-AV Active Pixels Data

Control Period, starts and ends with guard137HDMI-AV Control Data (GCG)

Control Period, starts with guard band136HDMI-AV Control Data (GC)

Control Period, ends with guard band135HDMI-AV Control Data (CG)

Control period, no guard band134HDMI-AV Control Data (CC)

DDC, CEC, HPD, 5V indication333Stream Control

Original Packet is generalized in Spec 2.0 to provide clock measurement

service

232Clock Info

221Ethernet data

Non AV stream related status and control 330General Status

RemarksPriority

Code

Quality CodePacket Type

Code

Packet Type




Consumer IR and UART Data, new packet type, define in Spec 2.0 3312CIR / UART Data

S/PDIF Audio Data, new packet type, define in Spec 2.02211S/PDIF Data

USB Data, new packet type, define in Spec 2.01210USB Data

Data Island139HDMI-AV Data Island Data

Active Pixels Data118HDMI-AV Active Pixels Data

Control Period, starts and ends with guard137HDMI-AV Control Data (GCG)

Control Period, starts with guard band136HDMI-AV Control Data (GC)

Control Period, ends with guard band135HDMI-AV Control Data (CG)

Control period, no guard band134HDMI-AV Control Data (CC)

DDC, CEC, HPD, 5V indication333Stream Control

Original Packet is generalized in Spec 2.0 to provide clock measurement

service

232Clock Info

221Ethernet data

Non AV stream related status and control 330General Status

RemarksPriority

Code

Quality CodePacket Type

Code

Packet Type

The three reserved codes (13,14,15) may be used by future specifications, therefore each switch complying

with this specification, shall support forwarding these packet types according to their associated properties.

The following table shows the mapping of current packet types to the Priority / Quality plane:

Table 8: Packet Type Mapping to the Priority/Quality Plane

General Status

Stream Control

CIR / UART

Clock Info

TMDS Controls

TMDS Data Island

(Reserved Type 14)

Very High

3

Ethernet

S/PDIF

(Reserved Type 13)

USB

High

2

TMDS Active Pixels

(Reserved Type 15)

Normal

1

Very High

3

Shall not use Retransmission

High

2

May use Retransmission

Normal

1

Shall use Retransmission

Priority

Quality

General Status

Stream Control

CIR / UART

Clock Info

TMDS Controls

TMDS Data Island

(Reserved Type 14)

Very High

3

Ethernet

S/PDIF

(Reserved Type 13)

USB

High

2

TMDS Active Pixels

(Reserved Type 15)

Normal

1

Very High

3

Shall not use Retransmission

High

2

May use Retransmission

Normal

1

Shall use Retransmission

Priority

Quality


50

Confidential

2.2.3.5 Support for Future Packet Types

In order to enable, future HDBaseT specifications, to add more packet types, with different properties, this

specification defines the usage of an extended packet type token:

Bad

CRCQuality Priority

b7 b0b6

Packet Type

b4b5

RtrsFuture

Packet Type Code

b7 b0b6

Extended Type

b3b4b5

E1 1 1Token

Type

Figure 25: Extended Type Token

Packet Type Token:

o When b7:b5 are all set to one it marks the presence of a special extended info token called

“extended type token” (Note that b6:b5 set to one are not a valid Token Type field therefore it is

easy to differentiate between extended type token case and “regular” extended info token case

see ‎2.2.3.3)

o Retransmission bit – 1 bit [b4] : If set to one this packet is participating in the retransmission

mechanism and uses the retransmission-protected packet format.

o Future Packet Type Code – 4 bits [b3:b0] : defining the packet type code which will be specified in

future specifications.

Extended Type Token:

o TokenType – 2 bits [b1:b0] : defines the Token Type of the packet‟s payload tokens:

00 – TokD16

01 – TokD12

10 - TokD8

o Priority – 2 bits [b3:b2] : defines the Scheduling-Priority property code (see ‎2.1.1.1 ) associated

with this packet type

o Quality – 2 bits [b5:b4] : defines the Transfer-Quality property code (see ‎2.1.1.1 ) associated with

this packet type

o Bad CRC – 1 bit [b6] : if set to one this packet is propagating bad CRC indication meaning that

this packet suffered a bad CRC in at least one of the hops along its network path.

o Extended Exist – 1 bit [b7] : If set to one, this token is immediately followed by an Extended Info

TokD8 Token (see ‎2.2.3.11).


51

Confidential

Link Layer/Switches complying with this specification shall support this extended type token and provide the

proper service for such packets even when the actual packet type is not known to them (since it will be

defined only in future specifications).

2.2.3.6 Session ID Token

The Session ID token carries 8 bits of data which convey the session identification as it was dynamically

assigned by the HDBaseT network.

NULL Session ID - A Session ID Token, with all its 8 bits equal to zero, is reserved for non specified Session

ID. NULL Session ID shall be use only at the edge of the network or in a simple point to point application as a

local Session ID.

2.2.3.7 Retransmission Header Token

The Retransmission Header token is part of the Retransmission-Protected packet format (see ‎2.2.3.2) and

shall use the following format as depicted in the following figure:

b7 b6 b4b5

Packet ID

Figure 26: Retranssmision Header Token

Packet ID (PID) - 7 bits [b6:b0] : The transmitter shall assign a PID to each packet which is part of

the retransmission mechanism. “New” packets shall use PIDs in sequential order with wrap

around (PID 127 is followed by PID 0). The sequence is used by the receiver to identify gaps (see

‎2.2.1). For a packet which is retransmitted, as a response to a retransmission request, this field

shall contain the original PID of the lost/corrupted packet.

Retransmission Request Enable - 1 bit [b7] : When set to one, this packet is a “new” packet and

shall trigger a retransmission request according to the rules as specified in ‎2.2.1.2. When it is

zero this packet is already a retransmitted packet and shall not trigger additional retransmission

requests. The transmitter shall clear this bit for retransmitted packets.

2.2.3.8 Payload Length Token

The Payload Length token carries 8 bits of data which conveys the number of payload tokens in this packet.

The values 1 to 255 are valid for the Payload Length token. Packets which contain a zero value in their

Payload Length token should be discarded and ignored upon reception.


52

Confidential

2.2.3.9 Downstream Packet CRC-8 Token

The CRC-8 is calculated on the data of the tokens of a packet, from the first token (i.e. Type) until the end of

the payload (i.e. the token before the CRC token).

For example, consider the following packet:

Stream IDType Length

Header

Payload1 Payload2 Crc Idle

Payload Tail

Figure 27: HDBaseT Packet Structure

Type

8-bits

Val=0x43

Payload1

8-bits

Val=0x01

Payload2

8-bits

Val=0x03

Length

8-bits

Val=0x2

Session ID

8-bits

Val=0x0

Figure 28: HDBaseT Token Values Example

The CRC-8 is calculated on the data of the tokens “Type” through “Payload2”. Tokens that contain less than

16-bits of data will be padded with zeros at their MSBs:

Type

0000000001000011

Stream ID

0000000000000000

Length

0000000000000010

Payload1

0000000000000001

Payload2

0000000000000011

Figure 29: Zero Padding

The bits are fed into the CRC-8 calculator starting from the LSB of the first token of the packet (i.e. the Type

token) and ending with the MSB of the last token of the packet (i.e. Payload2 token).

The CRC-8 is calculated according to the following bit level diagram:

S5S0 S1 S2 S6 S7+

Data Bit In

S3 S4+ ++

Figure 30: HDBaseT CRC-8

The CRC state values (S0 through S7) are the content of the CRC token:


53

Confidential

S7 S6 S5 S4 S3 S2 S1 S0

LSB

Crc Token Data

Figure 31: HDBaseT CRC-8 Token Assignment

Before each packet CRC calculation the CRC states (S0 through S7) are zeroed.

For the example given above the value of the resulted 8-bits CRC token is 0xE5.

2.2.3.10 Downstream Packet CRC-32 Token

TBD

2.2.3.11 Extended Info Tokens

In order to reduce the framing overhead HDBaseT uses a minimal packet header which provides the

information needed for normal operation most of the time. For some services and for future scalability, an

extended info token mechanism is provided where up to four extended info tokens may be added immediately

after the Packet Type token (see ‎2.2.3.3). In order to enable future specifications to use this extending

mechanism, Link Layer / Switches complying with this specification shall support up to four extended info

tokens, even if they do not “understand” the content of these extended info tokens.

The Extended Header consists of one of the following:

An Extended Type Token, or

An Extended Control Info Token followed by up to three optional Generic Extended Info Tokens, or

An Extended Type Token, followed by An Extended Control Info Token and up to two optional

Generic Extended Info Tokens

The Extended Type Token exists only for future data types ([b7:b5] of the Packet Type Token are 111) as

detailed in ‎2.2.3.5.

The Extended Control Info Token shall use the following format:

Figure 32: Packet Type Token followed by Extended Conrol Info Token Format


54

Confidential

Extended Info - 2 bits [b1:b0] : Conveys generic T-Adaptor extended information with format and

meaning known only to the T-Adaptor.

Nibbles Pad Num - 2 bits [b3:b2] : Conveys the number of MSB zero padded nibbles in the last

payload token (see ‎2.2.2). If an extended Control Info token does not exist, no padding is

assumed.

Sync Start bit - 1 bit [b4] : If set to one, is marking a Nibble Stream Start Sync point as explained

in ‎2.1.1.4.

Sync End bit - 1 bit [b5] : If set to one, is marking a Nibble Stream End Sync point as explained in

‎2.1.1.4.

Bad CRC – 1 bit [b6] : If set to one this packet suffered a bad CRC somewhere along its network

path.

Extended Exist – 1 bit [b7] : If set to one, this token is immediately followed by an additional

Generic Extended Info Token.

For Non Nibble Stream packet types (see ‎2.1.1.4), switches shall not treat b5 and b4 as Sync bits and shall

not change b5 and b4 when forwarding the packet. T-Adaptors of such packet types may use these bits as two

additional extended info bits.

Generic Extended Info Tokens each carry 7 bits of generic T-adaptor info as shown in the following figure:

b7

Extended Info

b0b6

Generic Extended Info

b3b4b5

E

Figure 33: Generic Extended Info Token Format

Extended Info - 7 bits [b6:b0] : The extended info carried by this token which conveys generic T-

Adaptor extended information with format and meaning known only to the T-Adaptor.

Extended Exist – 1 bit [b7] : If set to one, this token is followed by an additional Generic Extended

Info Token.

In all cases, Bad CRC indication, if exists, is located at the first extended info token immediately after the

packet type token.


55

Confidential

Bad

CRCQuality

Extended Type

E

Token

TypePriority

Nibbles

Pad Num

Bad

CRC

Sync

End

Sync

Start

Extended

InfoE

Extended Control InfoPacket Type

Token

TypeRtrs Packet Type Code1

Packet Type

Rtrs

Future

Packet Type Code1 1 1

Figure 34: Bad CRC Indication Location

Bad CRC indication shall be considered as „zero‟ if there are no Extended Info Tokens in the packet header.

The following figures depict the two options of a maximum length Extended Header (4 Extended Info Tokens):

Packet Type

Token

TypeRtrs Packet Type Code1 Extended Info


1 Extended Info


1 Extended Info


0Nibbles

Pad Num

Bad

CRC

Sync

End

Sync

Start

Extended

Info1

Extended Control Info

Figure 35: Packet Header with Max Number Of Extended Info Tokens for currently defined packet types

Extended Info


1 Extended Info


00 Nibbles

Pad Num

Ext

Info

Sync

End

Sync

Start

Extended

Info1


Bad

CRCQuality

Packet Type

Rtrs

Future

Packet Type Code

Extended Type

11 1 1

Token

TypePriority

Figure 36: Packet Header with Max Number Of Extended Info Tokens for future packet types

The Extended Info token immediately after an Extended Type token, if exist, shall use the Extended Control

Info Token format. The redundant Bad CRC indication bit shall be ignored as a bad CRC indication and may

be use by the T-adaptor to carry an additional extended information bit.

T-Adaptors, sending a packet without an Extended Control Info Token, shall assume that switch devices

along the packet‟s network path, may dynamically add an Extended Control Info Token to indicate a Bad CRC

event (applicable only when Extended Type is not used) or the existence of MSB zero padding nibbles due to

TokDx conversion as explained in ‎2.2.2, in these cases the switch shall add the token, filling the relevant sub

fields and clear the other sub fields to zero.

In the case a switch device performs TokDx conversion as explained in ‎2.2.2 on a packet with an Extended

Control Info, being the last extended info token and as a result of the conversion there is no need, any more,

for the extended control info token (all sub fields values are zero after the conversion), the switch shall

remove the resulted Extended Control Info Token from the packet header. Accordingly, a T-adaptor shall not

transmit a packet with an all zero Extended Control Info Token.

Following are the only valid configurations for the optional extended info tokens for currently defined packet

types:

Packet Type, Control Info

Packet Type, Control Info, Generic Info


56

Confidential

Packet Type, Control Info, Generic Info, Generic Info

Packet Type, Control Info, Generic Info, Generic Info, Generic Info

Following are the only valid configurations for the optional extended info tokens for future packet types:

Packet Type, Extended Type, Control Info

Packet Type, Extended Type, Control Info, Generic Info

Packet Type, Extended Type, Control Info, Generic Info, Generic Info

2.2.4 Downstream Control Packets

Downstream Control Packets are invalidated by CRC errors. These packets should be discarded on CRC

error.

2.2.4.1 HDBaseT Status and Control Packet

HDBaseT Status packets are used to transfer enhanced information, like HLIC. Since this information is

typically long, the HDBaseT Status packets are used to create structures that can carry long sequences of

data. In the next sections of this document there is a detailed explanation of these structures and how to use

the HDBaseT Status packets to create larger structures. The two larger structures are:

The “Bulk” – A “Bulk” is constructed from 2-16 “Long Packets”.

The “Frame” – A “Frame” is constructed from 1-256 “Bulks”.

HDBaseT Status packet has the following format:

Header

TokPtp

Type Stream ID Length

TokD8 TokD8

Status Reserved CRC-8 Idle

HDBaseT Status

Payload

TokD8 TokCrc TokIdl

Tail

TokD8

Figure 37: HDBaseT Status Control Packet

The HDBaseT Status packet carries one byte of status payload (the “Status” token above), referred to as the

Status Word. This work must not be zero. The MSB of the Status Word indicates whether this status word

carries control or data information, according to the following table:

Table 9: Upstream – Status Word Type

Status

Word

MSB

Description

0 This Status Word carry control

information


57

Confidential

1 This Status Word carry data

When it is a control type of Status Word, it has the following format:

LSB

0 Status DataStatus Type

5-bit2-bit1-bit

Table 10: Upstream – Status Word Type values

Status

Type

field

Value

Description

00 General Controls

01 Bulk Type

10 Bulk Index

11 Bulk Length (in bytes)

The Status Data field should be interpreted according to the Status Type field value, as described in the

following table:

Table 11: Upstream – Status Word Data values

Status

Type

Status

Data

field

Value

Description

General

Control

0 Not Allowed

1 Bulk Acknowledge

2 Frame Abort RX

3 Frame Abort TX

3-31 Reserved

Bulk

Type

0 First Bulk in a Frame

1 Continued Bulk in a Frame

2 Last Bulk in a Frame

3 Single Bulk in a Frame


58

Confidential

4-31 Reserved

Bulk

Index

0-31 Bulk Index

Bulk

Length

0-31 Bulk Length - 1 (in 7-bit words)

When it is a data type of Status Word, it has the following format:

LSB

1 Status Data

7-bit1-bit

Data is padded with zeros at the MSB‟s when there is a remainder to the 7-bit division of the payload.

2.2.4.2 Bulk Acknowledge General Status packet

This packet is sent by the receiver of the Bulk to the transmitter of the Bulk, upon the reception of a valid Bulk

which is consistent with the Bulk description (Bulk Type, Bulk Index and Bulk Length). The transmitter of the

Bulk shall expect to receive Bulk Acknowledge packet during the transmission of the next Bulk and not later

than 1 Sec after the transmission of the last Bulk.

LSB

0 0000100

5-bit2-bit1-bit

2.2.4.3 Frame Abort RX General Status packet

This packet is used to inform unsuccessful reception of a Frame. It should be sent by the receiving side, upon

reception of a bad Bulk that is incoherent with its "Bulk Head" description and the current Bulk sequence (the

"Frame"). The receiving side shall disregard the rest of the Frame and look for beginning of Frame indication

("Bulk Head" with "Bulk Index" equals zero). The transmitter of the Frame shall stop transmitting the Frame

and retransmit it.

LSB

0 0001000

5-bit2-bit1-bit


59

Confidential

2.2.4.4 Frame Abort TX General Status packet

This packet is used to inform unsuccessful generation of a Frame. The transmitter of the Frame may send the

Frame Abort packet if it encounter a transmission problem. In this case the receiver of the Frame shall

disregard the rest of the Frame and look for beginning of Frame indication.

LSB

0 0001100

5-bit2-bit1-bit

2.2.4.5 Bulk Head

Bulk Head is consisting of three consecutive HDBaseT Status packets of the types Bulk Type, Bulk Index and

Bulk Length, in that order. See the following example for more detailed explanation.

2.2.4.6 HDBaseT Status Packet Example

Consider a data structure of 14 words, each word is 32-bits (total 56 bytes). This data structure represents a

“Frame”. In this example, “Frame-0” is one such “Frame”. Generally, there could be “Frame-1”, “Frame-2” and

so on.

0000Byte-0 Byte-1 Byte-2 Byte-3Word-0



.

.

.

Frame-0


.

.

.


60

Confidential

To pass “Frame-0” through Downstream HDBaseT, it should first be divided to “Bulks”. Since each “Bulk” is

limited to 32 data words (7-bit word), two “Bulks” should be created where the first “Bulk” will carry data bytes

0 through 27 and the second “Bulk” will carry data bytes 28 through 55.

Byte-0 Byte-1 Byte-2 Byte-3


Byte-24

Byte-30 Byte-31

.

.

.

Bulk-0


.

.

.

Bulk-1

Byte-29

Byte-26 Byte-27Byte-25

Byte-28

The bit stream represented by Byte-0 and on, is reshaped into 7-bit words, Sev-0 and on.

Byte-0Byte-1Byte-2Byte-3

Sev-0Sev-1Sev-2Sev-3

...

...

Byte-27

Sev-31 .MSB LSB

“Bulk-0” is marked as the first “Bulk” in a “Frame” (its “Bulk Type” field is zero), it is also marked as “Bunk” 0

(its “Bulk Index” field is zero) and its total number of data bytes is declared (its “Bulk Length” field is 31 which

represent 32 7-bit words of data in this Bulk).


61

Confidential

Bulk Type010 0x00

Bulk Index

Bulk Length

.

.

.

Bulk Data

Bulk-0

100 0x00

110 0xFF

1 Sev-0

Bulk Data1 Sev-31

“Bulk-1” is marked as the last “Bulk” in a “Frame” (its “Bulk Type” field is two), it is also marked as “Bunk” 1 (its

“Bulk Index” field is one) and its total number of data bytes is declared (its “Bulk Length” field is 31).

Bulk Type010 0x02

Bulk Index

Bulk Length

.

.

.

Bulk Data

Bulk-1

100 0x01

110 0xFF

1 Sev-32

Bulk Data1 Sev-63

Similarly, longer frames can be created by generating "Bulk-2", "Bulk-3 and so on. The shortest frame that can

be created is build out of one "Bulk" that has a "Bulk Type" packet, marking it as a single-in-a-frame ("Bulk

Type" field is three), and carrying one 7-bit word in its "Bulk Data" packet.


62

Confidential

2.2.5 Downstream Link Scheduler

The HDBaseT Downstream scheduler controls the order in which packets are transmitted to the DS link. The

following packet groups are defined according to the different data types transferred by the HDBaseT link:

HDMI-AV Packets (packet type codes: 4, 5, 6, 7, 8, 9)

Control Packets (packet type codes: 0, 2, 3)

Ethernet Packets (packet code: 1)

Once a packet starts to be transmitted (Packet Type Token was transmitted) into the link, its transmission

must be completed (including the mandatory Idle Token at the end of the packet). When there is no packet

that is currently being transmitted on the link, the HDBaseT DS scheduler shall select which of the available

packets is the next one to be transmitted.

The DS Scheduler shall enforce the following priority order between these packet groups:

Control Packets have the highest priority hence they are transmitted before Ethernet packets and

HDMI-AV packets.

Ethernet Packet will be transmitted before HDMI-AV packets.

HDMI-AV Packets have the lowest priority and will be transmitted only if there is no available packet

from another packet group.

Whenever there is more than one available packet of the selected group, the DS Scheduler shall enforce the

following priority order:

HDMI-AV packets shall be transmitted according to the order in which they are constructed from the

TMDS stream.

Ethernet packets shall be transmitted according to the order in which they are constructed from the

RMII/MII MAC interface.

Control packets shall be transmitted according to their packet type codes:

o Packet type code 3 – Asynchronous Stream Control has the highest priority.

o Packet type code 2 – Periodic Stream Control has the mid priority.

o Packet type code 0 – General Status has the lowest priority.

2.3 Upstream Link Version 1

2.3.1 Upstream Packet Format

Unlike the Downstream packets that may be of different lengths, the Upstream packets all have the same

length and format that consists of 23 tokens and holds all the data types needed to be transferred to the other

side (Source side). The packet format is described below:


63

Confidential

Type Ether-1 Ether-2 Ether-17 Ctrl-1 Ctrl-2 Ctrl-3 CRC-8 Idle. . .

Header Ethernet Payload Control Payload Tail

TokPtpB TokIdlBTokD12B TokD8B TokCrcB

Figure 38: Upstream HDBaseT Packet

The tokens concept of the Upstream packet is similar to the Downstream concept with one difference: the

tokens of the Upstream packets are built for DC balancing and therefore contain less bits of data than their

payload, as described below:

Table 12: Upstream Token Types

Link Token Type

Name

Number of

transferred bits

Transfer Quality Meaning

TokD12B 12 Normal 12 Data bits

TokD8B 8 High 8 Data bits

TokCrcB 8 High Packet CRC

TokPtpB 4 Very High Packet Type

TokIdlB 4 Very High Idle Symbol

An Upstream packet starts with the packet header followed by the packet payload (starting right after the

header token and ending just before the CRC token) which is divided into two parts: the first part is dedicated

to Ethernet payload and the second part is dedicated to Control payload. Last is the packet tail which consists

of two tokens: CRC token and IDLE token, after which starts the next packet.

Packets are passed to the PCS layer token by token, with the header token first and the Idle token last.

2.3.2 Upstream Packet Type

The packet starts with the header which consists of one token. The header token type is "TokPtpB" which

contains 4 bits as its data. The content of this token defines the packet type, as described below:


64

Confidential

Table 13: Upstream Packet Types

Packet Type Field Value Remarks

Training 0 The rest of Tokens are Idle tokens (TokIdlB) containing the

scrambler's content

Has Ethernet, Has Control 1 Full Ethernet payload using all Ethernet tokens. Control

payload is dedicated for A/V stream controls (DDC, CEC,

HPD)

No Ethernet, Has Control 2 No Ethernet payload (Ethernet tokens are ignored).

Control payload is dedicated for A/V stream controls

(DDC, CEC, HPD)

Partial Ethernet, Has

Control

3 Partial¹ Ethernet payload using only 11 Ethernet tokens

(the rest are ignored). Control payload is dedicated for A/V

stream controls (DDC, CEC, HPD)

Reserved 4-9 Reserved

Has Ethernet, Has HLIC

Status

10 Full Ethernet payload using all Ethernet tokens. Control

payload is dedicated for HLIC control and status

information

No Ethernet, Has HLIC

Status

11 No Ethernet payload (Ethernet tokens are ignored).

Control payload is dedicated for HLIC control and status

information

Partial Ethernet, Has HLIC

Status

12 Partial¹ Ethernet payload using only 11 Ethernet tokens

(the rest are ignored). Control payload is dedicated for

HLIC control and status information


Idle 15 Idle Packet. The rest of Tokens are Idle tokens (TokIdlB)

containing the scrambler's content

2.3.3 Upstream Ethernet Data

Ethernet data is transferred in the Ethernet Payload portion of the Upstream packet. Ethernet data from the

Ethernet MAC is packed in 8 octets (64-bits) and transformed in 64B/65B conversion scheme as described in

section ‎6.1 to generate one Ethernet block of 65-bits. If three blocks of 65-bits are ready, they are packed in a

“Full Ethernet Payload” format. If only two blocks of 65-bits are ready, they are packed in “Partial Ethernet

Payload” format.

2.3.3.1 Full Ethernet Payload

Converting three Ethernet blocks (65-bits) into 17 tokens of type TokD12B (12-bits):


65

Confidential

Ether 65 Block (64B/65B) 3

Ether-1Ether-2Ether-3Ether-4Ether-5


Ether-6Ether-7Ether-8Ether-9Ether-10Ether-11Ether-17

LSB

LSBIgnored

Reserved



Figure 39: Upstream - 64B/65B Blocks to Ethernet Token Assignment

Each 12-bit word is placed in the respective Token of the packet (Ether-1 through Ether-17) in a reverse order

(LSB first) as described below:

Ether-1 Ether-2 Ether-17. . .

LSB MSB

2.3.3.2 Partial Ethernet Payload

Converting two Ethernet blocks (65-bits) into 11 tokens of type TokD12B (12-bits):




Ether-6Ether-7Ether-8Ether-9Ether-10Ether-11Ether-17 . . . .

LSB

Ignored

ReservedLSB

Figure 40: Upstream - 64B/65B Blocks to Partial Ethernet Token Assignment

Each 12-bit word is placed in the respective Token of the packet (Ether-1 through Ether-11) in a reverse order

(LSB first) as described below:

Ether-1 Ether-2 Ether-11. . .

LSB MSB

Ether-17. . .

2.3.4 Upstream Control Data

Control data is transferred in the Control Payload portion of the Upstream packet. There are three tokens in

the Control Payload that are used in two formats to transfer two types of controls: A/V controls and HLIC

controls and statuses, as detailed hereafter. In both formats, one token (the second one) is reserved.


66

Confidential

2.3.4.1 A/V Controls

A/V controls are DDC, CEC and HPD. They are mapped to the Control payload as described below:

HPDCECDDC0 0 Stream ID

Ctrl-2 Ctrl-3Ctrl-1

Reserved

LSBLSBLSB

Figure 41: Upstream - Control Token Assignment

The DDC content is described below:

Table 14: Upstream - DDC over HDBaseT

DDC

Field

Value

Description

0 No DDC data

1 DDC data bit is zero (0) or Slave Acknowledge

2 DDC data bit is one (1) or Slave Not-Acknowledge

3-7 Reserved

The CEC content is described below:

Table 15: Upstream - CEC over HDBaseT

CEC

Field

Value

Description

0 No CEC data

1 CEC line is LOW

2 CEC line is HIGH

3 Reserved


67

Confidential

The HPD content is described below:

Table 16: Upstream - HPD over HDBaseT

HPD

Field

Value

Description

0 HPD line is zero (0)

1 HPD line one (1)

The Stream ID token has the same structure as in the Downstream packets


68

Confidential

2.3.4.2 HDBaseT Status

HDBaseT Status packets are used to transfer enhanced information, like HLIC. Since this information is

typically long, the HDBaseT Status packets are used to create structures that can carry long sequences of

data. In the next sections of this document there is a detailed explanation of these structures and how to use

the HDBaseT Status packets to create larger structures. The two larger structures are:



HDBaseT Status packet has the following format:

HDBT Status WordReserved1 1

Ctrl-2 Ctrl-3Ctrl-1

Reserved

LSBLSB LSB

Figure 42: Upstream - HDBaseT Status Token Assignment

The HDBaseT Status packet carries one byte of status payload (the “Ctrl-3” token above), referred to as the

Status Word. This work must not be zero. The MSB of the Status Word indicates whether this status word

carries control or data information, according to the following table:

Table 17: Upstream – Status Word Type

Status

Word

MSB

Description

0 This Status Word carry control

information

1 This Status Word carry data

When it is a control type of Status Word, it has the following format:

LSB

0 Status DataStatus Type

5-bit2-bit1-bit


69

Confidential

Table 18: Upstream – Status Word Type values

Status

Type

field

Value

Description

00 General Controls

01 Bulk Type

10 Bulk Index

11 Bulk Length (in bytes)

The Status Data field should be interpreted according to the Status Type field value, as described in the

following table:

Table 19: Upstream – Status Word Data values

Status

Type

Status

Data

field

Value

Description

General

Control

0 Not Allowed

1 Bulk Acknowledge

2 Frame Abort RX

3 Frame Abort TX

3-31 Reserved

Bulk

Type

0 First Bulk in a Frame

1 Continued Bulk in a Frame

2 Last Bulk in a Frame

3 Single Bulk in a Frame

4-31 Reserved

Bulk

Index

0-31 Bulk Index

Bulk

Length

0-31 Bulk Length - 1 (in 7-bit words)

When it is a data type of Status Word, it has the following format:


70

Confidential

LSB

1 Status Data

7-bit1-bit

Data is padded with zeros at the MSB‟s when there is a remainder to the 7-bit division of the payload.

2.3.4.1 Bulk Acknowledge General Status packet

This packet is sent by the receiver of the Bulk to the transmitter of the Bulk, upon the reception of a valid Bulk

which is consistent with the Bulk description (Bulk Type, Bulk Index and Bulk Length). The transmitter of the

Bulk shall expect to receive Bulk Acknowledge packet during the transmission of the next Bulk and not later

than 1 Sec after the transmission of the last Bulk.

LSB

0 0000100

5-bit2-bit1-bit

2.3.4.2 Frame Abort RX General Status packet

This packet is used to inform unsuccessful reception of a Frame. It should be sent by the receiving side, upon

reception of a bad Bulk that is incoherent with its "Bulk Head" description and the current Bulk sequence (the

"Frame"). The receiving side shall disregard the rest of the Frame and look for beginning of Frame indication

("Bulk Head" with "Bulk Index" equals zero). The transmitter of the Frame shall stop transmitting the Frame

and retransmit it.

LSB

0 0001000

5-bit2-bit1-bit

2.3.4.3 Frame Abort TX General Status packet

This packet is used to inform unsuccessful generation of a Frame. The transmitter of the Frame may send the

Frame Abort packet if it encounter a transmission problem. In this case the receiver of the Frame shall

disregard the rest of the Frame and look for beginning of Frame indication.

LSB

0 0001100

5-bit2-bit1-bit


71

Confidential

2.3.4.4 Bulk Head

Bulk Head is consisting of three consecutive HDBaseT Status packets of the types Bulk Type, Bulk Index and

Bulk Length, in that order. See the following example for more detailed explanation.

2.3.4.5 HDBaseT Status Packet Example



so on.




.

.

.

Frame-0


.

.

.

To pass “Frame-0” through Downstream HDBaseT, it should first be divided to “Bulks”. Since each “Bulk” is

limited to 32 data words (7-bit word), two “Bulks” should be created where the first “Bulk” will carry data bytes

0 through 27 and the second “Bulk” will carry data bytes 28 through 55.


72

Confidential



Byte-24

Byte-30 Byte-31

.

.

.

Bulk-0


.

.

.

Bulk-1

Byte-29

Byte-26 Byte-27Byte-25

Byte-28

The bit stream represented by Byte-0 and on, is reshaped into 7-bit words, Sev-0 and on.

Byte-0Byte-1Byte-2Byte-3

Sev-0Sev-1Sev-2Sev-3

...

...

Byte-27

Sev-31 .MSB LSB



represent 32 7-bit words of data in this Bulk).


73

Confidential

Bulk Type010 0x00

Bulk Index

Bulk Length

.

.

.

Bulk Data

Bulk-0

100 0x00

110 0xFF

1 Sev-0

Bulk Data1 Sev-31


“Bulk Index” field is one) and its total number of data bytes is declared (its “Bulk Length” field is 31).

Bulk Type010 0x02

Bulk Index

Bulk Length

.

.

.

Bulk Data

Bulk-1

100 0x01

110 0xFF

1 Sev-32

Bulk Data1 Sev-63


be created is build out of one "Bulk" that has a "Bulk Type" packet, marking it as a single-in-a-frame ("Bulk

Type" field is three), and carrying one 7-bit word in its "Bulk Data" packet.

2.3.5 Upstream CRC-8 Token


the payload (i.e. the token before the CRC token).


74

Confidential

For example, consider the following packet:

Type Ether-1 Ether-2 Ether-17 Ctrl-1 Ctrl-2 Ctrl-3 CRC-8 Idle. . .

Header Ethernet Payload Control Payload Tail

TokPtpB TokIdlBTokD12B TokD8B TokCrcB

Figure 43: HDBaseT Upstream Packet Structure

The CRC-8 is calculated on the data of the tokens “Type” through “Ctrl-3”. Tokens that contains less than 12-

bits of data will be padded with zeros at their MSBs.

The bits are fed into the CRC-8 calculator starting from the MSB of the first token of the packet (i.e. the Type

token), than the MSB of the second token of the packet (i.e. Ether-1) and so on, ending with the LSB of the

last token of the packet (i.e. Ctrl-3 token). Note that this is a reverse order with compare to the way the bits

are fed to the Downstream scrambler (see ‎3.2.2.1).

The CRC-8 is calculated according to the following bit level diagram:

S5S0 S1 S2 S6 S7+

Data Bit In

S3 S4+ ++

Figure 44: Upstream CRC-8

The states (S0 through S7) value is the content of the CRC token:

S7 S6 S5 S4 S3 S2 S1 S0

LSB

Crc Token Data

Figure 45: HDBaseT CRC-8 Token Assignment

Before each packet CRC calculation the CRC machine states (S0 through S7) are zeroed.


75

Confidential

2.4 Upstream Link Ver 2

2.4.1 Upstream Ver 2 Packet Format

The Upstream Ver 2 packets all have the same length of 46 tokens. The packet starts with the packet header

followed by the packet payload (starting right after the header token and ending just before the CRC token)

which is divided into two parts: the first part is dedicated to Ethernet payload and the second part to all other

data types. Last is the packet tail which consists of two tokens: a CRC token and an IDLE token, after which

starts the next packet. The Ethernet payload consists of 17, 12, 11, 7, 1 or no tokens according to the packet

type (‎2.4.1.1).

Header Ether-1 Ether-x CRC-8 Idle

HeaderEthernet Payload Tail

Data-1Data-

(43-x)

Data Subpackets

TokPtp TokIdlTokD12 TokCrc

Ether-2

TokD12 /

TokD4TokD12

Figure 46: Upstream Ver 2 HDBaseT Packet

The header token type is TokPtp (4 bits), the CRC token type is TokCRC (8 bits), the IDLE token type is TokId

(4 bits) and the Etherenet payload token type is TokD12 (12 bits), except for the first token which may be

TokD4 (4 bits) depending on the Header value (see ‎2.4.2). The rest of the packet (Data Subpackets) consists

of a mix of token types as described below.

Packets are passed to the PCS layer token by token, with the header token first and the Idle token last.

2.4.1.1 Upstream Ver 2 Packet Type

The packet starts with the header which consists of one token. The header token type is "TokPtp" which

contains 4 bits as its data. The content of this token defines the packet type, as described below:


76

Confidential

Table 20: Upstream Ver 2 Packet Types

Packet Type Field Value Remarks

Training 0 The rest of the Tokens are Idle tokens (TokIdl) containing

the scrambler's content

Full Ethernet 1 Ethernet carries three non-idle 65-bit blocks, payload is 17

tokens

No Ethernet 2 No Ethernet payload (0 Ethernet Tokens)

Partial Ethernet 3 Ethernet carries two non-idle 65-bit blocks, payload is 11

tokens


Sparse Full Ethernet 9 Ethernet carries three 65-bit blocks, some of them are Idle,

payload is less than 17 tokens

Reserved 10 Reserved

Sparse Partial Ethernet 11 Ethernet carries two 65-bit blocks, some of them are Idle,

payload is less than 11 tokens


Idle 15 The rest of the Tokens are Idle tokens (TokIdl) containing

the scrambler's content

2.4.2 Upstream Ethernet Data

Ethernet data is transferred in the Ethernet Payload portion of the Upstream packet. Ethernet data from the

Ethernet MAC is packed in 8 octets (64-bits) and transformed to a block of 65-bits as described in ‎6.1 to

generate one Ethernet block of 65-bits.

If three blocks of 65-bits are available, they are packed in a “Full Ethernet” format. If only two blocks of 65-bits

are available, they are packed in “Partial Ethernet” format.

If some of the 65-bit blocks are entirely made of Idle symbols, these blocks will not be included in the payload

and the packet shall be sent using the “Sparse Ethernet” format.

The Ethernet payload is carried over 12-bit tokens (TokD12). The mapping of the Ethernet blocks proceeding

from the LSB of the first Ethernet block to the MSB of the last Ethernet block is done by starting at the MSB of

the first Ethernet token, proceeding towards the LSB of the first Ethernet token, then to the MSB of the second

Ethernet token and so on until the last Ethernet token. The extra LSBs of the last Ethernet token are

undefined.

Full Ethernet Payload

Three Ethernet blocks (65-bits) are carried over 17 tokens of type TokD12 (12-bits) as shown in Figure 47.


77

Confidential


LSB MSB

Ether-1

MS

B

LS

B

Ether-2

MS

B

LS

B

Ether-3

MS

B

LS

B

Ether-4

MS

B

LS

B

Ether-5

MS

B

LS

B

Ether-6

MS

B

LS

B

Ether-7

MS

B

LS

B

Ether-8

MS

B

LS

B

Ether-9

MS

B

LS

B

Ether-

10

MS

B

LS

B

Ether-

11

MS

B

LS

B

Ether-

12

MS

B

LS

B

Ether-

13

MS

B

LS

B

Ether-

14

MS

B

LS

B

Ether-

15

MS

B

LS

B

Ether-

16

MS

B

LS

B

Ether-

17

MS

B

LS

B


LSB MSB


LSB MSB

Figure 47: Upstream – Mapping of three 64B/65B Ethernet Blocks onto 17 Ethernet Tokens

Partial Ethernet Payload

Two Ethernet blocks (65-bits) are carried over 11 tokens of type TokD12 (12-bits) as shown in Figure 48.


LSB MSB

Ether-1

MS

B

LS

B

Ether-2

MS

B

LS

B

Ether-3

MS

B

LS

B

Ether-4M

SB

LS

B

Ether-5

MS

B

LS

B

Ether-6

MS

B

LS

B

Ether-7

MS

B

LS

B

Ether-8

MS

B

LS

B

Ether-9

MS

B

LS

B

Ether-

10

MS

B

LS

B

Ether-

11

MS

B

LS

B


LSB MSB

Figure 48: Upstream – Mapping of two 64B/65B Ethernet Blocks onto 11 Ethernet Tokens

Sparse Full/Partial Ethernet Payload

The first token of the payload (2nd

token of the upstream packet) shall be a TokD4 (4 bits) token, which is a

bitmap indicating the skipped over blocks as indicated in Table 21.

The rest of the Ethernet payload could be 0, 6, or 11 tokens long depending on the number of actual (non-

skipped) blocks included.


78

Confidential

Table 21: Sparse Ethernet Block Bitmap Token

Ethernet Block

Bitmap Value

Description Full Ethernet Meaning Partial Ethernet Meaning

0000 All block are present A non-valid value since the Non-Idle format should have been

used

0001 First block skipped Blocks 2 and 3 are present,

using 11 additional TokD12

tokens

Block 2 is present, using 6

additional TokD12 tokens

0010 Second block skipped Blocks 1 and 3 are present,


tokens



0011 First and second

blocks skipped

Blocks 3 is present, using 6


No blocks sent, no

additional tokens used

0100 Third block skipped Blocks 1 and 2 are present,


tokens

A Non-Valid value

0101 First and third blocks

skipped



A Non-Valid value

0110 Second and third

blocks skipped



A Non-Valid value

0111 First, second and third

blocks skipped

No blocks sent, no additional

tokens used

A Non-Valid value

1000-1111 Reserved A Non-Valid value

2.4.3 Upstream Data Sub-packets

Data Sub-packets appear after the Ethernet payload, they contain data of any other type (than Ethernet).

The Data Sub-packets consist of a Sub-packet Header, an optional Sub-packet header extension (zero to four

tokens), an optional Session ID (SID) token, and finally the Sub-packet payload (zero or more tokens).

Sub-packet Header

(1 or 2 tokens)

Session ID Token

(optional)Sub-packet Payload

Extended Sub-packet Header

(0 to 4 tokens)

TokD8b TokD8b or TokD12B

Extended Type

Token

Extended Control

Info TokenGeneric Extended Info Tokens

optionaloptional

Figure 49: Upstream Data Sub-packet Format


79

Confidential

Each sub-packet has an associated Transfer Quality value of 1, 2 or 3. For transfer qualities 1 and 2 the

Upstream uses TokD12 (12-bit) tokens, and for transfer quality 3 TokD8 (8-bit) tokens.

Sub-packet Header

Short Sub-packets

For packets with 8 or less payload tokens (“short sub-packets”) the Sub-packet Header is a single 8-bit token

(TokD8B) with the format shown in Figure 50.

LengthType

b0b1b2b3b4b5b6b7

Ext.

Figure 50: Upstream Data Sub-packet Header Token Format

The MSB is the extension bit (Ext) and is asserted if the Sub-packet Header is extended by Sub-packet

header extension tokens.

The Type field (b6:b3) describes the Sub-packet payload Type, as described below in Table 22: Auxiliary Data

Sub-packet Type. Defined types that are common to the DS and US have the same type value. Types that are

used in the US differently than in the DS are shaded.

The Length field (b2:b0) described the number of sub-packet payload tokens minus 1.


80

Confidential

Table 22: Auxiliary Data Sub-packet Type

Type Field

Value

Quality Priority SID Remarks

General Status 0 3 3 - Link Internal – does not propagate through

network

Reserved 1 2 2 - Ethernet in DS, Reserved for US only data

Clock 2 3 2 +

Stream control 3 3 3 +

Extended 00 4 According to

Extended Header

+ For future data types

Extension bit is asserted Extended 01 5

Extended 10 6

Extended 11 7

Retransmission

Request

8 3 3 - Link Internal – does not propagate through

network

Reserved 9 3 3 + For US only data

USB 10 2 1 +

S/PDIF 11 2 2 +

CIR/UART 12 3 3 +

Reserved 13 2 2 + For Upstream/Downstream data

Reserved 14 3 1 + For Upstream/Downstream data

Filler 15 N/A Extension bit is 0. The Length field indicates

the Downstream Reported Quality Code

(RQC).

Extended

Length

Extension bit is 1

Long Sub-packets

For sub-packets with 9 or more payload tokens (“long sub-packets”) the Sub-packet Header consists of two 8-

bit tokens (TokD8B), as shown in Figure 51. The first is an Extended-Length Token which is a Sub-header

Token, with Ext=1 and Type=15. The second is a Sub-header Token with Ext and Type fields as for short sub-

packets. The payload length in this case is (Ext_Length*8+Length+1) tokens.


81

Confidential

Ext_LengthType

b0b1b2b3b4b5b6b7

Ext.

1 1 1 1 1

Extended Length Token

LengthType

b0b1b2b3b4b5b6b7

Ext.

Sub-packet Header Token

Figure 51: Upsteam Auxiliary Data Long Sub-packet Header consisting of an Extended Length Token and a Sub-packet Header Token

Filler Sub-packet (Token)

When there is no sub-packet data to transmit a Filler Sub-packet is used. The Filler Sub-packet consists of a

single Sub-packet Header Token with Ext=0 and Type=15. The 3-bit length field is used to transmit the

Downstream Reported Quality Codes (RQC), see Table 6.

RQCType

b0b1b2b3b4b5b6b7

Ext.

0 1 1 1 1

Figure 52: Upstream Auxiliary Data Filler Sub-packet (Token)

A Filler Sub-packet (token) carrying the RQC information shall be transmitted at least every 1024 Upstream

packets.

Extended Sub-packet Header

The extended sub-packet header is optionally used for one or several of the following purposes:

Define Quality, Priority and Extended ID of future Data Sub-packets (Types 4-7);

Provide Nibble Stream (see ‎2.1.1.4) control information;

Provide Data Sub-packet Parameters;

Mark that the Data Sub-packet payload was received with bad CRC somewhere along the network.

The Extended Sub-packet Header (see Figure 49) is thus comprised of one of the following:

An Extended Type Token, or

An Extended Control Info Token, optionally followed by up to three Generic Extended Info Tokens, or

An Extended Type Token followed by An Extended Control Info Token and optionally followed by up to

two Generic Extended Info Tokens.

The total length of the Extended Sub-packet Header shall not exceed four (4) tokens.

The Extended Sub-packet Header is similar to the DS Extended Header except for a different Extended Type

Token as detailed below. Please see ‎2.2.3.11 for a description of Extended Control Info Token and Generic

Extended Info Token and their behavior and requirements.


82

Confidential

Extended Type Token

The Extended Type Token is used for future Data Sub-packets (Types 4-7) as the first token in the Extended

Sub-packet Header. It is an 8-bit token (TokD8).

PriorityLengthType

b0b1b2b3b4b5b6b7

Ext.

1 0 1 ID3 ID2

b7

Ext. Quality

b0b1b2b3b4b5b6

Subpacket Header Token Extended Type TokenBad

CRCID1 ID0

Ext. Type ID

b2b3

ID3 ID2

b0b1

ID1 ID0

Figure 53: Upstream Data Sub-packet Header Token, and Extended Type Token

The MSB (b7) of the Extended Type Token is an extension bit, asserted when the Extended Sub-packet

Header continues in the next token (when it is not asserted the next token is the beginning of the payload).

The next bit (b6) is asserted when the sub-packet contains data that was part of a packet which suffered a

CRC mismatch somewhere along the network path.

The next two bits (b5-b4) code the Transfer Quality property associated with this sub-packet payload when

passed on the Downstream Link or Upstream Link (see Table 3).

The next two bits (b3-b2) code the Scheduling Priority property associated with this subpacket payload (3

being the highest and 1 the lowest).

The last two bits together with the 2 LSBs of the Type field of the Sub-packet Header Token code the 4-bit

Extended Type ID.

Session ID (SID) Token

The SID token is used with Types 2-7 and 9-14. It is an 8-bit token (TokD8), carrying the session ID (‎1.3.1.3).

Sub-packet Payload

The Sub-packet Payload consists of either 8-bit (TokD8) or 12-bit (TokD12) tokens according to the Data Sub-

packet Type (Error! Reference source not found.) or the Extended Type Token for future Data Sub-packets.

The number of tokens used is according to the Data Sub-packet Header.

2.4.4 Upstream CRC-8 Token


the payload (i.e. the token before the CRC token). The calculation method is as in Ver 1.


83

Confidential

2.4.5 Upstream IDLE Token

The IDLE token is a 4-bit token (TokIdlB) which ends the packet, and carries the scrambler content for

synchronization verification.

2.5 HDSBI Link Layer

2.5.1 HDBaseT Stand by Interface (HDSBI) Overview

The HDSBI is used to communicate between two HDbaseT compliant devices in LPPF #1 and LPPF #2

modes. It is a low power, bi-directional and symmetric link that used to transfer the following information types:

HLIC (HDBaseT Link Internal Controls) messaging

HDMI Controls (DDC, CEC, HPD/5V)

The HDSBI uses the same cable (i.e. Cat5/6) and connector (i.e. RJ45) as the HDBaseT but uses only two

out of the four available channels, specifically channels C and D. One channel is used to transfer data in the

downstream direction and one channel is used to transfer data in the upstream direction.

The HDSBI link has three states:

Active Send – In this state HDSBI data symbols are transmitted.

Figure 54: HDSBI Overview

Active Wait – In this state HDSBI idle symbol is transmitted.

Silent – In this state nothing is transmitted.

In general, the HDSBI link enters into Active state only when data needs to be transmitted and exit to Silent

state as soon as no data is expected to be transmitted.

The transition from Silent state to Active state is known as the startup sequence. The Active Wait state is used

while the HDSBI link needs to be kept “alive” but there is no actual data to transmit.

2.5.2 Start-Up

The startup sequence is built to guarantee a robust link establishment after a Silent period. There are two

parties participating in the startup sequence:

HDBaseT

Source

HDBaseT

SinkHDSBI

AB

C

D

AB

C

D


84

Confidential

Initiator – this is the party that initiates the startup sequence. Typically, this party is the one that

receives new data (e.g. DDC) and needs to transfer it to the other party.

Follower – the party that detects that the link is no longer in Silent state and respond.

The same device can be Initiator on some occasions and Follower on other.

2.5.2.1 Start-Up Sequence

The Initiator starts to send Idle Symbols to the other partner. In case the Initiator is a source it will

transmit on its C channel and in case the Initiator is a sink it will transmit on its D channel.

The Follower detects activity on one of its channels (C or D), set its receiving cannel accordingly and

start loading its descrambler.

When the Follower‟s descrambler is “locked” it starts to transmit Idle Symbols on its transmitting

channel and wait to receive an Info Packet Request.

The Initiator detects activity on its receiving channel and start loading its descrambler.

When the Initiator‟s descrambler is “locked”, it sends an Info Packet Request and waits to receive an

Info Packet Response.

Upon reception of Info Packet Request, the Follower sends Info Packer Response and move to Active

state.

Upon reception of Info Packet Response, the Initiator move to Active state.


85

Confidential

2.5.2.2 Partner Detection Initiative

During HDSBI Silent state, each party will periodically try to establish a link by acting as Initiator. The period

between two consecutive Partner Detection Initiatives is different between sources to sink to minimize the

probability of the cases where both sides try to act as Initiators at the same time. It is also contain a random

component to assist in the cases where two devices of the same gender try to act as Initiators. This

mechanism guarantees two HDBaseT compliant devices will eventually establish an HDSBI link.

The following table lists the periods between consecutive Partner Detection Initiatives:

Gender Period Remarks

Source 10ms +

bin2udec(Curr_Tx_Scrambler_Seed)us

In the range

between 10ms and

12.047ms

Sink 16ms +

bin2udec(Curr_Tx_Scrambler_Seed)us

In the range

between 16ms and

18.047ms

2.5.2.3 Swap Resolving

The Initiator transmits on a constant channel (C if it is a source and D if it is a sink). The follower detects

activity on either cannels (C or D) and set it transmission to the other channel (D or C respectively), regardless

of its gender (source or sink).

2.5.2.4 Collisions

Collision is the case when both partners are transmitting on the same channel of twisted pair of the cable. This

could happen early in the startup sequence while both sides try to act as initiators (and obviously before the

swap is resolved) and only in certain occasions:

Sink and Source are connected with a crossed cable (C and D are crossed).

Gender Mismatch with uncrossed cable.

A collision will generate a link-down event and a move into the HDSBI Silent state. The two parties will retry to

establish link according to the randomized wait periods that will eventually resolve the swap and with it the

collisions resolving.

2.5.2.5 Link-Down Events

During the startup sequence or any of the Active states, the link will considered to be broken on the following

events:

“Surprising” loss of signal on the RX pair (e.g. not after graceful “HDSBI Active/Silent Change”

messages). Receiver shall identify loss of signal activity within 16 symbol periods

A required Response did not arrive after a certain period at all the allowed retransmissions


86

Confidential

Idle symbols does not match RX descrambler at a “too high” density

Framing Errors (see below) accrue at a “too high” density

o Unexpected SP/EP

o Unexpected NVS

o Missing EP

As a result, the HDSBI link will move to Silent state.

2.5.2.6 Break Link Time-Out

Before any attempt to move out of Silent state, the Break Link Time-Out must elapse. This Break Link Time-

Out allows the other link partner to sense that the HDSBI moved to Silent State and prevent situations in

which one partner moved from Active to Silent and then to Active again and the other partner did not notice

the move to Silent state.

Break Link Time-Out is 32 symbols period.

2.5.2.7 Gender Mismatch

Gender Mismatch is the case were both HDBaseT partners are of the same type (e.g. both are sources or

both are sinks). This information is available within the Info Packet that is sent during the startup sequence or

at any other time.

While in Gender Mismatch, HDMI Controls (e.g. DDC, CEC and 5V/HPD) should not be transferred. Only

HLIC messaging is allowed.

The probability for collision in Gender Mismatch is higher than in Gender Match because both sides start to

transmit on the same channel (C if they are both sources or D if they are both sinks). Eventually, the collision

will be resolved due to the random periods of Partner Detection Re-Try Period.

2.5.3 Packet Delimiter

Each HDSBI packet starts with “Start Delimiter” and ends with “End Delimiter”. The delimiters uses special

symbols called NVS (Non Valid Symbol) for robustness. Each delimiter is 4-bit long where the “Start Delimiter”

built from the levels:

High NVS

fist

High NVS Low NVS Low NVS

last

And the “End Delimiter” built from the levels:


87

Confidential

Low NVS

fist

Low NVS High NVS High NVS

last

2.5.4 Short Packets

HDSBI Short Packets are used to transfer the basic information for which HDSBI is build for, namely, the

HDMI controls data (DDC, CEC, HPD and 5V) and the HDSBI controls and status that is required to establish

the HDSBI link. The other type of information that is transferred over HDSBI but not using the Short Packets is

the HLIC, which will be describe hereafter, in the Long Packets section.

Short Packet has priority over Long Packets. If Short Packets and Long Packets are ready, the Short Packets

will be transferred first.

2.5.4.1 Short Packets Format

Packet

Type

Start

Delimiter

Packet

Payload

4-bits

End

Delimiter

4-bits 4-bits 4-bits

Figure 55: HDSBI Short Packet Structure

HDSBI Short Packet is built from 4 tokens. It starts with “Start Delimiter” token to signal the start of the packet,

followed by the “Packet Type” token to identify the packet type, followed by the “Packet Payload” which

contains the packet‟s 4-bits data and ended with the “End Delimiter” to signal the termination of the packet.

MSB of each token is transmitted first.

2.5.4.2 Short Packet Types

The packet type can be one of the following codes:

Packet

Type

Field

Value

(4-

bits)

Remarks

Long

Packet

0 Reserved for “Long Packets”. No “Short Packet”

should have this “Packet Type”

DDC 1 Pass DDC information (bit value, stop and start)

CEC and 2 Pass CEC information (bit value), 5V/HPD


88

Confidential

5V/HPD information (line status)


Set Stream

ID

9 Set Low portion (LSB) 4-bits of StreamID

10 Set High portion (MSB) 4-bits of StreamID

HDSBI

Mode

Change

11 Changing Modes of Operation

HDSBI

Active/Silent

Change

12 Changing between the Silent and Active modes

of HDSBI


HDSBI Info

Packet

15 Reporting and Receiving information on

HDBaseT compliant device

2.5.4.3 DDC over HDSBI Link

DDC data parsing is done in the same way it is done for the HDBastT. Please refer to chapter DDC Over

HDBaseT Link for more details. Once the DDC data is parsed, it is packed in a Short Packet as described

below:

0001Start

DelimiterDDC Info

4-bits

End

Delimiter


Figure 56: HDSBI DDC Packet Structure

Table 23: DDC over HDSBI

DDC

Info

Field

Value

Description

0 No DDC data

1 DDC data bit is zero (0) or Master Acknowledge

2 DDC data bit is one (1) or Master Not-

Acknowledge

3 Stop Condition


89

Confidential

4 Start Condition

5-7 Reserved

2.5.4.4 CEC and HPD / 5V over HDSBI Link

CEC and 5V/HPD (5V is relevant for source to sink direction and HPD is relevant for sink to source direction)

data parsing is done in the same way it is done for the HDBastT. Please refer to chapter CEC Over HDBaseT

Link and HPD / 5V Indications Over HDBaseT Link for more details. Once the CEC and 5V/HPD data is

parsed, it is packed in a Short Packet as described below:

0010Start

Delimiter

CEC 5V/

HPD Info

4-bits

End

Delimiter


5V/

HPD

Valid

5V/

HPDCEC Info

Figure 57: HDSBI DDC Packet Structure

Table 24: CEC over HDSBI

CEC

Info

Field

Value

Description

0 No CEC data

1 CEC line is LOW

2 CEC line is HIGH

3 Reserved

2.5.4.5 HDSBI Set Stream ID

Used to set, inform and synchronize the Stream ID (8-bit). The “Set Stream ID” has to associate commands

one is for the low portion of the StreamID (the 4-bit LSB) and the second is for the high portion of the

StreamID (the 4-bit MSB.


90

Confidential

1001Start

Delimiter

Stream ID

Low

4-bits

End

Delimiter


Stream ID

Low

4-bits

LSBStream ID

High

MSB

4-bits

StreamID

Figure 58: HDSBI Set Stream ID (Low) Packet Structure

1010Start

Delimiter

Stream ID

High

4-bits

End

Delimiter


Stream ID

Low

4-bits

LSBMSB

4-bits

StreamID

Stream ID

High

Figure 59: HDSBI Set Stream ID (High) Packet Structure

2.5.4.6 HDSBI Mode Change

Used to inform and synchronize the transition of two HDBaseT compliant devices from HDSBI mode (on

standby) to HDBaseT mode (on full power, operational mode)

1100Start

Delimiter

Next

Mode

4-bits

End

Delimiter


Target ModeAck.

Nack.

Req.

Resp.

Figure 60: HDSBI Mode Change Packet Structure

Table 25: HDSBI Mode Change Payload

Next

Mode

Description Value


91

Confidential

Req.

Resp.

This packet is a request for info. Or a

response for a request for info.

0 – request

1- response

Ack.

NAck.

On Request – Acknowledge Required

On Response - Acknowledged

0 – Not ACK or ACK

required

1 – ACK or ACK

required

Target

Mode

The mode both devices tries to move to 00 – HDBaseT Basic

Mode

01 – HDSBI #1

10 – HDSBI #2

11 – HDBaseT

Enhanced Mode

2.5.4.7 HDSBI Active/Silent Change

Used to inform and synchronize the transition between Active and Silent modes of HDSBI.

1100Start

DelimiterMode Info

4-bits

End

Delimiter


0Silent

Act.

Ack.

Nack.

Req.

Resp.

Figure 61: HDSBI Active/Silent Change Packet Structure


92

Confidential

Table 26: HDSBI Active/Silent Change Payload

Mode

Info

Description Value

Req.

Resp.

This packet is a request for change. Or

a response for a request for change.

0 – request

1 - response

Ack.

NAck.

On Request – Acknowledge Required

On Response - Acknowledged

0 – Not ACK or

ACK required

1 – ACK or ACK

required

Silent

Active

This packet is a request/response for

Silent or Active mode chage

0 – Silent

1 - Active

Reserved Reserved 0

2.5.4.8 HDSBI Bulk Acknowledge

This packet is used to inform a successful reception of Bulk. For more information of a "Bulk", please refer to

section ‎2.5.5. It should be sent by the receiving side, upon reception of a complete Bulk that coherent with its

"Bulk Head" description. The transmitter of the Bulk shall expect an acknowledge response within the time

frame of the next transmitted Bulk (to allow consecutive and sequential transmission) and not later than 1 Sec

after the termination of a Bulk (last "End Delimiter").

1101Start

DelimiterReserved

4-bits

End

Delimiter


Figure 62: HDSBI Bulk Acknowledge Packet Structure

2.5.4.9 HDSBI Frame Abort

This packet is used to inform unsuccessful reception or generation of a Frame. For more information of a

"Frame", please refer to section ‎2.5.5. It should be sent by the receiving side, upon reception of a bad Bulk

that is incoherent with its "Bulk Head" description and the current Bulk sequence (the "Frame"). The receiving

side shall disregard the rest of the Frame and look for beginning of Frame indication ("Bulk Head" with "Bulk

Index" equals zero). The transmitter of the Frame shall stop transmitting the Frame and retransmit it.


93

Confidential

The transmitter of the Frame may send the Frame Abort packet if it encounter a transmission problem. In this

case the receiver of the Frame shall disregard the rest of the Frame and look for beginning of Frame

indication.

1110Start

Delimiter

Abort

Type

4-bits

End

Delimiter


Figure 63: HDSBI Frame Abort Packet Structure

Table 27: HDSBI Frame Abort Payload

Abort

Type

Field

Value

Description

0 Abort Frame TX (sent by the

Frame receiver to the Frame

generator)

1 Abort Frame RX (sent by the

Frame generator to the Frame

receiver)

2-3 Reserved

2.5.4.10 HDSBI Info Packet

Used to inform or retrieve the link partner‟s information

1111Start

DelimiterMy Info

4-bits

End

Delimiter


0Src

Snk

Req.

Resp.Ver.


94

Confidential

Figure 64: HDSBI Info Packet Structure

Table 28: Info Packet Payload

My Info

Field

Description Value

Ver. Version. Future Use 0 – Current

1 – Future (reserved)

Req.

Resp.

This packet is a request for info. Or a

response for a request for info.

0 – request

1 - response

Src

Snk

Device identified as Sink or Source 0 – Source

1 - Sink

Reserved Reserved 0

2.5.5 Long Packets

Long Packets are used to transfer enhanced information, like HLIC. Since this information is typically long, the

Long Packet has built-in services to create structures that can carry long sequences of data. In the next

sections of this document there is a detailed explanation of the “Long Packet” structure and how to use the

“Long Packet” to create larger structures. The two larger structures are:



2.5.5.1 Long Packets Format

Packet

Type

Start

DelimiterPacket Payload

4-bits

End

Delimiter


Packet

Index

4-bits

Figure 65: HDSBI Long Packet Structure

HDSBI Long Packet is built from 5 tokens. It starts with “Start Delimiter” token to signal the start of the packet,

followed by the “Packet Type” token that is a constant zero (4-bits), followed by the “Packet Index” within the

current Bulk, followed by the “Packet Payload” which contains the packet‟s 24-bits data and ended with the

“End Delimiter” to signal the termination of the packet. MSB of each token is transmitted first.


95

Confidential

Table 29: Long Packet Tokes

Token Description

Start

Delimiter

Start of packet indicator

Packet

Type

“Long Packet” must have 0000 in its Packet Type

token

Packet

Index

Packet Index is used to track the “Long Packet”

sequence in the larger structures (“Bulks” and

“Frames”).

When the value of Packet Index is zeros (0) the

“Long Packet” is treated as “Bulk Head”.

When the value of Packet Index is between 1 and

15 the “Long Packet” is treated as “Bulk Data”.

Packet

Payload

Packet Payload carry “Bulk” information (when it is

a “Bulk Head” packet) or “Bulk” data (when it is a

“Bulk Data” packet).

End

Delimiter

End of packet indicator

2.5.5.2 Long Packet Payload Formats

Long Packets payload is used to form Bulks. Each Bulk is started with a “Bulk Head” packet (a “Long Packet”

structure), followed by 1 to 15 “Bulk Data” packets (a “Long Packet” structure). Each “Bulk Data” packet

contains three bytes of data. Thus, the total number of data bytes in a Bulk is 45. The number of data bytes of

a Bulk is declared in the “Bulk Length in Bytes” field of a “Bulk Head” packet.

0000Start

Delimiter

4-bits

End

Delimiter


0000

4-bits

Bulk Index Bulk LengthBulk Type

8-bits 8-bits

Figure 66: Bulk Head Payload

Payload

Field

Field

Value

Description

Bulk

Type

0 First “Bulk” in a “Frame”

1 Continued “Bulk” in a Frame

2 Last “Bulk” in a “Frame”


96

Confidential

3 Single “Bulk” in a “Frame”

4-255 Reserved

Bulk

Index

0-255 Used to track “Bulk” in a “Frame”

Bulk

Length

0-255 The total number of “Data Bytes” in the

“Bulk” -1 (zero represent one Data Byte)

0000Start

Delimiter

4-bits

End

Delimiter


1:15


Data Byte 1 Data Byte 2 Data Byte 3

Figure 67: Bulk Data Payload

2.5.5.3 Long Packet Example



so on.




.

.

.

Frame-0


.

.

.


97

Confidential

To pass “Frame-0” through HDSBI, it should first be divided to “Bulks”. Since each “Bulk” is limited to 45 data

bytes, two “Bulks” should be created where the first “Bulk” will carry data bytes 0 through 44 and the second

“Bulk” will carry data bytes 45 through 79 (this “Bulk” is not full).



Byte-44

Byte-46 Byte-47

.

.

.

Bulk-0


.

.

.

Bulk-1

Byte-45



represent 45 Data Bytes).


98

Confidential

Bulk Head0000Start

Delimiter

End

Delimiter0000 0x00 0x2C0x00

Bulk Data0000Start

Delimiter

End

Delimiter0001 Byte-1 Byte-2Byte-0

Bulk Data0000Start

Delimiter

End


.

.

.Bulk Data0000

Start

Delimiter

End


Bulk-0


“Bulk Index” field is one) and its total number of data bytes is declared (its “Bulk Length” field is 43 represents

4 Data Bytes).

Bulk Head0000Start

Delimiter

End

Delimiter0000 0x01 0x2B0x02

Bulk Data0000Start

Delimiter

End


Bulk Data0000Start

Delimiter

End


.

.

.Bulk Data0000

Start

Delimiter

End

Delimiter1111 Byte-79Byte-78

Bulk-1


be created is build out of one "Bulk" that has a "Bulk Head" packet, marking it as a single-in-a-frame ("Bulk

Type" field is three), and carrying one Data Byte in its "Bulk Data" packet, in which case the Bulk Length is 0.

Short Packets have priority over Long Packets therefore Short Packets may be transmitted / received in-

between Long Packets.


99

Confidential

2.6 HDMI-HDCP Link Layer

HDMI-HCDP Link layer implementations for HDBaseT shall adhere to HDMI specification revision 1.3a

including the HDCP 1.3 implementation

2.7 Ethernet/Switch MAC

Ethernet-Switch MAC implementations for HDBaseT shall adhere to IEEE 802.3-2005 section 2 100BaseT

specification. Switches shall adhere to IEEE 801.1D-2004.


100

Confidential

3 Physical Layer

3.1 General

3.1.1 Physical Media Impairments

HDBaseT operates in full duplex over four twisted pairs, CAT5e/6 UTP cable terminated with RJ45

connectors, with up to two middle, passive, RJ45 connectors. The following figure describes the main

impairments of such link:

NEXT 32

T

R

Hybrid

T

R

Hybrid

T

R

Hybrid

T

R

Hybrid

T

R

Hybrid

T

R

Hybrid

T

R

Hybrid

T

R

Hybrid

RJ45 RJ45 RJ45 RJ45

RJ45 RJ45 RJ45 RJ45

Pair 1 / Channel A

Pair 2 / Channel B

Pair 3 / Channel C

Pair4 / Channel D

FEXT 32

FEXT 42 NEXT 42

NEXT 12

NEAR EchoFAR Echo

Channel Response

ANEXT / EMI

FEXT 12

BLW

T

R

Hybrid

T

R

Hybrid

T

R

Hybrid

T

R

Hybrid

T

R

Hybrid

T

R

Hybrid

T

R

Hybrid

T

R

Hybrid

BLW

Figure 68: Media impairments of full duplex over four twisted pairs system

Channel Response: the effect of the transmission media on the transmitted signal‟s, magnitude and

phase, across the usable frequencies range. This effect causes Inter Symbol Interference (ISI) where

the reception of one symbol is interfered by other symbols that were transmitted, over the same

transmission pair, before and after that specific symbol. In order to achieve the target SER, HDBaseT

Upstream and Downstream receivers shall include equalizers to reduce the residual ISI to an

acceptable level.


101

Confidential

Echo: the reflections of the signal transmitted by the local transmitter over a pair as seen by the local

receiver which operates over the same pair. Echo is caused by impedance mismatches along the link

mainly in the RJ45 connectors and from the Hybrid circuit which combines both the transmitted and

the received signals over the same wire pair. In order to achieve the target SER, HDBaseT Upstream

and Downstream receivers shall include echo cancellers to reduce the residual Echo to an

acceptable level.

Far End Cross Talk (FEXT): the Cross Talk interference from the three, neighbors, Far End

transmitters, as seen on the, fourth pair, received signal. In order to achieve the target SER, an

HDBaseT Downstream receiver shall include FEXT cancellers to reduce the residual FEXT to an

acceptable level. Due to the low symbol rate of the Upstream sub link, the Upstream receiver may

not include FEXT cancellers.

Near End Cross Talk (NEXT) : the Cross Talk interference from the three, neighbors, Near End

transmitters, as seen on the fourth pair received signal. Due to the low symbol rate of the Upstream

sub link, both Upstream and Downstream receivers may not include NEXT cancellers.

Baseline Wander (BLW): HDBaseT source and sink are Transformer Coupled to the line.

Transformers attenuate the low frequency content of the signal such that if the transmitted data

signal includes significant low frequency content, it will be significantly distorted after the transformer.

The effect is being called BLW. HDBaseT uses a special coding on its Upstream sub link (see

‎3.3.1.3‎3.3.1.3) to mitigate the low frequency data content and its related BLW effect.

3.1.2 Master / Slave Clocking Scheme

HDBaseT uses Master-Slave clocking scheme. The HDBaseT source is the master and the HDBaseT sink is

the slave:

The source side shall transmit Downstream symbols using its local clock.

The sink side, Downstream receiver, shall recover the exact transmit clock in order to acquire the

Downstream symbols.

The sink side, Upstream transmitter shall use this recovered clock, divide it by 20 or 40, depending

on the operation mode, to reach the 12.5MSPS Upstream link rate and transmit the Upstream

symbols.

This scheme ensures that both Downstream and Upstream link rates are related to the same reference clock.

It is mainly important in order to facilitate Echo cancelling.

3.1.3 Channels / Polarity Swaps Considerations

Source side, HDBaseT Downstream transmitter shall transmit:

o DS symbols of channel A to pair A - RJ45 connector pins 1 and 2


102

Confidential

o DS symbols of channel B to pair B - RJ45 connector pins 3 and 6

o DS symbols of channel C to pair C - RJ45 connector pins 4 and 5

o DS symbols of channel D to pair D - RJ45 connector pins 7 and 8

Sink side, HDBaseT Downstream receiver shall automatically resolve cable inter pair swaps and

intra pair polarity swaps during Link Startup Training period.

Sink side, HDBaseT Upstream transmitter shall use the pair/polarity swaps, resolved by the

Downstream receiver, to correct the swap in its transmission such that for the Upstream receiver,

located in the source side, the cable would appear as non swap.

For example assuming the cable swaps between channels A and B (A/B crossover). Symbols transmitted to

pair A by the Downstream transmitter are received on “pair B” of the Downstream receiver and symbols

transmitted to pair B by the Downstream receiver, are received on “pair A” of the Downstream receiver. In this

case the Upstream transmitter will transmit the US symbols of channel A to its “pair B” and US symbols of

channel B to its “pair A”. The Upstream receiver will get channel A symbols on its pair A and channel B

symbols on its pair B.

3.2 Downstream Phy

3.2.1 Variable Bit Rate / Protection Level s4dPxx Symbols

HDBaseT physical layer operates using four dimensional symbols (s4d). For each Link Period (1/250M or

1/500M according to the operation mode) the HDBaseT Downstream transmitter PCS, receives a link token

from the link layer, selects the appropriate symbols subset (according to the link token type) and transmits four

symbols, from that selected subset, one per channel according to the scrambled link token data.

The basic set of symbols is the PAM16 set of symbols.

For convenience it is marked using the -15,-13,-11,-9,-7,-5,-3,-1, 1, 3, 5, 7, 9, 11, 13, 15 notation where “15”

corresponds to the positive differential peak and “-15” corresponds to the negative differential peak. All other

symbols subsets are included in the basic set. An s4d symbol (4 symbols - one symbol per channel) taken

from the basic set is called s4dP16, an s4d symbol taken from the subset with 8 symbols is called s4dP8, etc.

Each symbols subset can transfer different number of data bits and provides different level of protection

against noise:


103

Confidential

S4d

Subset

Use to carry Number of

bits per s4d

Symbol

Per Lane

Modulation

Target

SER

s4dP16 TokD16: Active Pixels 16 PAM16 10^(-9)

s4dP8 TokD12:

HDMI Data Island: Audio, Aux

Ethernet Data

12 PAM8 <10^(-22)

s4dP4 TokD8, TokPtp, TokCrc:

Controls

8 PAM4

-15,-7,7,15

<10^(-32)

s4dPI TokIdl:

HDBaseT Idle

8 PAM4

-11,-3,3,11

<10^(-32)

s4dP2 HDBaseT Training 4 PAM2

-7,7

<10^(-32)

s4dP2A HDBaseT Training Alignment

Symbol

4 PAM2

-15,15

<10^(-32)

S4d

Subset

Use to carry Number of

bits per s4d

Symbol

Per Lane

Modulation

Target

SER

s4dP16 TokD16: Active Pixels 16 PAM16 10^(-9)

s4dP8 TokD12:

HDMI Data Island: Audio, Aux

Ethernet Data

12 PAM8 <10^(-22)

s4dP4 TokD8, TokPtp, TokCrc:

Controls

8 PAM4

-15,-7,7,15

<10^(-32)

s4dPI TokIdl:

HDBaseT Idle

8 PAM4

-11,-3,3,11

<10^(-32)

s4dP2 HDBaseT Training 4 PAM2

-7,7

<10^(-32)

s4dP2A HDBaseT Training Alignment

Symbol

4 PAM2

-15,15

<10^(-32)

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

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

PAM16

Basic

Levels

Figure 69: Downstream s4dPxx symbols subsets

S4dP16 – Carries 16 bits of scrambled data SD[15:0], 4 bits per channel:

SD[3:0] are encoded over Channel A.

SD[7:4] are encoded over Channel B.

SD[11:8] are encoded over Channel C.

SD[15:12] are encoded over Channel D.

Per channel, each 4 bits word is being mapped to one symbol using gray code:


104

Confidential

0000 : 15

0001 : 13

0011 : 11

0010 : 9

0110 : 7

0111 : 5

0101 : 3

0100 : 1

1100 : -1

1101 : -3

1111 : -5

1110 : -7

1010 : -9

1011 : -11

1001 : -13

1000 : -15Lsb

Figure 70: Downstream - per channel, mapping bits to s4dP16 symbol

S4dP8 – Carrie 12 bits of scrambled data SD[11:0], 3 bits per channel:






000 : 15

001 : 11

011 : 7

010 : 3

110 : -3

111 : -7

101 : -11

100 : -15Lsb



105

Confidential







00 : 15

01 : 7

11 : -7

10 : -15Lsb


3.2.2 Downstream Physical Coding Sub Layer (PCS)

ScramblerIsTraining

Xor

Link Token Data (TD)

Output (Sout)

Scrambled Link Token Data (SD) Bits

to

s4d

Gen Training

IsTraining

Link Token Type (TT)

A Symbol

B Symbol

C Symbol

D Symbol

s4d

Figure 73: Downstream - Source PCS

For each Link Period, the Downstream source PCS maps a Link Token, received from the Link Layer, into a

s4d symbol (4 channel symbols taken from the same s4dPxx symbols subset). The PCS uses a scrambler to

scramble the Link Token Data (TD) according to its Type (TT) and then maps the scrambled data bits (SD)

into a s4d symbol according to its TT. During Link Training period the PCS generates training sequences

utilizing s4dP2 and s4dP2A symbols.


106

Confidential

The Downstream sink PCS uses the received Training sequence to resolve channels alignment, pair/polarity

swaps and to synchronize its descrambler. During normal operation, for each Link Period, it maps the

received s4d symbol back to bits and descrambles them to regenerate the Link Token.

3.2.2.1 Downstream Scrambler / De-Scrambler

The Downstream Scrambler / De-Scrambler is implemented using the following LFSR:

S0 S1 S2 S37… S38 S39 … S57

++

Scramble / De-Scrambler

Output (Sout)

58 bits Scrambler / De-Scrambler seed

xor

T

Figure 74: Downstream - Scrambler / De-Scrambler LFSR

The scrambler‟s 58 bit seed shall be initialized by the Downstream source PCS to an arbitrary, non all zero,

value.

The scrambler shall operate according to the following two stages:

During Link Training, for each Link period (i.e. 1/250M or 1/500M depending on the operation mode)

the scrambler “produces” 4 bits (4 operations of the above LFSR): Sout[3:0]. Sout[0] denotes the first

bit which was “produced” during this link period and at the end of this link period will reside in S3.

While not in Link Training, for each Link period, the scrambler will “produce” 16 bits (16 operations of

the above LFSR): Sout[15:0]. Sout[0] denotes the first bit which was “produced” during this link

period and at the end of this link period will reside in S15.

During Link Training: the Downstream source PCS, encodes the Sout[3:0], scrambler output, using s4dP2

and s4dP2A symbols and delivers them for physical transmission.

At the sink side the Downstream PCS receives these training symbols and reconstruct the Sout[3:0] original

bits from the source side. These bits can be loaded, now, into the De-Scrambler seed. After 15, non

erroneous, consecutive Link periods the sink De-Scrambler should be in synchronization with the source

Scrambler.


107

Confidential

While not in Link Training: the Downstream source PCS shall “xor” (scramble) the Link Tokens Data (TD)

with the Sout[15:0] scrambler output, to generate the Scrambled Token Data (SD), according to the Link

Token Type:

TokD16: 16 bits of Token Data :

SD[15:0]=TD xor Sout[15:0].

TokD12: 12 bits of Token Data:

SD[11:0]=[ TD[11:9]xorSout[14:12], TD[8:6]xorSout[10:8], TD[5:3]xorSout[6:4], TD[2:0]xorSout[2:0]]

TokD8, TokPtp, TokCrc, TokPIdl: 8 bits of Token Data:

SD[7:0]=[ TD[7:6]xorSout[13:12], TD[5:4]xorSout[9:8], TD[3:2]xorSout[5:4], TD[1:0]xorSout[1:0]]

While not in Link Training the Downstream sink PCS shall regenerate Scrambled Token Data (SD) and the

Token Type from the sequence of s4d symbols it receives from the physical link. It shall “xor” (de-scramble)

then the Scrambled Link Tokens Data (SD) with the Sout[15:0], de-scrambler output to generate the original

Link Token Data (TD) according to the resolved Link Token Type:

TokD16: 16 bits of Token Data :

TD[15:0]=SD xor Sout[15:0].

TokD12: 12 bits of Token Data:

TD[11:0]=[ SD[11:9]xorSout[14:12], SD[8:6]xorSout[10:8], SD[5:3]xorSout[6:4], SD[2:0]xorSout[2:0]]

TokD8, TokPtp, TokCrc, TokPIdl: 8 bits of Token Data:

TD[7:0]=[ SD[7:6]xorSout[13:12], SD[5:4]xorSout[9:8], SD[3:2]xorSout[5:4], SD[1:0]xorSout[1:0]]

3.2.2.2 Downstream Training

During Link Training, the Downstream source PCS transmits the scrambler output using s4dP2 and s4dP2A

symbols:

S4dP2 and s4dP2A – Carries 4 bits of scrambler output Sout[3:0], 1 bit per channel:

Sout[0] is encoded over Channel A.

Sout[1] is encoded over Channel B.

Sout[2] is encoded over Channel C.

Sout[3] is encoded over Channel D.

Per channel, each bit is being mapped as follows:


108

Confidential

1 : 7

0 : -7

s4dP2

1 bit per lane

1 : 15

0 : -15

1 bit per lane

s4dP2A

Training Period

Figure 75: Downstream - per channel, mapping bits to s4dP2 and s4dP2A symbols

These symbols are easy to detect by the sink Downstream receiver. The training sequence enables the

Downstream receiver to:

Solve the channel response, timing, FEXT

Resolve channels alignment

Resolve pair/polarity swap

Synchronize de-scrambler

In order to resolve channels alignment the s4dP2 are usually transmitted while the s4dP2A are rarely

transmitted. Since it is easy to distinguish between s4dP2 and s4dP2A symbols, due to the s4dP2A larger

amplitude, the receiver can resolve the alignment of the channels by matching the appearance of s4dP2A

symbols on all channels.

The number of Link periods between s4dP2A symbols, shall vary between 64 to 127 Link periods in a pseudo

random way. One implementation may be to calculate the number of Link Periods until the next s4dP2A,

using 6 bits of the scrambler current seed, treated as a number (Bin2Dec) with value range of 0 to 63 and add

the constant 64 to get the 64 to 127 value range.

The Downstream receiver shall tolerate channels skew of up to 60nS which corresponds to 30 link periods, at

the fastest mode of operation. Therefore, a gap of at least 64 Link Periods between s4dP2A symbols ensures

a robust detection of channel skew.

After the alignment stage, the Downstream receiver shall check different pair / polarity swap configurations

and load the received bits into its de-scrambler until it reaches a synchronization with the source scrambler.

3.2.2.3 Downstream Idles

During Idle Period and between packets in normal operation period, the Downstream Link Layer provides Idle

Link Tokens to the source PCS. These Idle Link Tokens shall include zero data, and after scrambling

(Scrambled Token Data (SD)) they are mapped to s4dPI symbols for transmission into the cable:

S4dPI – Carries 8 bits of scrambled data (Data before scrambler is all zero) SD[7:0], 2 bits per channel:


109

Confidential






00 : 11

01 : 3

11 : -3

10 : -11Lsb

Figure 76: Downstream - per channel, mapping bits to s4dPI symbol

At the sink side the Downstream PCS shall validate that the de-scrambled content of the received Idle

symbols, is zero and if not it shall count the IdleMisMatchs

3.2.2.4 Downstream Link Tokens to Symbols Modulation








110

Confidential

0000 : 15

0001 : 13

0011 : 11

0010 : 9

0110 : 7

0111 : 5

0101 : 3

0100 : 1

1100 : -1

1101 : -3

1111 : -5

1110 : -7

1010 : -9

1011 : -11

1001 : -13

1000 : -15Lsb








000 : 15

001 : 11

011 : 7

010 : 3

110 : -3

111 : -7

101 : -11

100 : -15Lsb



111

Confidential







00 : 15

01 : 7

11 : -7

10 : -15Lsb

Figure 79: Downstream, per channel, mapping bits to s4dP4 symbol

3.2.3 Downstream Physical interface tests

3.2.3.1 Downstream Isolation requirement

The PHY shall provide electrical isolation between the port device circuits, including frame ground (if any) and

all MDI leads. This electrical isolation shall withstand at least one of the following electrical strength tests:

a) 1500 V rms at 50 Hz to 60 Hz for 60 s, applied as specified in Section 5.2.2 of IEC 60950-1: 2001. b) 2250 V dc for 60 s, applied as specified in Section 5.2.2 of IEC 60950-1: 2001. c) A sequence of ten 2400 V impulses of alternating polarity, applied at intervals of not less than 1s .The

shape of the impulses is 1.2/50 μs (1.2 μs virtual front time, 50 μs virtual time or half value), as defined in Annex N of IEC 60950-1:2001.

There shall be no insulation breakdown, as defined in Section 5.2.2 of IEC 60950-1: 2001, during the test. The

resistance after the test shall be at least 2 MΩ, measured at 500 V dc.

3.2.3.2 Downstream Test modes

The test modes described below shall be provided to allow for testing of the transmitter waveform, transmitter

distortion, transmitter droop and transmitted jitter.

Table 30: Transmitter Test Mode

Test

mode

Mode

0 Normal operation


112

Confidential

1 Test mode 1 – Transmit

Amplitude test

2 Test mode 2 – Transmit droop

test

3 Test mode 2 – Transmit jitter test

4 Test mode 4 – Transmitter

distortion test

5 Reserved

6 Reserved

7 Reserved

Test mode 1 is a mode provided for enabling testing of transmitter Peak differential output voltage and level

accuracy. When test mode 1 is enabled, the PHY shall transmit [+15*ones(1,8), -15*ones(1,8)] continuously

from all four transmitters with the transmitted symbols timed from its local clock source of 500 MHz ± 100ppm.

At 500MSPS - Measure the average amplitude from 10nSec after zero crossing till 14nSec after zero crossing.

An Example of transmitter test mode 1 waveform is shown in Error! Reference source not found..

0 5 10 15 20 25 30-2

-1.5

-1

-0.5

0

0.5

1

1.5

2

time (nS)

Vol

ts

500 MSPS

A - V high

B - V low

Figure 80: Example of transmitter test mode 1 waveform


113

Confidential

Test mode 2 is for transmitter droop testing. When test mode 2 is enabled, the PHY shall transmit

[ +15*ones(1,64), -15*ones(1,64) ] continuously from all four transmitters and with the transmitted symbols

timed from its local clock source of 500 MHz ± 100ppm.

At 500MSPS - Measure the amplitude at 20nSec after zero crossing and at 100nSec after zero crossing.



Test mode 3 is for transmitter jitter testing. When test model 3 is enabled, the PHY shall transmit [+15, -15]

continuously from all four transmitters and with the transmitted symbols timed from its local clock source of

500 MHz ± 100ppm. The transmitter output is a 250 MHz clock signal.



114

Confidential


Test mode 4 is for transmitter distortion testing. When test mode 4 is enabled, the PHY shall transmit the

sequence of symbols generated by the following scrambler generator polynomial, bit generation, and level

mappings:

20171)( xxxg

The bits stored in the shift register delay line at a particular time [n] are denoted by S[19:0]. At each symbol

period the shift register is advanced by 16 bits and a new 16 bit represented by So[15:0] are generated (taken

from each new S[0]). Bits S[16] and S[19] are exclusive OR‟d together to generate the next S[0] bit. The bit

sequences, So[31:0] shall be used to generate the PAM16 symbols to each of the 4 channels (denoted as

SYM_CH0, SYM_CH1, SYM_CH2 and SYM_CH3), as shown in Error! Reference source not found..

At test mode 4 the LFSR circuit will be configured to generate a cyclic pattern every 2^16 symbols (every 2^16

symbol the LFSR will be reset with the initial Seed of 20‟hFFFFF)


115

Confidential

S01 S02 . . . S16S00 S17 S18 S19

+

20171)( xxxG

So0 So1 So2 So3 So4 So5 So6 So7 So8 So9 So10 So11 So12 So13 So14 So15 So16 So17 So18 So19 So20 So21 So22 So23 So24 So25 So26 So27 So28 So29 So30 So31

b0 b1 b2 b3 b0 b1 b2 b3 b0 b1 b2 b3 b0 b1 b2 b3 b0 b1 b2 b3 b0 b1 b2 b3 b0 b1 b2 b3 b0 b1 b2 b3

lsb msb lsb msb lsb msb lsb msb lsb msb lsb msb lsb msb lsb msb

SYM_CH0[n+1] SYM_CH0[n]SYM_CH3[n+1] SYM_CH3[n] SYM_CH2[n+1] SYM_CH2[n] SYM_CH1[n+1] SYM_CH1[n]

Code

[b3……..b0]

Symbol

0000 +15

0001 +13

0011 +11

0010 +9

0110 +7

0111 +5

0101 +3

0100 +1

1100 -1

1101 -3

1111 -5

1110 -7

1010 -9

1011 -11

1001 -13

1000 -15

Figure 83: Distortion scrambler generator polynomial level mapping

The transmitter shall time the transmitted symbols from a 500 MHz ± 100ppm clock.

3.2.3.3 Downstream Test Fixtures

The following fixtures (illustrated by Error! Reference source not found. and Error! Reference source not

found.), or their functional equivalents, shall be used for measuring the transmitter specifications described in

Error! Reference source not found..

Transmitter

Under

Test

50Ω

50Ω

Vd

VA

Digital

Oscilloscope

Post-

ProcessingTX_TCLK

Figure 84: Transmitter test fixture 1

Transmitter

Under

Test

100Ω

VA

Jitter

AnalyzerTX_TCLK



116

Confidential

Table 31: Vd Characteristics

Characteristics Transmit test fixture 1

Waveform Sine Wave

Amplitude 2.5 volts peak-to-peak

Frequency 6.25 MHz

The first role of post-processing block is to remove the disturbing signal (Vd) from the measurement. A method

of removing the disturbing signal is to take a single shot acquisition of the transmitted signal plus test pattern,

then remove the best fit of a sine wave at the fundamental frequency of the disturbing signal from the

measurement. It will be necessary to allow the fitting algorithm to adjust the frequency, phase, and amplitude

parameters of the sine wave to achieve the best fit.

Trigger averaging of the transmitter output to remove measurement noise and increase measurement

resolution is acceptable provided it is done in a manner that does not average out possible distortions caused

by the interaction of the transmitter and the disturbing voltage. Averaging can be done by ensuring the

disturbing signal is exactly synchronous to the test pattern so that the phase of the disturbing signal at any

particular point in the test pattern remains constant. Trigger averaging also requires a triggering event that is

synchronous to the test pattern. A trigger pulse generated by the PHY would be ideal for this purpose;

however, in practice, triggering off the waveform generated by one of the other transmitter outputs that does

not have the disturbing signal present may be possible.

3.2.4 Downstream Transmitter electrical specifications

The transmitter shall provide the Transmit function with the electrical specifications of this clause.

Unless otherwise specified, the transmitter shall meet the requirements of this clause with a 100 Ω resistive

differential load connected to each transmitter output.

The transmitter must be able to tolerate the presence of the remotely driven signal with acceptable distortion

or other changes in performance. From practical considerations, a disturbing sine wave is used to simulate the

presence of a remote transmitter for some transmitter tests described in the following subordinate subclauses


117

Confidential

3.2.4.1 Downstream Transmitter Peak differential output voltage and

level accuracy

With the transmitter in test mode 1 and using the transmitter test fixture 1 The absolute value of the peak of

the waveform at points A and B, as defined in Error! Reference source not found., shall fall within the range

of 0.9 V ± 1.0dB. These measurements are to be made for each pair while operating in test mode 1 and

observing the differential signal output at the MDI using transmitter test fixture 1 with no intervening cable.

The absolute value of the peak of the waveforms at points A and B shall differ by less than 2% from the

average of the absolute values of the peaks of the waveform at points A and B.

3.2.4.2 Downstream Transmitter Maximum output droop

With the transmitter in test mode 2 and using the transmitter test fixture 1, the magnitude of both the positive

and negative droop shall be less than 10%, measured with respect to an initial value at 20 ns after the zero

crossing and a final value at 100 ns after the zero crossing.

3.2.4.3 Downstream Transmitter timing jitter

With the transmitter in test mode 3 and using the transmitter test fixture 2. Measure the jitter of the differential

signal zero crossings relative to an unjittered transmit pattern with the same frequency (Tavg).

The RMS jitter measured shall be less than 6.0 pSec when measured over a time interval of 1ms with the jitter

waveform filtered by a high-pass filter of 100 KHz single pole.

3.2.4.4 Downstream Transmitter distortion

When in test mode 4 and observing the differential signal output using transmitter test fixture 1, for each pair,

with no intervening cable, The peak distortion should better than 0.3 relative to -15,-13, , , +15 Pam16

symbols and a conceptual receiver MSE should be better than -23dB

The peak distortion and MSE is determined by sampling the differential signal output with the symbol rate at

arbitrary phase and processing a block of any 2^16 consecutive samples. The peak and MSE should comply

to the limits for at least half of the UI phases (0.5UI)

3.2.4.5 Downstream Transmitter Power Spectral Density

When in test mode 4 and observing the differential signal output using transmitter test fixture 1, with no

disturbing signal power spectral density of the transmitter, measured into a 100 Ω load shall be between the

upper and lower masks specified in Equation below. The masks are shown graphically in Figure 72


118

Confidential

and

0 0.5 1 1.5 2 2.5 3

x 109

-120

-115

-110

-105

-100

-95

-90

-85

-80

-75Transmitter PSD

Pow

er s

pect

ral d

ensi

ty (dB

m/H

z)

Frequency (MHz)

Figure 86: Transmitter PSD Mask

3.2.4.6 Downstream Transmit clock frequency

The symbol transmission rate on each pair of the Downstream Transmitter shall be 500 MHz or 250 MHz ±

100 ppm.

3.2.5 Downstream Receiver electrical specifications

The receiver shall provide the Receive function in accordance with the electrical specifications of this clause.

3.2.5.1 Downstream Receiver Symbol Error Rate

Differential signals received at the MDI that were transmitted from a remote transmitter within the

specifications of shall comply with the target Symbol Error Rate (SER) as specified in ‎3.2.1


119

Confidential

3.2.5.2 Downstream Receiver frequency tolerance

The receive feature shall properly receive incoming data symbols with rate of 500 MHz or 250 MHz ± 100

ppm.

3.2.5.3 Downstream Common-mode noise rejection

This specification is provided to limit the sensitivity of the receiver to common-mode noise from the cabling

system. Common-mode noise generally results when the cabling system is subjected to electromagnetic

fields.

The common-mode noise can be simulated using a cable clamp test. A 6 dBm sine wave signal from 1 MHz to

500 MHz can be used to simulate an external electromagnetic field

3.3 Upstream Phy

3.3.1 Upstream Physical Coding Sub Layer (PCS)

The main tasks of the Upstream PCS are:

1. Generating modulated symbols with the following properties:

DC Balanced – by using balanced s4d (s4dB).

Evenly spread energy content – by using scrambler.

2. Synchronizing source and sink – by training period.

3. Taking care of cable condition – by swap resolving and alignment resolving.

The PCS interfaces with the Link Layer (see section ‎2.3) on one side and with the Physical Layer on the other

side, as described in the following diagram:


120

Confidential

s

c

r

a

m

b

l

e

r

Upstream

Link Layer

(Sink)

token

mode

12.5 MHz

lane

swap

Swap

ControlData

Align

Upstream

Link Layer

(Source)

D

e

s

c

r

a

m

b

l

e

r

12.5 MHz

token

mode

sync

align

headerPacket Track

PAM

s4dB

Coding

s4dB

Coding

s4dB

Coding

s4dB

Coding

s4dB

Decode

s4dB

Decode

s4dB

Decode

s4dB

DecodeLine

(DSP+PHY)

Source PCS Sink PCS

Token

Control

Figure 87: Upstream - Block Diagram

The Link Layer information (i.e. Control, Status and Ethernet) is presented to/by the PCS in a form of “Token”.

A “Token” can hold different data lengths:

12-bit Data

8-bit Data

4-Bit Data

And it also contains information about its type:

Start Of Packet

Data Payload

End Of Packet

Idle

The “Token” is been scrambled and distributed to the four lanes (A, B, C and D) as described in the following

chapters.

3.3.1.1 Token Control

Tokens are passed by the PCS layer according to three operation modes:

1. Training – In this mode, the header token (of type TokPtpB) contains the value 0 and the rest of the 22

tokens are idle tokes (of type TokIdlB) containing the scrambler's content.


121

Confidential

22 clks

Type

0000Idle Idle

Header

Figure 88: Upstream - Training Packet

2. Idle – In this mode, the header token (of type TokPtpB) contains the value 15 and the rest of the 22

tokens (of type TokIdlB) contain the scrambler's content.

22 clks

Type

1111Idle Idle

Header

Figure 89: Upstream - Ideal Packet

3. Data – In this mode, the header token (of type TokPtpB) contains the packet description (see table 10

in section 2.3.2) and the rest of the 22 tokens are as described in section 2.3.1

22 clks

Type

xxxxdata idle

Header

Figure 90: Upstream - Data Packet

3.3.1.2 Upstream Scrambler / De-Scrambler

The Upstream Scrambler / De-Scrambler implementation is represented using the following bit level diagram.

S18...S0 S1 S2 S19 S57...

+

+

Data In

Scrambled Data Out

12-bit mode

4-bit mode

Mode select

Figure 91: Upstream - Scrambler


122

Confidential

The Upstream scrambler‟s 58 bit seed shall be initialized by the Sink PCS to an arbitrary, non all zero, value.

While in the training period (see ‎0) the de-scrambler is loaded with the scrambler‟s seed by loading the IDLE

content into the de-scrambler. Since IDLE data is 4-bits, the scrambler and de-scrambler advance 4-bits on

each cycle during this training period. When the de-scrambler is considered to be locked (i.e. its content

matches the incoming data), the training period may be aborted and switched to idle period. At the end of the

training period, the scrambler and de-scrambler switch to advance in 12-bits steps per cycle. The transition

between 4-bit steps and 12-bit steps is made at the first token after the next head token, as described in the

following diagrams:

22 clks

Type

0000Idle Idle

Type

1111idle

4 bit mode 12 bit mode

HeaderHeader

Figure 92: Upstream - 4bit to 12bit Scrambler Mode Transition

Training

________

Rotate 4

Zero all

RESET

Wait for new

pkt

________

Rotate 4

Zero all

Header

________

Rotate 4

Zero partial

Normal

________

Rotate 12

Zero partial

Training=1

Training=0Training=1

header

No headerTraining=0

Figure 93: Upstream - Scrambler Modes State Machine


123

Confidential

When at the 12-bit step mode, tokens of less than 12-bits (8-bits tokens and 4-bit tokens) are padded with

zeros at the MSBits.

3.3.1.3 DC Balance

Since HDBaseT links are transformer coupled at both ends, operation at such low symbol rate may cause

significant Baseline Wander (BLW). A Balanced coding (“s4dB”) is used to remove low frequency content from

the Upstream data spectrum to minimize the effect of BLW. DC-Balance is achieved by encoding N-1 bits for

the PAM level and one extra bit to encode the sign of the level, according to the current accumulated DC

(parity). DC Balancing is done per lane so each s4dB symbol should be viewed as if it was separated to 4

parts, one for each lane. Each lane maintains a counter (LaneDContent) which sums up all levels transmitted

so far, on that lane. LaneDContent is initialized to zero and in the first cycle the selected polarity is “-L” where

“L” is the PAM level.

Figure 94: Upstream - DC Balanace Algorithem

3.3.1.4 Upstream Link Tokens to Symbols Modulation

The Token‟s data is distributed to the four lanes (A, B, C and D) and then, the data of each lane is converted

to PAM level (one of 16 possible levels designated by numbers [-15:2:15]). See the following diagrams:

12-bit Token

12-bit tokens are divided to 3-bit per lane data:

if ( LaneDContent(n-1) > 0 )

TransmitLevel(n) = -sign(LaneDContent(n-1))*L

else if(LaneDContent(n-1) < 0 )

TransmitLevel(n) = sign(LaneDContent(n-1))*L

end

LaneDContent(n) = LaneDContent(n-1) + TransmitLevel(n)


124

Confidential

xxxxxxxxxxxx

Lane

D

Lane

C

Lane

B

Lane

A

MSB LSB

Figure 95: Upstream - 12-bits Token Lane Assignment

Each lane data is gray coded to PAM levels where each gray code value has two options that are different

only in their sign for DC balancing:

Figure 96: Upstream - per channel, mapping bits to s4dP16B symbol

8-bit Tokens

8-bit tokens are divided to 2-bit per lane data:


125

Confidential

xxxxxxxx

Lane

DLane

C

Lane

B

Lane

A

MSB LSB





4-bit Tokens

4-bit tokens are divided to one-bit per lane data:

xxxx

AMSB LSB

DCB





126

Confidential

Figure 100: Upstream - per channel, mapping bits to s4dPIB symbol


3.3.1.5 Swap Control

The Upstream PCS transmitter (at the Sink side) receives the swap assignment as was resolved by the

Downstream PCS receiver (at the Sink side also). See sections ‎3.1.3 and ‎3.2.2 for details.

3.3.1.6 Data Alignment

The alignment is resolved during the training period during which the received symbols are of two types only:

s4dPIB and s4dP4B, which have totally different PAM levels:

s4dPIB – [-15, -7, +7, +15]

s4dP4B – [-11, -3, +3, +11]

3.3.1.7 Packet Track

The packets that is transmitted during the training period look like this:


127

Confidential

22 clks

Type

0000Idle Idle

Header

Figure 102: Upstream – Packet Example

Only the “Header” token is coded with s4dP4B symbol and the rest of the “Idle” tokens are coded with s4dPIB

symbols.

Since the length of the transmitted packet does not change, once the “Header” position is found, the position

and types of all the other symbols can be retrieved. This information is used to convert the received PAM

levels into the right s4d symbol type in cases where the same PAM levels can be interpreted as different s4d

symbols like in the following example:

PAM levels [-15,+11,-3,+7] can be interpreted as s4dP16B or as s4dP8B, but if this is the third symbol

after the “Header”, the s4dP16B option should be preferred.

The ending of the training period is designated by:

22 clks

Type

0000Idle Idle

Type

1111idle

Training period Idle period

HeaderHeader

idleType

xxxxdata

data period

Header

data

22 clks 22 clks

Figure 103: Upstream – Packets in Startup Sequence

3.3.2 Upstream Physical Interface tests

3.3.2.1 Upstream Isolation requirement

The PHY shall provide electrical isolation between the port device circuits, including frame ground (if any) and

all MDI leads. This electrical isolation shall withstand at least one of the following electrical strength tests:

a) 1500 V rms at 50 Hz to 60 Hz for 60 s, applied as specified in Section 5.2.2 of IEC 60950-1: 2001.

b) 2250 V dc for 60 s, applied as specified in Section 5.2.2 of IEC 60950-1: 2001.

c) A sequence of ten 2400 V impulses of alternating polarity, applied at intervals of not less than 1s .The

shape of the impulses is 1.2/50 μs (1.2 μs virtual front time, 50 μs virtual time or half value), as defined

in Annex N of IEC 60950-1:2001.


128

Confidential

There shall be no insulation breakdown, as defined in Section 5.2.2 of IEC 60950-1: 2001, during the test. The

resistance after the test shall be at least 2 MΩ, measured at 500 V dc.

3.3.2.2 Upstream Test modes

The test modes described below shall be provided to allow for testing of the transmitter waveform, transmitter

distortion, transmitter droop and transmitted jitter.

Table 32: Transmitter Test Mode

Test

mode

Mode

0 Normal operation

1 Test mode 1 – Transmit

Amplitude test

2 Test mode 2 – Transmit droop

test

3 Test mode 2 – Transmit jitter test

4 Test mode 4 – Transmitter

distortion test

Test mode 1 is a mode provided for enabling testing of transmitter Peak differential output voltage and level

accuracy. When test mode 1 is enabled, the PHY shall transmit [+15*ones(1,4) -15*ones(1,4)] continuously

from all four transmitters with the transmitted symbols timed from its local clock source of 12.5 MHz ± 100ppm.

Test mode 2 is for transmitter droop testing. When test mode 2 is enabled, the PHY shall transmit

[+15*ones(1,128), -15*ones(1,128) ] continuously from all four transmitters and with the transmitted symbols

timed from its local clock source of 12.5 MHz ± 100ppm.

Test mode 3 is for transmitter jitter testing. When test mode 3 is enabled, the PHY shall transmit [+15, -15]

continuously from all four transmitters and with the transmitted symbols timed from its local clock source of

12.5 MHz ± 100ppm. The transmitter output is a 6.25 MHz signal.

Test mode 4 is for transmitter distortion testing. When test mode 4 is enabled, the PHY shall transmit the

sequence of symbols generated by the following scrambler generator polynomial, bit generation, and level

mappings:


129

Confidential

20171)( xxxg

The bits stored in the shift register delay line at a particular time [n] are denoted by S[19:0]. At each symbol

period the shift register is advanced by 16 bits and a new 16 bit represented by So[15:0] are generated (taken

from each new S[0]). Bits S[16] and S[19] are exclusive OR‟d together to generate the next S[0] bit. The bit

sequences, So[15:0] shall be used to generate the PAM16 symbols to each of the 4 channels (denoted as

SYM_CH0, SYM_CH1, SYM_CH2 and SYM_CH3), as shown in Error! Reference source not found..

Figure 104: Distortion scrambler generator polynomial level mapping

The transmitter shall time the transmitted symbols from a 12.5 MHz ± 100ppm clock.

A typical transmitter output for transmitter test mode 4 is shown in Error! Reference source not found..

3.3.2.3 Upstream Test Fixtures

The following fixtures (illustrated by Error! Reference source not found. and Error! Reference source not

found.), or their functional equivalents, shall be used for measuring the transmitter specifications described in



130

Confidential

Transmitter

Under

Test

50Ω

50Ω

Vd

VA

Digital

Oscilloscope

Post-

ProcessingTX_TCLK


Transmitter

Under

Test

100Ω

VA

Jitter

AnalyzerTX_TCLK


Table 33: Vd Characteristics

Characteristics Transmit test fixture 1

Waveform Sine Wave

Amplitude 5.00 volts peak-to-peak

Frequency 50 MHz

The first role of post-processing block is to remove the disturbing signal (Vd) from the measurement. A method

of removing the disturbing signal is to take a single shot acquisition of the transmitted signal plus test pattern,

then remove the best fit of a sine wave at the fundamental frequency of the disturbing signal from the

measurement. It will be necessary to allow the fitting algorithm to adjust the frequency, phase, and amplitude

parameters of the sine wave to achieve the best fit.

The second role of the post-processing block is to compare the measured data with the droop specification, or

distortion specification.


131

Confidential

Trigger averaging of the transmitter output to remove measurement noise and increase measurement

resolution is acceptable provided it is done in a manner that does not average out possible distortions caused

by the interaction of the transmitter and the disturbing voltage. For transmitter template and droop

measurements, averaging can be done by ensuring the disturbing signal is exactly synchronous to the test

pattern so that the phase of the disturbing signal at any particular point in the test pattern remains constant.

Trigger averaging also requires a triggering event that is synchronous to the test pattern. A trigger pulse

generated by the PHY would be ideal for this purpose; however, in practice, triggering off the waveform

generated by one of the other transmitter outputs that does not have the disturbing signal present may be

possible.

3.3.3 Upstream Transmitter electrical specifications




The transmitter must be able to tolerate the presence of the remotely driven signal with acceptable distortion

or other changes in performance. From practical considerations, a disturbing sine wave is used to simulate the

presence of a remote transmitter for some transmitter tests described in the following subordinate subclauses

3.3.3.1 Upstream Transmitter Peak differential output voltage and level

accuracy

With the transmitter in test mode 2 and using the transmitter test fixture 1 The absolute value of the peak of

the waveform at points A and B, as defined in Error! Reference source not found., shall fall within the range

of 0.20 V to 0.5 V. These measurements are to be made for each pair while operating in test mode 1 and

observing the differential signal output at the MDI using transmitter test fixture 1 with no intervening cable.

The absolute value of the peak of the waveforms at points A and B shall differ by less than 2% from the

average of the absolute values of the peaks of the waveform at points A and B.

3.3.3.2 Upstream Transmitter Maximum output droop

With the transmitter in test mode 2 and using the transmitter test fixture 1, the magnitude of both the positive

and negative droop shall be less than 10%, measured with respect to an initial value at 10 ns after the zero

crossing and a final value at 90 ns after the zero crossing.


132

Confidential

3.3.3.3 Upstream Transmitter timing jitter

With the transmitter in test mode 3 and using the transmitter test fixture 2. Measure the jitter of the differential

signal zero crossings relative to an un-jittered transmit pattern with the same frequency (Tavg).

The RMS jitter measured shall be less than X ps when measured over a time interval of 1ms with the jitter

waveform filtered by a high-pass filter of 100 KHz single pole.

3.3.3.4 Upstream Transmitter distortion

3.3.3.5 Upstream Transmitter Power Spectral Density

3.3.3.6 Upstream Transmit clock frequency

The symbol transmission rate on each pair of the Upstream Transmitter shall be 12.5 MHz ± 100 ppm.

3.3.4 Upstream Receiver electrical specifications


3.3.4.1 Upstream Receiver differential input signals


specifications of shall comply with the target Symbol Error Rate (SER) as specified in ‎3.2.1

3.3.4.2 Upstream Receiver frequency tolerance

The receive feature shall properly receive incoming data symbols with rate of 12.5 MHz ± 100 ppm.

3.3.4.3 Upstream Common-mode noise rejection



fields.




133

Confidential

3.4 Active Mode Startup

The bi-directional physical link between the source and the sink is established by utilizing a series of

transmission types starting from no transmission (silence), followed by transmission in training mode, idle

mode and eventually data mode. A successful startup sequence shall always consist of transmission in the

described order (silence followed by a training transmission, idle transmission, and finally data transmission).

Transmission shall be continuous without any gaps in the transition between different transmission types

(except for silence, of course). If any of the sides detects a failure during the sequence it shall revert back to

the beginning of the sequence (silence) to start the sequence again.

A diagram of the startup sequence is shown in Error! Reference source not found. for the source and sink

together. A successful startup sequence initiates with both Downstream and Upstream transmitters off. The

source then starts transmitting in downstream training mode, answered by the sink transmitting in upstream

training mode, then in upstream idle mode, to which the source responds by transmitting in downstream idle

mode. The sink finally starts transmitting in upstream data mode, followed by the source transmission of

downstream data mode, at which stage normal operation mode is achieved.

SILENT

SILENT

TRAINING IDLE DATA

TRAINING IDLE DATA

STARTUP NORMAL

SO

UR

CE

TX (DOWNSTREAM)

ECHO

CHANNEL (UPSTREAM)

LANE ALIGN

TX (UPSTREAM)

CHANNEL (DOWNSTREAM)

ECHO

LANE ALIGN

LANE SWAP RESOLVE,

DESCRAMBLER SYNC

DESCRAMBLER SYNC

SIN

K

“MODE”

Figure 107: Startup Sequence Diagram

3.4.1 Downstream Link Startup Transmission Types

In order to establish the physical downstream link the downstream TX shall go through a sequence utilizing

different transmission types: silent, training, idle and data.

3.4.1.1 Downstream Silent Mode

During this period the downlink is silent (no transmission).

3.4.1.2 Downstream Training Mode

During this period the transmitter shall transmits S4dP2 and S4dP2A symbols as described in ‎3.2.2.2.


134

Confidential

3.4.1.3 Downstream Idle Mode

During this period the transmitter shall transmits S4dPI symbols as described in ‎3.2.2.3

3.4.1.4 Downstream Data Period

During this period the transmitter shall transmits downstream packets provided by the downstream link as

described in ‎2.2.1.

3.4.2 Upstream Link Startup Transmission Types

3.4.2.1 Upstream Silent Mode

During this period the downlink is silent (no transmission).

3.4.2.2 Upstream Training Mode

During this period the transmitter shall transmits packets containing a header token of type 0, followed by 22

idle tokens, as described in ‎3.3.1.1. During this period the scrambler advances 4 bits per cycle as described in

‎3.3.1.2.

3.4.2.3 Upstream Idle Mode

During this period the transmitter transmits packets containing a header token of type 15, followed by 22 idle

tokens, as described in ‎3.3.1.1. After the first header is transmitted the scrambler transits to 12 bits per cycle

operation, instead of 4, as described in ‎3.3.1.2.

3.4.2.4 Upstream Data Mode

During this period the transmitter transmits packets containing a header token of type 1 to 14, followed by 22

tokens, as described in ‎2.3.1.


135

Confidential

SRC1. Detect US Inactivity

DS_TX = OFF

SRC3. Solve Echo

DS_TX = TRAINING

us_inactive

SRC5. Solve Upstream Channel,

Lock Descrambler

and Wait for IDLE

Solve channel, timing

Align lanes, lock descrambler

DS_TX = TRAINING

SRC6. Wait for DATA

DS_TX = IDLE

SRC7. DATA

DS_TX = DATA

SOURCE

(Downstream TX, Upstream RX)

SINK

(Downstream RX, Upstream TX)

SNK1. Detect Activity

US_TX = OFF

SNK3. Solve Downstream Channel and

Lock Descrambler

Solve channel, timing, FEXT

Align lanes, solve lane swap and polarity,

lock descrambler

US_TX = OFF

ds_active

SNK4. Solve Echo and Verify

Descrambler Lock

US_TX = TRAINING

SNK5. Wait for IDLE

US_TX = IDLE

SNK7. DATA

US_TX = DATA

ds_idle_detected

SNK0. Init

US_TX = OFF

SRC0. Init

DS_TX = OFF

src0_timer_done

snk0_timer_done

SRC2. Partner Error

DS_TX = OFF

us_inactive

SRC4. Detect Activity

DS_TX = TRAINING

src3_timer_done +

us_quality_good

src4_timer_done

src3_timer_done and

!us_quality_good

us_active

us_descrambler_locked *

us_idle_detected

us_signal_loss +

us_quality_bad +

!us_descrambler_locked +

src6_timer_done

us_signal_loss +

us_quality_bad +

!us_scrambler_locked

us_data_detected

src1_timer_done

snk3_min_timer_done *

ds_quality_good *

ds_descrambler_locked

ds_signal_loss +

ds_quality_bad +

snk3_max_timer_done

snk4_min_timer_done *

ds_quality_good *

ds_descrambler_locked

ds_signal_loss +

ds_quality_bad +

snk4_max_timer_done

ds_signal_loss +

ds_quality_bad +

!ds_scrambler_locked +

snk5_timer_done

ds_signal_loss +

ds_quality_bad +

!ds_scrambler_locked

SNK2. No Partner

US_TX = OFF

snk1_timer_done

ds_active

us_signal_loss +

us_quality_bad +

(src5_min_timer_done *

!us_descrambler_locked) +

src5_max_timer_done

SNK6. Wait for DATA

US_TX = DATA

ds_data_detected

ds_signal_loss +

ds_quality_bad +

!ds_scrambler_locked +

snk6_timer_done

Figure 108: Link Startup State Machines


136

Confidential

3.4.3 SINK (Downstream RX, Upstream TX) Startup State Machine

The startup state machine for both sink and source are shown together in Error! Reference source not found..

3.4.3.1 Indications

Timer Indications

The following indications are used to measure time spent in various states. The timer values are shown in


snk0_timer_done – indicates that at least snk0_timer_val msecs have passed since entering state SNK0.


snk3_min_timer_done – indicates that at least snk3_min_timer_val msecs have passed since entering

state SNK3.

snk3_min_timer_done – indicates that at least snk3_max_timer_val msecs have passed since entering

state SNK3.

snk4_min_timer_done – indicates that at least snk4_min_timer_val msecs have passed since entering

state SNK4.

snk4_min_timer_done – indicates that at least snk4_max_timer_val msecs have passed since entering

state SNK4.



Activity Indications

The following indications are used to report presence or loss of signal at the receiver.

ds_active – indicates that the receiver identifies activity on the DS (e.g. power measurement).

ds_signal_loss – indicates that the receiver identifies the loss of DS signal (e.g. by loss of power).

Link Quality Indications

The following indications are used to monitor signal quality:

ds_quality_good – indicates that the signal quality (measured by SNR for example) is sufficient.

ds_quality_bad – indicates that the signal quality (measured by SNR or CRC errors for example) is bad.

The criteria used for these indications differ between and during states. Link quality shall not simultaneously

be good and bad, but it may be neither.

“Data Integrity” Indications

The following indications are used to monitor the data received.


137

Confidential

ds_descrambler_locked – indicates that the descrambler is locked, see ‎3.2.2.1.

ds_idle_detected – indicates that downstream idle transmission is detected (e.g. by the descrambler locking

in idle mode).

ds_data_detected – indicates that downstream data transmission is detected (e.g. by reception of video,

Ethernet or control packets, see ??????).

Table 34: Sink State Machine Timer Values

Value

[msecs]

Description

snk0_timer_val 4 Time from startup initiation until sink

begins to listen for DS activity

snk1_timer_val 10 If DS activity is not detected during this

time, no partner is declared

snk3_min_timer_val 100 The minimal time from DS activity

detection to start of US transmission

snk3_max_timer_val 600 The time allowed from DS activity

detection to solve channel and achieve

descrambler lock

snk4_min_timer_val 100 The minimal time from start of US

(training) transmission to transition to

US idle transmission

snk4_max_timer_val 200 The time allowed from start of US

transmission to solve echo

interference and re-achieve

descrambler lock

snk5_timer_val 1 The maximal time allowed from start of

US idle transmission to reception of

DS idle transmission

snk6_timer_val 10 The maximal time allowed from start of

US data transmission to reception of

DS data transmission

3.4.3.2 States

SNK0. Init

During this state the downstream receiver performs initialization; the receiver shall remain in this state until

snk0_timer_done is indicated.

During this state the upstream TX shall be silent.


138

Confidential

SNK1. Detect Activity

During this state the receiver monitors the downstream link and detects the start of transmission by the

downstream TX. The receiver shall proceed to the SNK3 state upon activity detection (ds_active indication).

If snk1_timer_done is indicated before no downstream activity is detected the receiver shall transit to the

SNK2 state.


SNK2. No Partner

This state indicates that the receiver did not detect a source transmitting on the downstream. The receiver

shall proceed to the SNK3 state if downstream activity is detected (ds_active).


SNK3. Solve Downstream Channel and Lock Descrambler

During this state it is assumed that the downstream TX transmits in training mode.

In this state the receiver shall perform the necessary operations required to receive the downstream

transmitted symbols in each of the four lanes. This may include gain control, symbol synchronization, channel

equalization, etc. The receiver shall then align the downstream lanes, using the S4dP2A symbols present in

the downstream training transmission, solve the lane polarity and swap, which may be arbitrary as described

in ‎3.2.2.2. A successful solution shall result in a stable lock of the downstream descrambler in training mode.

The receiver shall proceed to the SNK4 state when snk3_min_timer_done is indicated, a good enough

solution of the channel is achieved (indicated by ds_quality_good), and the descrambler is locked

(ds_descrambler_locked). If anytime during this state the receiver senses loss of signal (ds_signal_loss),

bad channel quality (ds_quality_bad) or if snk3_max_timer_done is indicated it shall restart startup.

During this state the upstream TX shall remain silent.

SNK4. Solve Echo and Verify Descrambler Lock

Upon entering this state the upstream TX shall start transmitting in Training mode.

The resulting echo interference may cause degradation in the channel quality, and the receiver shall perform

the necessary operations required to receive the downstream transmitted symbols in the presence of

upstream transmission, e.g. echo cancellation. A successful solution shall result in a stable lock of the

downstream descrambler in training mode.

The receiver shall proceed to the SNK5 state when snk4_min_timer_done is indicated, a good enough

solution of the channel is achieved (indicated by ds_quality_good), and the descrambler is locked

(ds_descrambler_locked). If anytime during this state the receiver senses loss of signal (ds_signal_loss),

bad channel quality (ds_quality_bad) or if snk4_max_timer_done is indicated it shall restart startup.

SNK5. Wait for IDLE

Upon entering this state the upstream TX shall transit to transmission in IDLE mode.


139

Confidential

The receiver shall proceed to the next state when IDLE downlink transmission is detected

(ds_idle_detected). If anytime during this state the received power drops off (ds_signal_loss indication) or

the quality of the signal is lower than expected (ds_quality_bad) or descrambler locking is lost or if

downstream idle transmission is not detected prior to snk5_timer_done being indicated, then the receiver

shall restart the startup procedure.

SNK6. Wait for DATA

Upon entering this state the upstream TX shall transit to transmission in DATA mode (normal operation).

The receiver shall proceed to the next state when DATA downlink transmission is detected

(ds_data_detected). If anytime during this state the received power drops off (ds_signal_loss indication) or

the quality of the signal is lower than expected (ds_quality_bad) or descrambler locking is lost or if

downstream idle transmission is not detected prior to snk6_timer_done being indicated, then the receiver


SNK7. DATA

This is the normal operation state.

If anytime during this state the received power drops off (ds_signal_loss indication) or the quality of the

signal is lower than expected (ds_quality_bad) or descrambler locking is lost, the receiver will restart the

startup procedure.

3.4.4 SOURCE (Upstream RX, Downstream TX) Startup State Machine

The startup state machine for both source and sink are shown together in Error! Reference source not found..

3.4.4.1 Indications

Timer Indications

The following indications are used to measure time spent in various states.

src0_timer_done – indicates that at least src0_timer_val msecs have passed since entering state SRC0.




src5_min_timer_done – indicates that at least src5_min_timer_val msecs have passed since entering state

SRC5.

src5_max_timer_done – indicates that at least src5_max_timer_val msecs have passed since entering

state SRC5.


Activity Indications


140

Confidential

The following indications are used to report presence or loss of signal at the receiver.

us_inactive – indicates that the receiver identifies no activity on the US (e.g. power measurement).

us_active – indicates that the receiver identifies activity on the US (e.g. power measurement).

us_signal_loss – indicates that the receiver identifies the loss of US signal (e.g. by loss of power).

Link Quality Indications

The following indications are used to monitor signal quality:

us_quality_good – indicates that the signal quality (measured by SNR or MSE for example) is sufficient.

us_quality_bad – indicates that the signal quality (measured by SNR or MSE for example) is bad.

The criteria used for these indications differ between and during states. Link quality cannot be simultaneously

both good and bad, but it may be neither.

“Data Integrity” Indications

The following indications are used to monitor the data received.

us_scrambler_locked – indicates that the descrambler is locked, see clause ….

us_idle_detected – indicates that upstream idle transmission is detected (e.g. by the descrambler locking in

idle mode).

us_data_detected – indicates that upstream data transmission is detected (e.g. by PCS).

3.4.4.2 States

SRC0. Init

During this state the upstream receiver shall perform initialization; the receiver shall remain in this state until

snk0_timer_done is indicated.

During this state the downstream TX shall be silent.

SRC1. Detect US Inactivity

During this state the receiver shall monitor the downstream link and wait for DS transmission to stop. The

receiver shall proceed to the SRC3 state upon inactivity detection (us_inactive indication). If the receiver fails

to detect upstream inactivity until src1_timer_done is indicated it shall proceed to the SRC2 state.

During this state the downstream TX shall remain silent.

SRC2. Partner Error

This state indicates that the receiver did not detect upstream inactivity as expected from a valid sink partner.

The receiver shall proceed to the SRC3 state if upstream inactivity is detected (us_inactive).



141

Confidential

SRC3. Solve Echo

Upon entering this state the downstream TX shall start transmitting in Training mode.

In this state the receiver shall perform the necessary operations required to operate in the presence of the

echo interference once upstream transmission commences (in later stages), e.g. echo cancellation.

The receiver shall proceed to the SRC4 state when src3_timer_done is indicated and a good enough

solution of the channel is achieved (indicated by us_quality_good). If src3_timer_done is indicated and the

solution is not good enough, the receiver shall restart startup.

SRC4. Detect Activity

The receiver shall proceed to the SRC5 state when it detects the start of upstream transmission. If the

receiver fails to detect upstream activity by the time src4_timer_done is indicated then it will restart startup.

During this state the downstream TX shall remain in training mode.

SRC5. Solve Upstream Channel, Lock Descrambler and Wait for

IDLE

During this state it is assumed that the upstream TX transmits in training mode and transits to idle mode.

In this state the receiver shall perform the necessary operations required to receive the upstream transmitted

symbols in each of the four lanes. This may include gain control, symbol synchronization, channel

equalization, etc. The receiver shall then align the lanes, by using the header symbols present in the upstream

training transmission. It is guaranteed that the lanes are not swapped, since swap was already solved at the

downstream RX and this information was used to swap the lanes appropriately at the upstream TX.

Successful operation will result in a successful and stable lock of the upstream descrambler in training mode.

The receiver shall proceed to the SRC6 state when the descrambler is locked (us_descrambler_locked) and

IDLE uplink transmission is detected (us_idle_detected). If anytime during this state the received power

drops off (us_signal_loss indication) or the quality of the signal is lower than expected (us_quality_bad) or if

descrambler locking is not achieved by the time src5_min_timer_done is indicated, or if

src5_max_timer_done is indicated then the receiver will restart the startup procedure.

During this state the downstream TX shall remain in training mode.

SRC6. Wait for DATA

Upon entering this state the downstream TX shall transit to Idle mode.

The receiver shall proceed to the SRC7 state when upstream data transmission is detected

(us_data_detected). If anytime during this state the received power drops off (us_signal_loss indication) or

the quality of the signal is lower than expected (us_quality_bad) or descrambler locking is lost or if

downstream data transmission is not detected priod to src6_timer_done being indicated, then the receiver


SRC7. DATA

Upon entering this state the downstream TX shall transit to data mode (normal operation).


142

Confidential

This is the normal operation state.

If anytime during this state the received power drops off (us_signal_loss indication) or the quality of the

signal is lower than expected (us_quality_bad) or descrambler locking is lost, the receiver will restart the

startup procedure.

Table 35: Source State Machine Timer Values

Value

[msecs]

Description

src0_timer_val 1 The minimal time Source TX is silent

during startup

src1_timer_val 10 If US silence is not detected during

this time, no partner is declared

src3_timer_val 90 The time allowed to solve echo and

be ready for US transmission

src4_timer_val 520 The maximal expected time for start

of US transmission

src5_min_timer_val 95 The time allowed to solve the

upstream channel and lock

descrambler

src5_max_timer_val 210 The maximal expected time for

transition from US training

transmission to US idle transmission

src6_timer_val 1 The maximal time allowed from start

of DS idle transmission to reception

of US data transmission

3.5 HDBaseT Stand By mode Interface (HDSBI) Phy

3.5.1 HDSBI General

HDBaseT Stand By mode Interface (HDSBI) is design for a very low power bi-directional, full duplex, high

quality communication channel operating over two pairs of the Cat5e/6/6a cable


143

Confidential

HDBaseT

Source

HDBaseT

SinkHDSBI

AB

C

D

AB

C

D

Figure 109: HDSBI Operation Over C&D pairs

3.5.2 HDSBI Design for Low Power

Operates over a single pair in each direction

Using self clocked Manchester II encoding

Operates at 2 x Symbol Rate

One Symbol

Period

Middle

Transition

Between Symbols

Transition

Figure 110: HDSBI Manchaster II encoding

Operates at ~3.9Msymbols/sec (125M/32)

TX amplitude is 500mV peak to peak differential

Burst communication - active only during data transactions

3.5.3 HDSBI Physical Coding Sub-Layer (PCS)

The HDSBI PCS receives the following inputs from the link layer at the symbol rate of 3.90625MHz:

tx_active (1 bit) – indicates that the HDSBI TX is active

tx_mode (1 bit) – 0 = IDLE, 1 = DATA

tx_del (1 bit) – 0 = Manchester II symbol, 1 = delimiter


144

Confidential

tx_bit (1 bit) – if tx_del is 0 it is the data bit to be encoded, if tx_del is 1 indicates the

polarity of the delimiter.

HDSMI

Link

Layer

LFSR

0

tx_bit

tx_mode

Symbol

Generator

0

1

tx_del

TX

tx_active

to line

PCS

Scrambler

Figure 111: HDSBI PCS

When tx_active is 0, the transmission shall be 0, and the PCS output does not matter.

Otherwise, when tx_del is 1 the Symbol Generator shall transmit a delimiter according to the tx_bit value.

When tx_del is 0 the Symbol Generator shall transmit a Manchester II encoded symbol as follows. If tx_mode

is 0 (Idle transmission), then the scrambler LFSR output is Manchester II encoded, otherwise the tx_bit value

is xored with the scrambler LFSR output and the result is Manchester II encoded.

3.5.3.1 HDSBI Symbol Generator

An HDSBI symbol may be a Manchester II encoded symbols or a delimiter symbol as indicated by the link

tx_del signal (0=MAN2, 1=delimiter).

Each Manchester II symbol contains a middle transition and encodes a single bit. A bit of „1‟ shall be encoded

using a transition from V to –V, while a bit of „0‟ shall be encoded using a transition from –V to V, as seen in

Figure 112. Manchester II symbols are DC-balanced.


145

Confidential

1

Man II encoded symbols

Symbol Clock

0 1 1 0 0 0 0

+V

-V

0 1 1 0Packet start Packet end

Figure 112: The two types of HDSBI Symbols

Delimiter symbols serve to indicate packet start and end and do not contain inter-symbol transitions. A „1‟

delimiter shall be encoded as a constant +V signal for the duration of a symbol. A „0‟ delimiter shall be

encoded as a –V signal for the duration of a symbol. A packet start is indicated by the link as two „1‟ (+V)

delimiters followed by two „0‟ (-V) delimiters. A packet end is indicated by the link as two „0‟ (-V) delimiters

followed by two „1‟ (+V) delimiters.

3.5.3.2 HDSMI Scrambler LFSR

The HDSMI Scrambler LFSR shall be implemented using the following LFSR:

S0 S1 ... S8 S9 S10

Scrambler

output

Figure 113: HDSBI Scrambler LFSR

The scrambler‟s 11 bit seed shall be initialized to an arbitrary, non all zero, value. The scrambler shall

advance once every symbol when tx_active is asserted. The scrambler may or may not advance when

tx_active is not asserted.

3.5.4 HDSBI Transmitter electrical specifications




3.5.4.1 HDSBI Transmitter Output Waveform Mask

With the transmitter in HDSBI mode and using the transmitter test fixture 1, the output waveform shall fall

within the template shown in Error! Reference source not found..


146

Confidential

Figure 114: HDSBI Transmitter Mask

3.5.4.2 HDSBI Transmit Clock Frequency

The symbol transmission rate on each pair of the HDSBI Transmitter shall be 3.90625 MHz ± 1000 ppm.

3.5.4.3 HDSBI Common-mode output voltage

The magnitude of the total common-mode output voltage of the transmitter shall be less than 50 mV peak.

3.5.5 HDSBI Receiver electrical specifications


3.5.5.1 HDSBI Receiver Symbol Error Rate


specifications shall comply with the target Symbol Error Rate (SER) of 10^-15

3.5.5.2 HDSBI Receiver frequency tolerance

The receive feature shall properly receive incoming data symbols with rate of 3.90625 MHz ± 1000 ppm.

(125 MHZ / 32)


147

Confidential

3.5.5.3 HDSBI Common-mode noise rejection



fields.




148

Confidential

4 HDBaseT Link Control and Management

4.1 General

Control and Management of HDBaseT devices are done using the following:

Each HDBaseT Device shall maintain an HDBaseT Configuration Database (HDCD),as described in

section ‎4.2, comprising configuration and status entities of that device. Other HDBaseT devices and

control points can access the HDCD of a certain HDBaseT device to retrieve information regarding its configuration and status.

Each HDBaseT Device shall provide access to its HDCD using HDBaseT Link Internal Controls

(HLIC) as described in secion ‎4.3. HLIC shall be supported over the HDBaseT Downstream sublink,

as described in section INSERTCROSS, Upstream sublink as described in section INSERTCROSS, and over the HDSBI link as described in section INSERTCROSS. HDBaseT switching devices shall additionally support HLIC access over the Ethernet network, using HD-CMP encapsulation.

4.2 HDBaseT Configuration Database (HDCD)

Each HDBaseT Device shall maintain an HDBaseT Configuration Database (HDCD), comprising

configuration and status entities of that device.

Each HDCD entity is represented by:

Entity ID – 16 bits which provides a unique identifier of that entity

Entity Value – A variable length octets sequence (1 to 255) which holds the value of that entity

Per Entity ID the HDCD defines the Read/Write ability of that Entity and the way how to interpret the octets

sequence holding the value of that entity.

Entities in the HDCD are organized according to the prefix of their Entity ID:

Device Entities - Entities with ID in the range of 0x0000 to 0x03FF (6 MSBs are zero)

Port Entities – Entities with ID in range 0x0400 to 0x04FF

HDBaseT Chip Vendor Specific Entities – Entities with ID in the range 0xB000 to 0xBFFF

CE Vendor Specific Entities – Entities with ID in the range 0xC000 to 0xCFFF

The port entities are related to the port in question (“current port”) there are no duplications of entity IDs per

port in the device. In order to retrieve/set information regarding port entities the requestor shall provide port ID

as a parameter to the query.

An HDBaseT device shall support all HDCD Device Entities as defined in the following table:


149

Confidential

Entity ID Definition Value

length

(octets)

Read /

Write

Remark

0x0000 Reserved for Error ELV indication see ‎4.2.1.1

0x0001 HDCD Version:

0x10 – Comply with spec 1.0

1 RO

0x0002 IEEE OUI 3 RO

0x0003 Device Description String Up to 255 RO

0x0004 Device Model ID 4 RO

0x0005 Device Ethernet MAC Unique Identifier

Use to access this device for managment

6 RO If not supported shall be all

zero

0x0006 Device UUID:

A unique device identifier used as a linkage to

uPnP/DLNA network view

According to uuid rfc 4122, a universally unique

identifier (uuid) urn namespace, July 2005

16 RO If not supported shall be all

zero (NIL UUID)

0x0007 HDBaseT Ports Number:

The number of HDBaseT ports in this device

1 RO

Table 36: HDCD Device Entities

Entity

ID

Definition Value

length

(octets)

Read

/

Write

Remark

0x0400 Port ID:

The ID of this port

within the device

0x0000 - Unknown

0x0001 to 0xFFFF –

2 RO 16 bits port

identifier in

accordance

with IEEE

801.1D-2004


150

Confidential

valid IDs MSByte is

transferred

first

0x0401 Port HDBaseT Spec

Compliancy:

0x10 – Comply with spec 1.0

1 RO

0x0402 Port Type Capability:

0x01 – End Node Source Only

0x02 – End Node Sink Only

1 RO

0x0403 Port Active Type:

0x00 – Reserved

0x01 – End Node Source Only

0x02 – End Node Sink Only

1 RO

0x0404 Number Of AV Stream

Supported

1 RO

0x0405 Max Active Mode

Supported:

0x01 – 250M PAM16

0x02 – 500M PAM16

1 RO

0x0406 Current Operation

Mode:

0x00 – Partner Detect

0x01 - 100BaseT Fallback

0x02 - LPPF #1

0x03 - LPPF #2

0x04 – 250M PAM16

0x05 – 500M PAM16

1 RO

0x0407 Data Type

Termination:

Each bit represent

support for a certain

data type to be

terminated over this

HDBaseT port

2 RO MSByte is

transferred

first


151

Confidential

Bit 0 – DVI

Bit 1 – HDMI

Bit 3 – CEC

Bit 4 – Ethernet

Bit 5 to 15 – Reserved

and shall be zero

0x0408 CEC Device Types:

Preferred CEC device

types, encoded as in

CEC, of the device

operating through this

port. Several CEC

device types may be

specify.

Each octet represent

one type therefore the

length field will

determine the number

of supported types

0xFF – Represent Not

Known

0xFE – Represent Not

Supported

1 to 8 RO The most

preferred type

is

represented

by the first

transferred

octet

0x0409 CEC Logical Address:

Preferred CEC logical

addresses, encoded

as in CEC, of the

device operating

through this port.

Several CEC logical

addresses may be

specify.

Each octet represent

one address therefore

the length field will

determine the number

1 to 8 RO The most

preferred

address is

represented

by the first

transferred

octet


152

Confidential

of addresses

0xFF – Represent Not

Known

0xFE – Represent Not

Supported

0x040A Port Ethernet MAC

address

6 RO If not

supported

shall be all

zero

Table 37: HDCD Port Entities

4.2.1 ELV Structure

When HDCD entities are exchanged between HDBaseT device, each entity shall be sent using the following

(Entity ID, Entity Value Length in octets, Value) ELV structure:

Entity ID Length

…

Value

Figure 115: ELV Structure

Entity ID – 16 bits which provides a unique identifier of that entity

Entity Value Length – The number (1 to 255) of octets in which the entity value is represented

Entity Value – A variable length octet sequence (1 to 255) which holds the value of that entity. MSB octet is transferred first.


153

Confidential

Since only ID and Value are exchanged between the devices, the device which retrieve the entity ELV shall

parse the Value octet sequence according to it‟s a-priory knowledge about this Entity (using its Entity ID).

4.2.1.1 Error ELV

In case of an error in the process of retrieving information regarding a certain Entity ID a special error ELV

with the following format shall be use:

Entity ID Length Value

00 4

Original Entity ID Error Code

Figure 116: Error ELV Format

Entity ID – Zero

Length – At least 4 octets

Value – first two octets in the Value field represent the original requested Entity ID and the following

two octets encodes the error

The following error codes are defined:


154

Confidential

Table 38: ELV Error Codes

4.3 HDBaseT Link Internal Controls (HLIC)

Error

Code

Name Description

0 Unknown

1 ID Not

Supported

The requested Entity ID is not supported by the

responder HDCD

2 ID Not

Supported

In This

Mode

ID is not supported in this operation mode

3 ID Not

Ready

ID is supported but value is not ready

4 to

100

Reserved

101 Read

Only

Entity is read only

102 Format

Mismatch

Entity value to write does not match current HDCD

definition

103 to

1000

Reserved

1001 Range

Not

Supported

The requested Entities Range is not supported by the

responder HDCD

1002 Range

Not

Supported

In This

Mode

Range is not supported in this operation mode

1003 Range

Not

Ready

Range is supported but values are not ready


155

Confidential

4.3.1 HLIC General

HLIC transactions are used by an HDBaseT device (The Initiator) in order to access HDCD of a directly attach

other HDBaseT device (The Responder) and provide means to control the HDBaseT link which connect these

two devices.

HLIC transaction to non directly attach device are possible only when encapsulated over HD-CMP and

transfer over the Ethernet network to the target device or to a device which is directly attach to the target

device, which converts the non direct HLIC to Direct HLIC.

An HDBaseT device shall support Direct HLIC transactions on each one of its HDBaseT ports, at each

operation mode of these ports.

HLIC transaction comprises a Request HLIC packet initiate by the Initiator and followed by one or more Reply

packets sent by the Responder. Each HDBaseT device on both sides of the link may be the Initiator of a

transaction, such that both downstream and upstream transactions may be active over the same link at the

same time. After sending a Request packet, each Initiator shall first complete or abort a certain HLIC

transaction before it can send additional Request packet for the next transaction towards the same HDBaseT

port.

Each HLIC packet is using CRC32 to insure the data integrity of the received packets. When a Responder

receives a bad CRC Request packet it shall reply with No Ack packet as specified in section ‎4.3.7.2 and

ignore this request. When the Initiator receives a bad CRC Reply packet it shall ignore this Reply packet. In

order to abort an active transaction, the Initiator may send Abort Request as specified in section ‎4.3.7‎4.3.7.1,

to which the Responder shall respond with Abort Reply. The Responder may initiate Abort Reply to signal the

Initiator it wishes to abort the transaction, the Initiator shall not respond to that Abort Reply.

The Responder shall consider a newly received non Abort Request as an Abort to the current transaction, if

exists, and shall not respond with Abort Reply. The Responder shall execute the newly received request as a

normal request.

The time difference between the reception of a request to the transmission of the first reply and the time

difference between the transmissions of a reply to the transmission of the next reply, in the same transaction,

shall not exceed 1 second.

4.3.2 HLIC Packet Format

The following figure describes the HLIC Packet Format:


156

Confidential

…

CRC32Length Op Code Payload (1 to 511 bytes)

Request

/ Reply

Flag

Figure 117: HLIC Packet Format

Op Code – HLIC Operation Code 6 bits (0 to 63)

Req/Rep Flag – A single bit field if zero it is a Request packet and if one it is a Response

Length – The payload length in octets

Payload – An octet sequence carrying the payload of this packet and its format depends on the Op

Code Field

CRC32 – A 32 bits CRC field which is calculated starting from the Op Code octet up to the last

Payload octet, insuring the packet‟s data integrity

4.3.3 HLIC Op Codes

The following table defines the HLIC Op codes:

Op

Code

Description Remarks

0 Reserved

1 HDCD Get Get entities from the HDCD

2 HDCD Set Set entities in the HDCD

3 Reserved

4 Change Mode Change HDBaseT

Operation Mode

5 to 62 Reserved

63 Non Ack / Abort Transaction

Table 39: HLIC Op Codes


157

Confidential

4.3.4 HLIC Get Transaction

In an HLIC Get transaction the Initiator retrieve HDCD entities from the Responder. The transaction starts

when the Initiator send an HLIC Get Request packet as described in section ‎4.3.4.1 the Responder responds

in one or more HLIC Get Reply packet as describe in section ‎4.3.4.2 containing ELV fields of the requested

HDCD entities.

4.3.4.1 HLIC Get - Request Packet

Following is the HLIC Get - Request packet format:

A set of HDCD entities references according to the

Referencing Mode

…

CRC32Length

Get

Op Code

Request

Ref Mode

0100000 Ref 1 Ref N

Non Direct

Flag

Figure 118: HLIC Get – Request Packet Format

When requesting HDCD entities the initiator can use different referencing modes in order to define the set of

HDCD entities it wants to retrieve.

Non Direct Flag – One bit field:

o zero: specifies that target port for query is the port in which the responder receive the

packet

o one: specifies non direct query in this case the Ref1 field is a 16bits field which holds the

Port Identifier of target port for query within the responder device

Ref Mode – A 7 bits field carrying the reference mode code. The following table specify the available

reference mode:


158

Confidential

Table 40: HDCD Referrancing Modes

In each HLIC Get transaction the Initiator shall use only one referencing mode for that transaction.

4.3.4.2 HLIC Get - Reply Packet

Following is the HLIC Get - Reply packet format:

A set of ELV’s conveying the value of the requested

HDCD entities

…

CRC32Length

Get

Op Code

Reply

1100000 ELV 1 ELV N

Reply Idx

Last Reply

Figure 119: HLIC Get – Reply Packet Format

Last Reply – A one bit field, which when set to one, is specifying that this reply packet is the last reply

in this transaction

Referencing

Mode Code

Name Description

1 Specific The specific entity ID (Reference is transferred as a 16

bits field)

2 Range All entities between ID1 and ID2 including them

(Reference is transferred as a 16 bits field of ID1

followed by a 16 bits field of ID2) ID1 <= ID2

3 PrefixRange All entities with the specified PrefixID (Reference is

transferred as a 16 bits field PrefixID followed by an 8

bits field PrefixShift) an ID belong to the PrefixRange if

the ID after zeroing its PrefixShift LSB‟s ((ID >>

PrefixShift) << PrefixShift ) is equal to the PrefixID

4 Complex An ELV specifying Entity ID and a set of parameters

which are needed by the responder to access the

HDCD. (Reference is transferred as an ELV the

required parameters are carried using the Value field of

the ELV)


159

Confidential

Reply Idx – A 7 bits field which specify the index of this reply packet. The first reply packet shall use

zero in its Reply Idx field. Each following reply packet increase it by one including wrap around, to

zero, after Reply Idx of 127.

The transaction is completed when the Initiator receives a valid last response packet. There is no

retransmission mechanism upon detection of bad CRC packet. If the Initiator discover mismatch in the Reply

Idx field it may assume that some reply packets were lost and may try to retrieve the unsatisfied HDCD

entities, from it original request, after the completion of this transaction in a new transaction.

The Initiator shall examine the Reply packet according to the original referencing mode used in the Request

packet. For „Specific‟ and „Complex‟ modes the reply shall contain reply ELV per reference entry in the

original request packet. The reply ELVs shall also appear in the reply packet(s) in the same order as they

were sent in the request packet.

In case of an error regarding a certain requested Entity ID the responder shall reply with an Error ELV as

defined in section ‎4.2.1.1

For „Range‟ and „PrefixRange‟ modes the responder shall respond only with the Entity IDs it currently

supports within the specified range and shall not generate Error ELV for each other entity ID within the

specified range. If no entities are supported for a specific range reference request the responder will respond

with the proper Error ELV and with the ID1 / PrefixID (see Table 40) in the original Entity ID field

4.3.5 HLIC Set Transaction

In an HLIC Set transaction the Initiator is trying to modify HDCD entities at the Responder. The transaction

starts when the Initiator send an HLIC Set Request packet as described in section ‎4.3.5.1 the Responder

responds in one or more HLIC Set Reply packet as describe in section ‎4.3.4.2‎4.3.5.2 containing ELV fields of

the requested HDCD entities after modification or with error codes.

4.3.5.1 HLIC Set - Request Packet

Following is the HLIC Set - Request packet format:


160

Confidential

A set of ELV’s conveying the value to be written to the requested HDCD entities

…

CRC32Length

Set

Op Code

Request

Ref Mode

0010000 ELV 1 ELV N

Non Direct

Flag

Figure 120: HLIC Set – Request Packet Format

Non Direct Flag – One bit field:

o zero: specifies that target port for „set‟ is the port in which the responder receive the packet

o one: specifies non direct „set‟ in this case the ELV1 field is replaced with a 16bits field which

holds the Port Identifier of target port for „set‟ within the responder device

Ref Mode – A 7 bits field carrying the reference mode code.

When setting HDCD entities the initiator can use only the „Specific‟ or „Complex‟ referencing modes see Table

40

4.3.5.2 HLIC Set - Reply Packet

Following is the HLIC Set - Reply packet format:

A set of ELV’s conveying the value of the requested

HDCD entities

…

CRC32Length

Set

Op Code

Reply

1010000 ELV 1 ELV N

Reply Idx

Last Reply

Figure 121: HLIC Set – Reply Packet Format

Last Reply – A one bit field, which when set to one, is specifying that this reply packet is the last reply

in this transaction

Reply Idx – A 7 bits field which specify the index of this reply packet. The first reply packet shall use

zero in its Reply Idx field. Each following reply packet increase it by one including wrap around, to

zero, after Reply Idx of 127.


161

Confidential

The transaction is completed when the Initiator receives a valid last response packet. There is no

retransmission mechanism upon detection of bad CRC packet. If the Initiator discover mismatch in the Reply

Idx field it may assume that some reply packets were lost and may try to retrieve the unsatisfied HDCD

entities, from it original request, after the completion of this transaction in a new transaction.

The reply packet shall contain reply ELV per reference entry in the original request packet. The reply ELVs

shall also appear in the reply packet(s) in the same order as they were sent in the request packet.

In case of an error regarding a certain requested Entity ID the responder shall reply with an Error ELV as

defined in section ‎4.2.1.1

4.3.6 HLIC Change Mode Transaction

4.3.7 HLIC Non Ack/Abort Packets

The usage of the Abort mechanism is explained in ‎4.3.1. The Initiator may initiate an Abort request to the

responder while the responder may initiate a Non Ack / Abort reply. Both packets are carrying abort code

which provides more information regarding the cause of the abort.

The valid codes for the Abort Code field are as follow:

Table 41: HLIC Abort Codes

Following are the request and reply packets formats

Abort

Code

Name Description

1 Bad CRC Bad CRC packet is the cause for the abort usually it will

be generated by the responder when received a bad

CRC request packet

2 Unsupported

Op code

Received request packet contains unsupported op

code

3 Params

mismatch

Op Code parameters do not match op code

4-255 reserved


162

Confidential

4.3.7.1 HLIC Non Ack / Abort - Request Packet

Following is the HLIC Non Ack Abort - Request packet format:

An optional description

…

CRC32Length

NonAck/Abort

Op Code

Request

0111111 Desc 1 Desc N

Abort Code

Figure 122: HLIC Abort – Request Packet Format

Abort code – An 8 bits field containing the reason for aborting the transaction

Desc 1 to Desc N – Optional description of the abort reason

4.3.7.2 HLIC Non Ack / Abort - Reply Packet

Following is the HLIC Non Ack Abort - Reply packet format:

An optional description

…

CRC32Length

NonAck/Abort

Op Code

Reply

1111111 Desc 1 Desc N

Abort Code

Figure 123: HLIC Abort – Reply Packet Format

Abort code – An 8 bits field containing the reason for aborting the transaction

Desc 1 to Desc N – Optional description of the abort reason


163

Confidential

The Responder shall always use an Abort Reply Packet:

If the Responder receive a bad CRC request packet it shall respond with Non Ack reply packet

If the Abort reply is generated as a reply to an abort request sent by the Initiator it shall contain the

exact content as the request packet (except from the Reply Flag bit).

In the case when the Responder initiates an abort from a transaction it shall send an Abort Reply

Packet to which the Initiator shall not reply.


164

Confidential

5 Network Layer

5.1 General

The HDBaseT network implements in parallel two networking schemes over the same LAN cabling

infrastructure:

1. T-Network : provides reservation based, predictable, stable, high throughput and low latency

services (T-Services) for time sensitive communication streams

2. E-Network : provides regular Ethernet services

5.1.1 T-Network

These T-Services are provided by the T-Network to different protocol/interface/application T-Adaptors,

implemented at the network edges and wishing to communicate over the HDBaseT network.

In order for a T-Adaptor to communicate over the network, with another T-Adaptor, a session must be created.

The session defines the communication network path and reserves the proper service along it. Each active

session is marked by a SID (Session ID) token carried by each HDBaseT packet which belongs to the

session. The T-Switches along the network path switch those packets according to their SID tokens.

5.1.2 E-Network

In order to ensure maximum compatibility with the large installed base of Ethernet based applications, the

HDBaseT network implements native Ethernet networking by encapsulating/decapsulating the Ethernet data

per HDBaseT hop and by switching it, using a “regular” Ethernet switching function, at each HDBaseT switch.

This E-Switching function within the HDBaseT switch device shall support RSTP (IEEE 802.1D-2004 Rapid

Spanning Tree Protocol) and can be connected to pure Ethernet switches via pure Ethernet links. The RSTP

resulted, Ethernet active topology, may create active Ethernet connections between different E-Switching

entities through pure Ethernet switches. Or in other words: when an Ethernet message is sent from one E-

Switching entity to another E-Switching entity (even a neighboring entity) the message path is not limited to

HDBaseT links and may involve pure Ethernet links and switches.

This native Ethernet support, allows pure Ethernet devices to function as Control Points for the HDBaseT

network.

5.1.3 HDBaseT Network Objectives

Support in parallel, over the same home span cabling infrastructure, high quality networking of:

o Time sensitive data streams such as

HDMI 1.4 streams with their associated controls


165

Confidential

S/PDIF streams

USB streams

o Ethernet data

Provide transparent network attachment for legacy devices/interfaces – HDMI, Ethernet, USB and S/PDIF

Provide transparent network attachment for future supported devices/interfaces – Generalized core network

services

Self installable - HDBaseT devices do not have to be individually configured in order to operate correctly over

the network

Enable pure Ethernet devices to function as HDBaseT Network Control Points

Enable low cost solutions for CE price points

5.1.3.1 Network Topology

Support point to point, star, mesh and daisy chain topologies

Support the following port directionalities:

o Fixed A-Symmetric : port is a downstream input or a downstream output

o Bi-Functional A-Symmetric: same port can function as a downstream input and as a

downstream output but not at the same time

A relatively long function changing period is assumed so it shall not be consider as

a practical half duplex communication but rather two functional modes which can

be dynamically configured and/or resolved according to the link partner

o Symmetric: same port can function as a downstream (high throughput) input and as a

downstream (high throughput) output at the same time

Support up to 5 network hops (maximum of 4 switches in any network path)

Support IEEE 802.1D-2004 Rapid Spanning Tree Protocol (RSTP) to enable Ethernet loop removal

(Ethernet packets may flow, through the HDBaseT E-Network, in a different path than the T-Network

packets)

5.1.3.2 Latency Targets

Maximum T-Network latency over full network path (max of 5 hops) of less than 100uS (first symbol,

in the packet, transmitted to the HDBaseT network, to last symbol received at its final destination)

o Note that edge T-Adaptors latency is not included

Maximum T-Network, full downstream path, latency variation of less than 20uS


166

Confidential

5.1.3.3 Control and Management

Support control and management using HDBaseT Control Point functions

Support network operation without mandating the presence of a control point function

Support control using native HDMI-CEC and provide extended CEC switching to enable operation

with multiple sinks

Support control using native USB device selection, provide extended USB switching to enable

operation with multiple USB hosts

Support HDBaseT Control and Management during Stand By mode:

o A HDBaseT switching port devices shall operate at LPPF #2 during Stand By mode

o A HDBaseT non-switching port devices shall operate at least in LPPF #1 and may operate

at LPPF #2 during Stand By mode

5.1.4 Entity Referencing Method

HDBaseT entities are referenced/identified in the HDBaseT network using the following four levels hierarchical

referencing method:


167

Confidential

2 Bytes

HDBaseT Device Port Device T-Group Entity

Port Device

Port Device

T-Group Entity

T-Group Entity

T-Adaptor Entity

T-Adaptor Entity

T-Adaptor Entity

Each device may

have several port

devices

Each port device

may have several

T-Groups

Each T-Group

may have several

T-Adaptors

Device MAC Address Port ID Type MaskT-G ID

6 Bytes

10 Bits 6 Bits

2 Bytes

Unique Identifier of the

device management entity

PDME/SDME/CPME

Unique ID within the

device

Unique ID

within the

port

Unique mask

bit per T-

Adaptor within

the T-Group

Device Referencing

Port Referencing

T-Group Referencing

T-Adaptor/s Referencing

Ref Notation – Device ID : Port ID, T-Group ID : T-Adaptors Type Mask

Figure 124: Entity Referencing Method

5.1.4.1 T-Adaptors Type Mask Field

Each T-Group contains a T-Adaptors Type Mask field which represents what types of T-Adaptors are

associated with this T-Group. The basic Type Mask field is a 16 bits field (b15 is the MSB and b0 is the LSB)

where each bit, if set to one, represents a certain type of T-Adaptor associated with this T-Group.

The following table specifies the already defined T-Adaptor types bit mapping. The first six future T-Adaptor

types will use the reserved bits.

When b15 is set, an extension field of additional 16 bits exists for more future T-Adaptor types.

HDBaseT devices complying with this specification shall not assume that this extension bit is always zero

and shall support up to three, 16 bit, extension fields (altogether up to 64 bits type mask field)


168

Confidential

Table 42: T-Adaptor Types bit mapping

Bit Index T-Adaptor Type Bit Index T-Adaptor Type

0 HDMI Source 8 S/PDIF TX

1 HDMI Sink 9 S/PDIF RX

2 Reserved 10 Reserved

3 Reserved 11 Reserved

4 USB Host 12 IR TX

5 USB Device/Hub 13 IR RX

6 Reserved 14 UART

7 Reserved 15 Extension Bit

Since each T-Group cannot be associated with more than one instance of a certain T-Adaptor type, the type

mask field uniquely identifies the T-Adaptor instances within the T-Group. Using type mask referencing we

can reference one or several T-Adaptor instances from the T-Adaptors group which is associated with this

T-Group

This flexibility is needed to allow the creation of a session involving only a subset of the T-Adaptor group, and

communication with one, several or all of the T-Adaptors.

5.1.4.2 Port and T-Group ID (TPG) Field

The Port and T-Group ID two byte field conveys a 10 bit index of the port device within the HDBaseT device

concatenated with 6 bits T-Group index within the port device.

Port ID T-G ID

6 Bits10 Bits

2 Bytes

Figure 125: TPG Field

The full TPG ID field provides a unique reference for a certain T-Group entity within the device.

Port index - non zero value from 1 to 1023 provides a unique reference for a port device within the

HDBaseT device.

T-Group index – non zero value from 1 to 63 provides a unique reference to a certain T-Group

within the port device.

When the T-Group index is zero the TPG ID provides a unique reference for the port within the device and can

be referred to as port ID.


169

Confidential

When the Port index is zero the TPG ID do not provide any meaningful reference.

5.1.4.3 Device ID

HDBaseT is using Ethernet MAC addresses as unique identifiers for the management entities within its

devices.

SDMEs and CPMEs shall provide Ethernet termination and therefore shall use their Ethernet MAC address

as their unique identifier.

PDMEs may provide Ethernet termination:

In case Ethernet termination is provided by a PDME, it will use its Ethernet MAC address as its unique

identifier

In case Ethernet termination is not provided by a PDME:

o The PDME shall communicate its lack of Ethernet termination to its link partner edge switch

using HLIC transactions

o The PDME shall “borrow” the identity of its link partner edge switch port by retrieving its SDME

device ID and the Port index within the switch using HLIC

o The PDME shall use the link partner SDME MAC address as its own “Device ID” and shall use

its link partner Port index as its own Port index in all management transactions towards the

network. The link partner SDME shall route all management transactions targeting this Port of

this switch to the link partner PDME

o If the link partner is not a switch as in direct point to point, then such PDME will not have a

unique identifier and can only be reached by its link partner

As a result, Port Referencing (Device ID : Port ID (T-Group bits are zero) ) is needed to uniquely identify

a PDME

The usage of the E-Network Ethernet MAC address as the T-Network Device ID creates the linkage between

the T-Network and the E-Network and allows the management of T-Network entities and sessions using

Ethernet communication.

SStephens

Highlight

SStephens

Highlight


170

Confidential

5.1.4.4 Referencing Examples

S1

E1E2

E4

E3

12

3

S1

S1

1

1

E1

E1

Edge Switch

Intra Switch

Edge Port

Intra Port

End Node device

Embedded T-Adaptors

Edge Link

Intra Link

4

1 Virtual Edge Port

E1 End Node device without

Ethernet Termination

MAC: yyyyyy

MAC: xxxxxx

MAC: ffffff

HDMI

Source

T-Adaptor

USB

Host

T-Adaptor

T-Group

HDMI

Source

T-Adaptor TX

Ethernet

Switching

T-Group

PDME

MAC: xxxxxx

E-Stream

ID: 1

ID: 2

HDMI

Source

T-Adaptor

USB

Host

T-Adaptor

T-Group

ID: 1

T-Group Ref: yyyyyy:4,1

T-Adaptor Ref: yyyyyy:4,1:0x0001

T-Group Ref: xxxxxx:1,2

PDME Ref: xxxxxx:1,0

Both T-Adaptors Ref: xxxxxx:1,2:0x0011

PDME Ref: yyyyyy:2,0 PDME Ref: ffffff:1,0

T-A Ref: xxxxxx:1,1:0x0001

Figure 126: Referencing Examples

5.1.5 Routing Schemes

HDBaseT utilizes the following routing schemes:

5.1.5.1 Distributed Routing Scheme (DRS)

The HDBaseT network utilizes a default Distributed Routing Scheme (DRS) which allows session

creation between T-Adaptors with and without the existence of a HDBaseT control point function in the

network. It allows controlling the network using extended legacy control functions such as HDMI-CEC

and USB. In DRS each T-Adaptor may initiate/maintain/terminate, through its associated management

entity PDME/SDME, a session with other T-Adaptors in the sub network. DRS also allow operation

with and without the existence of a Routing Processor Entity (RPE) which maintains full knowledge

regarding the network topology and the status of the links/devices in it. DRS is using the HD-CMP

Broadcast SNPM mechanism to discover T-Adaptors in the sub network with their directional

connectivity. DRS is using the HD-CMP Unicast SNPM mechanism to provide distributed route/path

computing and maintenance.

PDMEs, SDMEs and CPMEs shall comply with the requirements as set by the DRS per entity.


171

Confidential

5.1.5.2 Centralized Routing Scheme (CRS)

The HDBaseT network enables the usage of an optional Centralized Routing Scheme (CRS) in which

an optional Routing Processor Entity (RPE) may be implemented, at any device, on top of the CPME

functionality. The combination of RPE and CPME provides a single entity which is aware and can

maintain the full topology and status of each link in the network, and is capable of computing the

optimal route and a valid session ID for each session upon creation. The RPE/CPME may be

implemented at an end node, switch or pure Ethernet device. The RPE/CPME functionality enables a

faster route / SID computation and therefore faster session creation. Using its knowledge base, the

RPE shall provide session route computation services for any management entity upon request.

Each SDME and CPME shall comply with the requirements as set by the RPE to ensure that a RPE, if

exists in the network, will be able to function.

Each CPME shall use the RPE route/SID computation services if such RPE exists in the network.

Each PDME/SDME may use the RPE route/SID computation services if such RPE exists in the

network.

5.2 HDBaseT Control & Management Protocol (HD-CMP)

HDBaseT‟s management entities: PDMEs, SDMEs and CPMEs, communicate using HD-CMP messages. HD-CMP

messages may be encapsulated using Ethernet packets to be transferred over the Ethernet network or using HLIC

packets to be transferred from one management entity to a neighboring management entity over the HDBaseT link.

HD-CMP messages are sent using two different methods:

o Direct - unicast and broadcast communication according to the Ethernet active topology (as

determined by the RSTP protocol)

Unicast messages may use HLIC on the edge links

o Sub Network Propagation Message (SNPM) – An Intra HDBaseT Sub Network restricted, T-Network

direction aware, loop protected, message sent by a PDME/SDME to, its directional neighboring,

PDMEs/SDMEs according to the HDBaseT physical topology and type of message

Downstream SNPM (DSPM) – The message propagates to downstream neighbors

Upstream SNPM (USPM) – The message propagates to upstream neighbors

Mixed-path SNPN (MXPM) – The message propagates to all neighbors


172

Confidential

HD-CMP Messages

SNPM Direct Messages

Broadcast SNPM Unicast SNPM

Periodic SNPM

Broadcast Unicast

Edge SNPM Intra SNPM

Over Edge Links Other Links

Using Ethernet Encapsulation

Using Ethernet or HLIC Encapsulation

Figure 127: HD-CMP messages and encapsulation methods mapping

5.2.1 HD-CMP Message Format

The following figure depict the HD-CMP message format

HD-CMP

Op CodeHD-CMP Payload

2 Bytes Variable Length

Destination Entity

Device ID : TPG

Source Entity

Device ID : TPG

8 Bytes 8 Bytes

Figure 128: HD-CMP message Format

Destination Entity – An 8 byte TPG reference (Device ID : Port ID, T-Group Index) conveying the Port and T-

Group reference of the message destination entity

Source Entity – An 8 byte TPG reference (Device ID : Port ID, T-Group Index) conveying the Port and T-Group

reference of the message source entity

o The Port reference (Device ID : Port ID) is sufficient for the network to identify the proper device and

its management entity (SDME/PDME/CPME). Additional T-Group referencing is needed to identify the

proper entity within the managed device as a parameter of this message


173

Confidential

o Additional T-Adaptors referencing, using type masks, is done, if needed, as part of the HD-CMP

payload depending on the type of the HD-CMP message

HD-CMP Op Code – A 2 byte field conveying the type of this message and determining the format of the HD-

CMP payload

5.2.2 HD-CMP Message Encapsulation within Ethernet Packet

HD-CMP messages shall be encapsulated within Ethernet packets with the following format:

HD-CMP



Destination Entity

Device ID : TPG

Source Entity

Device ID : TPG

8 Bytes 8 Bytes

Destination MAC

Address

Source MAC

Address

Type: HD-CMP

EtherTypeHD-CMP Payload

6 Bytes 6 Bytes 2 Bytes Variable Length

Eth CRC

4 Bytes

Destination TPG

2 Bytes

Source TPG

2 Bytes

HD-CMP

Op Code

2 Bytes

Device ID Device ID

Figure 129: HD-CMP message encapsulation using Ethernet packet

• Destination MAC Address – Conveys the Device ID reference of the destination management entity

(SDME/PDME/CPME) for this message or an Ethernet broadcast address

• Source MAC Address – Conveys the Device ID reference of the source management entity

(SDME/PDME/CPME) for this message

• EtherType – A unique, 2 byte, EtherType value (to be allocated by the Ethernet Alliance)

• Destination TPG – Completes the TPG reference for the destination entity of this message and also identifies

the intended target port device

• Note that due to the RSTP active topology the Ethernet packet may arrive to its destination device

through a different port device

• Source TPG – Completes the TPG reference for the source entity of this message and also identifies the

intended source port device

• Note that due to the RSTP active topology the Ethernet packet may be transmitted by the source

device through a different port device

Upon the reception of a message with “good CRC”, the destination management entity shall treat the message as if

it was received through the intended destination port device and was transmitted from the intended source port

device.


174

Confidential

In the case that the destination Port reference (Device ID : Port ID) is “borrowed” by a, non Ethernet terminating,

edge PDME, the link partner, edge SDME, shall forward the message to the proper port device using HLIC. HD-

CMP Ethernet packets with a broadcast destination address shall not be forwarded to the “borrowing” PDME.

When sending a Direct HD-CMP message to a management entity which provides Ethernet termination, the

destination TPG field may be zeroed.

When sending a Direct, broadcast, HD-CMP message, the destination TPG field shall be zeroed.

When a management entity which provides Ethernet termination, sends a Direct HD-CMP message, it may zero the

source TPG field.

When sending a SNPM HD-CMP message both source and destination TPG fields shall contain the proper non-

zero values

5.2.3 HD-CMP Message Encapsulation within HLIC Packet

HD-CMP messages shall be encapsulated within HLIC packets with the following full form and short form

formats

5.2.3.1 Full Form

Length Op Code

Request

/ Reply

Flag

1 0 0 1 0 0 0HD-CMP


2 Bytes

CRC-32

4 BytesVariable Length

Destination Entity

Device ID : TPG

Source Entity

Device ID : TPG

8 Bytes 8 Bytes

Figure 130: HD-CMP message, full form, encapsulation within HLIC packet

• Full Form HD-CMP messages are encapsulated within HLIC packets identified by HLIC Op Code = 36

• These messages convey a Port and T-Group reference of the source and destination entities

• Full Form HD-CMP payload, over HLIC, length is limited to 493 bytes

• The initiator of the HLIC transaction marks it as a request (zero value at the Request / Reply flag)

• Upon the reception of a bad CRC, HD-CMP over HLIC packet, the responder shall send a Non Ack /

Abort reply according to the HLIC protocol

• Upon the reception of a good CRC, HD-CMP over HLIC packet, the responder shall send HLIC reply

packet according to the following format:


175

Confidential

Length Op Code

Request

/ Reply

Flag

1 0 0 1 0 0 1HD-CMP

Op Code

2 Bytes

CRC-32

4 Bytes

Destination Entity

Device ID : TPG

Source Entity

Device ID : TPG

8 Bytes 8 Bytes

Response

Code

1 Byte

Figure 131: HD-CMP message, full form reply, over HLIC packet

• The Destination Entity Reference, Source Entity Reference and HD-CMP Op Code are the

same as in the request packet

• The one byte response code field shall use the following pre define values:

• 0x00 – Success

• 0x01 – Forwarding Error for this message

• 0x02 – General Error

• 0x03 to 0xff - Reserved

5.2.3.2 Short Form

Length Op Code

Request

/ Reply

Flag

1 0 0 0 0 0 0HD-CMP


2 Bytes

CRC-32


Figure 132: HD-CMP message, short form, encapsulation within HLIC packet

• Short Form HD-CMP messages are encapsulated within HLIC packets identified by HLIC Op Code = 32

• These messages do not convey references to the source and destination entities and they are useful

since some frequent HD-CMP messages, such as periodic SNPMs are sent between, management

entities of link partners with no need to specify their source and destination entities

• Short Form HD-CMP, over HLIC, payload length is limited to 509 bytes

• The initiator of the HLIC transaction marks it as a request (zero value at the Request / Reply flag)

• Upon the reception of a bad CRC, HD-CMP over HLIC packet, the responder shall send a Non Ack / Abort

reply according to the HLIC protocol


176

Confidential

• Upon the reception of a good CRC, HD-CMP over HLIC packet, the responder shall send HLIC reply packet

according to the following format:

Length Op Code

Request

/ Reply

Flag

1 0 0 0 0 0 1HD-CMP

Op Code

2 Bytes

CRC-32

4 Bytes

Response

Code

1 Byte

Figure 133: HD-CMP message, short form reply, over HLIC packet

• The HD-CMP Op Code is the same as in the request packet

• The one byte response code field shall use the following pre define values:

• 0x00 – Success

• 0x01 – Forwarding Error for this message

• 0x02 – General Error

• 0x03 to 0xff - Reserved:

5.2.4 Common Payload Sections

The following data structures are commonly conveyed as payload sections in several types of HD-CMP

messages:

5.2.4.1 Path Description Section (PDS)

The PDS contains an array of PDS entries each describing a device with input port into the device and output

port from the device. An array of such entries completely defines a sub network path since paths in the

HDBaseT sub network are reversible which means that the “return channel” of the session is flowing in the

same sub network path but in the opposite direction.

The first PDS usage is to collect the sub network path in which a SNPM message (broadcast or

unicast) have been flowing, where each intermediate device fills up the next available, PDS entry in

the PDS array, with its own info. While updating the PDS the intermediate device shall also check for

topology loops in the sub network and discard messages with detected loops. A loop is detected

when the device finds its own device ID in a previous, already filled, PDS entry of a received Intra

SNPM message.

The second PDS usage is to communicate/define a sub network path by sending a pre-filled PDS in

unicast SNPM or direct messages.

The PDS shall be transmitted and updated according to the following format:


177

Confidential

PDS Entries

Max Count: N

1 Byte

PDS Entries

Occ Count

1 Byte

PDS Entry

N

10 Bytes

PDS Entry

1 …

10 Bytes

Path Description Section (PDS)

Device IDInput

Port ID

Output

Port ID2 Bytes 2 Bytes6 Bytes

Figure 134: PDS Format

• Max Count: Path Description Max Number Of Entries – The sender of the SNPM shall specify how

many entries are pre allocated in this PDS

• Non Occupied PDS entries shall contain all zero value

• Occ Count: This one byte, two‟s complement, field shall be used in the following manner per use case:

• When using the PDS to collect a path description the Occ Count shall represent the current

number of occupied (non zero) entries in the PDS. Each device, in the path, shall fill up the

next available PDS entry (in Index Occ Count +1) and increase the Occ Count by one.

• When using the PDS to define a path for a unicast SNPM message the transmitted absolute

value of Occ Count shall represent the PDS entry index, describing the device which is about

to receive this message. The receiving device uses the indexed entry input and output port

IDs to determine where to propagate the message. If the Occ Count value is larger than zero

the receiving device propagate the message according to the output port as listed in the

proper entry. If the Occ Count value is smaller than zero, it means that the message shall be

propagated in the reverse order of the PDS and therefore the receiving device shall

propagate the message according to the input port as listed in the proper entry (switch the

input and output roles due to reverse propagation). In both cases the device shall increase

the Occ Count by one before propagating it.

• In the case that Max Count is zero, Occ Count shall also be zero and no PDS entries shall be allocated

therefore the length of the PDS, in bytes, shall be always equal to:

• PDS_Length_in_Bytes = 2 + Max Count * 10 (size of a PDS entry)

• PDS Entry: A 10 byte field containing the following sub fields:

• Device ID: unique identifier 6 bytes MAC address of a „device‟ on the message path

• Input Port ID: The Port ID (TPG field with T-Group ID = 0) within that „device‟ where the

message was/is-to-be received from

• Output Port ID: The Port ID within that „device‟ where the message was/is-to-be propagated

to


178

Confidential

5.2.4.2 Network Path Availability Section (NPA)

HDBaseT uses a standard, twelve (12) byte, data structure to represent the directional network availability /

resource requirements of / from a certain path or a link. The NPA is defined in terms of available throughput

and the accumulated number of packet streams per priority, per direction along the path.

The first NPA usage is to collect the resources availability/usage of a network path in which a SNPM

message (broadcast or unicast) is flowing, where each intermediate device shall properly update the

NPA. Edge SDMEs shall properly fill up the NPA on behalf of the edge link as well. The NPA in this

context will represent the available throughput and the number of packet streams interfering with

each priority as detailed below.

The second NPA usage is to report/define the resource requirements from a certain path, link or a

session.

The NPA shall use the following format:

DS Path

Availability

US Path

Availability

6 bytes 6 bytes

Network Path

Availability

12 bytes

Available Throughput P1 PSU P2 PSU P3 PSU

1 Byte (8bits)12 bits12 bits2 Bytes (16bits)

Figure 135: NPA Format

• DS Path: A six (6) byte field which represents the availability/requirements of the path in the

downstream direction.

• US Path: A six (6) byte field which represents the availability/requirements of the path in the upstream

direction.

• Each of the above fields shall contain the following sub fields:


179

Confidential

• Available Throughput - A 2 byte sub field which shall represent the available/required

throughput in Mbps of/from a path or link (a 2 byte field can represent throughput values of up

to 65Gbps). The value shall take into account the link conditions in the case of reporting the

available throughput and framing overhead / required protection level in the case of

specifying the requirements from the path. When collecting the available throughput of a

certain path, in a SNPM, each device compares the available throughput it has on the next

link of the path and if it is lower than what is currently listed in the sub field it shall modify the

Available Throughput sub field. When specifying the session requirements this sub field shall

represent the accumulation of throughput required by all packet streams needed for this

session, taking into account the needed overhead. The value 0xFFFF is reserved for

indicating “Maximum Available” when specifying the requested Session Resources and shall

not be used when specifying the committed or actual Session Resources.

• Priority 1 PSU - A twelve (12) bit sub field which shall represent the accumulation of packet

streams number in PSU (see ‎5.2.4.3) which exist/are-required along the path. When

collecting the interfering PSUs for priority 1 victim packet, along a certain path, each SDME

shall act according to the specification in‎5.2.5. When specifying the session requirements

this sub field shall represent the accumulation of priority 1 PSUs required by all priority 1

packet streams needed for this session.

• Priority 2 PSU - A twelve (12) bit sub field which shall represent the accumulation of packet


collecting the interfering PSUs for priority 2, victim packet, along a certain path, in a SNPM,

each SDME shall act according to the specification in ‎5.2.5. When specifying the session

requirements this sub field shall represent the accumulation of priority 2 PSUs required by all

priority 2 packet streams needed for this session.

• Priority 3 PSU - An eight (8) bit sub field which shall represent the accumulation of packet


collecting the interfering PSUs for priority 3, victim packet, along a certain path, in a SNPM,

each SDME shall act according to the specification in ‎5.2.5. When specifying the session

requirements this sub field shall represent the accumulation of priority 3 PSUs required by all

priority 3 packet streams needed for this session.

5.2.4.3 Packet Stream Unit (PSU)

An important service provided by the T-Network is controlled latency variation, the T-Network limits the latency

variation that packets may experience along the path. The latency variation of a certain victim packet comprises

the accumulation, of additional delays at each transmitter/switch function along the path. Other, interfering,

packets will cause the victim packet to “wait for its turn”, adding undeterministic extra delay to its arrival time at

the final destination. At each node the scheduling interference is caused by:

Packets, belonging to packet streams with higher priority than the victim packet, which shall be served

by the transmitter/switch before the victim packet even if they arrive after the victim packet.

Packets, belonging to packet streams with the same priority as the victim packet, which shall be

served by the transmitter/switch before the victim packet only if they arrive before/with the victim

packet.


180

Confidential

A Packet, belonging to a packet stream with a lower priority than the victim packet, whose

transmission started before the arrival of the victim packet.

It is clear that the amount of scheduling interference at each transmitter/switch is the accumulation of all

interfering packet sizes transmitted from the arrival of the victim packet until its actual transmission. While the

“burstiness” of each packet stream, by itself, can be controlled, different packet streams are un-related to each

other. With a certain probability, a group of packets each belonging to a different packet stream, all arriving in

short period of time to a certain node and wishing to continue through a certain link, can create a “burst” of

packets interfering with a victim packet wishing to continue through the same link. Combination of such

interfering bursts per each node along the path can create large latency variation when compared with the case

of un-interfered transmission of packets belonging to the same victim stream. In order to control the latency

variation, the T-Network limits, per victim priority, the sum of max packet size over all interfering packet

streams, accumulated along the network path. Note that the limit is on the sum of max size packets of different

streams, for example if the limit is „8‟ it can be satisfied with 8 streams with max size „1‟, 2 streams with max

size „4‟, 2 streams with max size „1‟ + 2 streams with max size „3‟, etc…

In order to provide an efficient representation of this sum, HDBaseT defines a Packet Stream Unit (PSU) for the

DS (DPSU) and US (UPSU) which shall be used in the NPA data structure / section.

DS PSU

The following table provides classification of max packet sizes with their equivalent “Packet Stream Units”

(PSU) for the DS:

Table 43: DS Max Packet Size Classes mapping to DPSU

Max payload of 255 symbols + 9 symbols framing

overhead + max of 4 optional extended info symbols

16268Full Size



8134Half Size

Max payload of 54 symbols + 9 symbols framing overhead

+ max of 4 optional extended info symbols

467Quarter Size

Max payload of 8 symbols + 5 symbols framing overhead +

max of 4 optional extended info symbols

217Small Size

Payload of 2 symbols + 5 symbols framing overhead + 2

optional extended info symbols…. or


optional extended info symbol

19Micro Size

RemarkPSU

Weight

Max Total Packet Size

(including the trailing Idle

symbol) in Symbols

Max Packet Size

Class Name



16268Full Size



8134Half Size

Max payload of 54 symbols + 9 symbols framing overhead

+ max of 4 optional extended info symbols

467Quarter Size

Max payload of 8 symbols + 5 symbols framing overhead +

max of 4 optional extended info symbols

217Small Size


optional extended info symbols…. or


optional extended info symbol

19Micro Size

RemarkPSU

Weight

Max Total Packet Size

(including the trailing Idle

symbol) in Symbols

Max Packet Size

Class Name

As an example a declared value of 32 PSU can represent two streams each using „Full Size‟ packets (32 = 2

streams x 16 PSU/stream) or eight streams each using „Quarter Size‟ packets (32 = 8 streams x 4

PSU/stream), or any combination which result in a total of 32 PSU. The mapped packet size shall consider

also the changes in packet size due to dynamic modulation changes done by the transmitter according to the

link conditions.


181

Confidential

Packet streams using a max size packet with sizes in between these packet size class limits may use

intermediate PSU weights, by taking the lower class limit PSU value and adding 1 PSU per 16 additional

symbols, and another 1 PSU for any remaining symbols (between 1 and 16). For example if a packet stream

has a max size packet of 150 symbols, it can declare usage of 9 PSUs, since this size is larger than 134 (8

PSUs upper limit) and ceil(150-134/16)=1 therefore adding one PSU. However if the max packet size was

151 then ceil(151-134/16)=2 adding 2 PSU for a total of ten (10) PSUs.

US PSU

The USPU unit is equal one US symbol.

5.2.4.4 Device Info Section (DIS)

A three level, hierarchical, data structure, used to describe, device, TPGs and T-Adaptors identity, capabilities

and status. The DIS is being frequently used in SNPM and direct HD-CMP messages and therefore conveys

only needed, basic information. The full information regarding the identity, capabilities and status of these

entities, can be retrieved using HDCD access via HLIC and/or remote HLIC over HD-CMP transactions.

Device ID

6 Bytes

Device Type

1 Byte

Length in

Bytes

2 Bytes

TPG 1

Info

Variable Length

…TPG Last

Info

Variable Length

TPG ID

2 Bytes

T-Adaptors

Type Mask

2/4 Bytes

T-Adaptor 1

Info

T-Adaptor 2

Optional Info

Variable Length

…

T-Adaptor Last

Optional Info

Variable Length

Rest of Info

Length In Bytes

1 Byte

T-Adaptor

Type Code

2/4 Bytes

T-Adaptor

Specific Info

Variable Length

Info Length:

7

1 Byte

T-A Type Code:

0x0001

2 Bytes

HDMI Source

Type

1 Byte

HDMI Source

Status

1 Byte

CEC Preferred

Logical Addr

2 Bytes

CEC Device

Type

1 Byte

Example of HDMI Source T-Adaptor Info

T-Adaptor Info Format

T-Group Info Format

Device Info Section Format

Device Status

1 Byte

Length in

Bytes

2 Bytes

Port Type Port Status

1 Byte1 Byte

Figure 136: DIS Format

• Device ID: A 6 byte field which contains the Device ID of the reported device.

• Device Type: A one byte field which represent the type of the device:

C TypeER

b0b7 b4


182

Confidential

Figure 137: Device Type Format

The 3 bits (b2:b0) Type sub field represents the type of the device as follow:

o 000 – End Node device with embedded HDBaseT interface

o 001 – Switch device

o 010 – Stand alone Adaptor End Node device

o 011 – Daisy Chain device

o 100 – Repeater device

o 101 – Reserved

o 110 – Coupler Device

o 111 – Reserved

The „E‟ bit (b3) if set to 1 represents that the HDBaseT management entity of this device

provides Ethernet termination and can be directly accessed through HD-CMP over

Ethernet. If set to zero it represents that the device does not provide Ethernet

termination, shall be referenced at least by port referencing (Device ID : Port ID) and

HLIC shall be used on its edge link.

The „C‟ bit (b4) if set to 1 represents that the device provides control point functionality.

The „R‟ bit (b5) if set to 1 represents that the device provides routing processor

functionality.

Reserved bits (b7:b6) shall be set to zero upon generation and ignored/unchanged upon

reception/store.

• Device Status: A one byte field which represents the status of the device:

PWR

b0b7 b3

E

Figure 138: Device Status Format

The 2 bits (b1:b0) PWR sub field represents the power status of the device as follow:

o 000 – Off

o 001 – On

o 010 – Stand By

o 011 – Unknown

o 100 to 111 - Reserved


183

Confidential

The „E‟ bit (b3) if set to 1 represents that this device is an edge device with active T-

Adaptors. Active End Nodes and Edge SDMEs shall set this bit to one.

Reserved bits (b7:b4) shall be set to zero upon generation and ignored/unchanged upon

reception/store.

• Length: A two byte field which represents the length in bytes of the rest of the DIS.

• TPG Info: The rest of the DIS comprises a series of TPG info entries each comprising the following sub

fields:

• TPG ID: A 2 byte field which contains a reference to the reported Port and T-Group (Port ID, T-

Group Index) within the device (see ‎5.1.4.2 for TPG definition ). If the T-Group index is zero the

entry reports only Port information.

• Port Type: A one byte field which represents the type of the port device which include the reported

T-Group:

PoH Dir

b0b7 b3

Figure 139: Port Type Format

The 3 bit (b2:b0) Dir sub field represents the directionality capabilities of the port

device as follow:

o 000 – Fixed Asymmetric downstream output

o 001 – Fixed Asymmetric downstream input

o 010 – Bi-Functional

o 011 – Full Link Symmetric

o 100 – Half Link Symmetric

o 101 – Reserved

o 110 – Reserved

o 111 – Reserved

The two bit (b4:b3) PoH sub field represents the Power over HDBaseT capabilities

of the port device as follow:

o 00 – None

o 01 – PD

o 10 – PSE

o 11 – Both


184

Confidential

Reserved bits (b7:b4) shall be set to zero upon generation and ignored/unchanged

upon reception/store.

• Port Status: A one byte field which represents the status of the port device:

Op Mode PoH Dir

b0b7 b3

Figure 140: Port Status Format

The 3 bit (b2:b0) Dir sub field represents the current directionality status of the port

device as follow:

o 000 – Asymmetric downstream output

o 001 – Asymmetric downstream input

o 010 – Reserved

o 011 – Full Link Symmetric

o 100 – Half Link Symmetric

o 101 – Reserved

o 110 – Reserved

o 111 – Not in Active mode

The two bit (b4:b3) PoH sub field represents the current Power over HDBaseT

status of the port device as follow:

o 00 – No PoH

o 01 – PD

o 10 – PSE

o 11 – Resolving now

The 3 bit (b7:b5) Operation Mode sub field represents the current operation mode of

the port device as follow:

o 000 – Partner detect

o 001 – Ethernet Fallback

o 010 – LPPF #1

o 011 – LPPF #2

o 100 – 250 MSPS Active Mode

o 101 – 500 MSPS Active Mode


185

Confidential

o 110 – Reserved

o 111 – Reserved

• Length: A two byte field which represents the length in bytes of the rest of the TPG Info entry.

• T-Adaptors Type Mask: A variable length T-Adaptors type mask field representing the T-Adaptor

types, associated with the reported T-Group (see ‎5.1.4.1 for type mask definition).

• T-Adaptor Info: The rest of the TPG Info comprises a series of T-Adaptor info entries each

comprising the following sub fields:

• Length: A one byte field which represents the length in bytes of the rest of this T-Adaptor Info

entry.

• T-Adaptor Type Code: A variable length T-Adaptor type mask field representing the reported

T-Adaptor type code (see ‎5.1.4.1 for type mask definition).

• T-Adaptor Specific Info: A variable length T-Adaptor specific info with a format that is known

only to the target T-Adaptor and/or control point. Intermediate SDMEs shall not assume the

knowledge require to parse this info section. As a part of each T-Adaptor specification, the

HDBaseT specification defines the format of this T-Adaptor specific info.

5.2.5 Sub Network Propagation Message (SNPM)

SNPM is an HD-CMP message which is generated by a PDME/SDME and propagates, within the HDBaseT

Sub Network, from PDME/SDME to neighboring PDMEs/SDMEs, until it reaches its destination or the sub

network boundaries.

At each intermediate PDME/SDME the management entity may inspect/store/update the information

conveyed in the message and add additional information. This allows the usage of the SNPM to collect/set

information regarding network paths, links utilizations and nodes along the path.

The SNPM is T-Network direction aware, which means that the propagating entity propagates the message

only at the proper direction (downstream/upstream) according to the SNPM message directionality and the T-

Network physical topology.

SNPM shall use the target neighbor PDME/SDME reference (device id : intended receive port id) as the

„Destination Entity‟ reference field and it shall use the sender PDME/SDME reference (device id : intended

transmit port id) as the „Source Entity‟ reference field within the HD-CMP message. This means that per hop

the content of these fields shall be changed. Note that when SNPM is sent over Ethernet the actual transmit

/receive port may be different then intended.

SNPM shall use the following HD-CMP OpCode field format:


186

Confidential

Type

b0b15 b8

00 – Not Used

01 – DSPM

10 – USPM

11 – MXPM

0 0 0 0 0 0 0 x DirMod

00 – All Ports

01 – With Path

10 – Best Path

11 – By PDS

Figure 141: SNPM HD-CMP OpCode Format

Prefix – A 7 MSBs zero prefix defines that this is a SNPM

Broadcast/Unicast – A one bit field (b8) defines:

0 – This message is a broadcast SNPM

1 – This message is a unicast SNPM

Type – A four bit field which defines up to 16 message types per broadcast / unicast category

Mod – A two bit field which defines the propagation mode of this SNPM

o Broadcast SNPMs shall only use the „All Ports’ (00) value which means - propagate to all

ports with the proper directionality

o Unicast SNPMs may use all values (see value definitions at the Unicast SNPM section

‎5.2.7)

Dir – A Two bit field which defines the propagation directionality of this message:

00 – Not in Use : shall be discarded upon reception

01 – DSPM : downstream SNPM, shall propagate only to downstream outputs

10 – USPM : upstream SNPM, shall propagate only to downstream inputs

11 – MXPM : mixed path SNPM, may propagate to both downstream inputs and outputs

A SNPM sent towards Edge links is referred to as Edge SNPM, A SNPM sent towards Intra links is referred to

as Intra SNPM.

5.2.5.1 NPA Update

Each SNPM carries a NPA field, as defined in ‎5.2.4.2. Each SDME shall properly update the NPA field before

propagating the SNPM. This update is needed in order to collect and compute the sum of interfering PSUs a

victim packet from a given priority and direction might suffer along the path. In order to update properly the

NPA‟s „Priority x PSU‟ sub fields (see ‎5.2.4.3) the propagating SDME, shall identify the following:

Port A from which the SNPM was received/is-intended-to-be-received into the SDME


187

Confidential

Port B where the SNPM should be propagated to

Port B Session Group (BSG) – The sessions that are active on port B

Added Session Group (ASG) – The sessions that are active on port B but are not active on port A

Per active session, each SDME shall store the number of committed PSUs per priority per direction. BSG_Px

denotes the sum of committed Priority X PSUs in all sessions belonging to BSG. ASG_Px denotes the sum of

committed Priority x PSUs in all sessions belonging to ASG.

DS NPA

The SDME shall add to the received NPA „Priority x DS PSU‟ sub fields the following values ():

Additional_DS_P1_PSU = DS_ASG_P1 + DS_BSG_P2 + DS_BSG_P3 : For a victim P1 packet, only

the additional sessions going into port B are adding P1 interfering PSUs while Priority 2 and 3

streams may re-interfere with P1 packet at each SDME due to the retransmission that P1 packets are

using.

Additional_DS_P2_PSU = DS_BSG_P2 + DS_BSG_P3 +16 : For a victim P2 packet, other Priority 2

and Priority 3 streams may re-interfere with the victim P2 packet at each SDME due to the

retransmission that some P2 packets may use. Per node, a single priority 1 packet, being already

transmitted, causes an interference of at most 16 PSUs.

Additional_DS_P3_PSU = DS_ASG_P3 + 16 : For a victim P3 packet, only the additional sessions

going into port B and one already transmitted, low priority max sized packet are adding P3 interfering

PSUs.

US NPA (Asymmetrical port)

The SDME shall add to the received NPA „Priority x US PSU‟ sub fields the following values:

Additional_US_P1_PSU = US_ASG_P1 + US_BSG_P2 + US_BSG_P3+19 : For a victim P1 packet,

only the additional sessions going into port B are adding P1 interfering PSUs while Priority 2 and 3

streams may re-interfere with P1 packet at each SDME. At each SDME the Ethernet payload adds at

most 19 additional PSUs.

Additional_US_P2_PSU = US_BSG_P2 + US_BSG_P3 + 19 + 8 : For a victim P2 packet, other

Priority 2 and Priority 3 streams may re-interfere with the victim P2 packet at each SDME. At each

SDME the Ethernet payload adds at most 19 additional PSUs and a single priority 1 packet, being

already transmitted, causes an interference of at most 8 PSUs.

Additional_US_P3_PSU = US_ASG_P3 + 19 + 8 : For a victim P3 packet, only the additional

sessions going into port B, the Ethernet payload and one already transmitted, low priority max sized

packet are adding P3 interfering PSUs.


188

Confidential

US NPA (Symmetrical port)

The SDME shall add to the received NPA „Priority x US PSU‟ sub fields the values calculated as for the DS

NPA case.

MXPM NPA

When the SNPM is mixed-path (MXPM) the two NPA Path Availability subfields shall be calculated as US

NPAs. The first subfield (DS) shall hold the NPA at the message propagation direction, while the second

subfield (US) shall hold the NPA at the opposite direction.

5.2.6 Broadcast SNPM

Broadcast Intra SNPMs shall be used to create Intra sub network restricted, broadcast messaging between

SDMEs. PDMEs shall also use broadcast Edge SNPM to communicate with their SDME link partner but these

messages shall not be propagated by the SDME.

SDMEs shall send their Intra Sub Network broadcast SNPM (messages sent to their Intra ports) encapsulated

within Ethernet packets.

SDMEs shall accept broadcast SNPM received in both Ethernet and HLIC encapsulations.

The following figure depicts the, broadcast SNPM, HD-CMP OpCode and payload formats:


HD-CMP

Msg OpCode

Network Path

AvailabilityType Specific payload

2 Bytes 10 bytes Variable Length

PDS Entries

Max Count: N

1 Byte

PDS Entries

Occ Count

1 Byte

PDS Entry

N

10 Bytes

PDS Entry

1 …

10 Bytes

Type

b0b15 b8

0 0 0 0 0 0 0 0 Dir0 0

Figure 142: Broadcast SNPM HD-CMP OpCode and Payload Formats

HD-CMP OpCode - The broadcast/unicast bit (b8) shall be set to zero and the „Mod‟ field shall be

set to zero („All Ports‟).

PDS - The HD-CMP payload shall start with a Path Description Section (see ‎5.2.4.1). The

generator entity of the message shall allocate/initialize the proper section size and each

intermediate device shall update the PDS properly before propagating it.

NPA – The payload continues with the Network Path Availability section (see ‎5.2.4.2). The


intermediate device shall update the NPA properly before propagating it.

Type Specific Payload – This section format is defined per message type.


189

Confidential

5.2.6.1 Broadcast SNPM Propagation Rules

A SDME shall propagate a received broadcast SNPM according to the following rules:

1. A received Broadcast SNPM, which contains a PDS entry occupied with the receiving device

ID (A loop is detected), shall be discarded

2. A received Broadcast SNPM, which contains an already full PDS (Number of occupied

entries is equal to PDS max entries) shall not be propagated

3. A Broadcast SNPM, received from an Edge Port, shall not be propagated

4. A Broadcast SNPM shall not be propagated towards Edge Ports

5. A Bi-Directional port shall be considered as both a downstream input port and a downstream

output port implemented on the same port

6. Broadcast Downstream SNPM (B_DSPM): When received from a downstream input, shall

be propagate to all other downstream outputs and shall be propagated as a MXPM to all

other downstream inputs

7. Broadcast Upstream SNPM (B_USPM): When received from a downstream output, shall

be propagated to all other downstream inputs and shall be propagated as a MXPM to all

other downstream outputs

8. Broadcast Mixed Path SNPM (B_MXPM): When received from a port, shall be propagated to

all other ports

5.2.6.2 Broadcast SNPM Types

Periodic SNPMs and Update SNPMs are the only broadcast SNPM types defined in this specification. Future

specification may add additional types. In order to support future types, SDMEs complying with this

specification shall propagate all broadcast SNPMs regardless of their „Type‟ sub field value.

5.2.6.3 Periodic SNPM

Periodic SNPMs are used by the PDMEs/SDMEs to broadcast their capabilities, discover their directional

connectivity and to collect network paths availabilities:

• Each T-Adaptor shall identify its connected native edge device, collect its capabilities, using various

methods according to the T-Adaptor type and report the information to its local PDME/SDME

• Each PDME shall generate periodic Edge SNPMs, on behalf of all its T-Groups and their associated

T-Adaptors, towards its connected edge SDME. The PDME shall send these messages periodically

with an interval of 2 seconds +/- 100mSec between consecutive periodic messages.

• Each edge SDME shall generate periodic intra SNPMs, towards its intra ports, on behalf of all its

directly connected end nodes and on behalf of all the integrated T-Adaptors/T-Groups in this switch

device. The edge SDME shall send these intra messages periodically with an interval of 3 seconds

+/- 100mSec between consecutive periodic messages.


190

Confidential

• Each SDME shall propagate periodic SNPMs which it receives through its intra ports towards its

other intra ports according to the SNPM propagation rules

• The periodic SNPMs allow each SDME to learn/store which T-Adaptors exist in the T-Network, what

are their capabilities and their directional connectivity from this SDME

• Each edge SDME shall generate periodic edge SNPMs towards its edge ports conveying to its

connected PDMEs its knowledge about all the other, directionally connected, T-Adaptors in the T-

Network. The edge SDME shall send these edge messages periodically with an interval of 2

seconds +/- 100mSec between consecutive periodic messages

• Each PDME/SDME conveys to each of its embedded T-Adaptors all the needed information

regarding other T-Adaptors, considering the directional connectivity and type of those other T-

Adaptors

• SDMEs are also using those periodic SNPMs to build a switching table, marking which entities are

accessible, per direction, through which port devices of the switch, with how many hops and with

what network path availability

• On standby mode, periodic SNPMs continue to flow using the LPPF #1 and #2 modes of operation:

• Switch ports shall support LPPF #2 (HDSBI + Ethernet)

• End node ports do not have to support Ethernet and may use HD-CMP over HLIC over

HDSBI in LPPF #1

The following figure depicts the HD-CMP OpCode and payload format of the Periodic SNPM:


HD-CMP

Msg OpCode

Network Path

Availability

Device xxxxxx

Info

2 Bytes 10 bytes Variable Length

…

Device zzzzzz

Info

Variable Length

0x0001 – Periodic downstream SNPM

0x0002 – Periodic upstream SNPM

0x0003 – Periodic mix path SNPM

PDS Entries

Max Count: N

1 Byte

PDS Entries

Occ Count

1 Byte

PDS Entry

N

10 Bytes

PDS Entry

1 …

10 Bytes

Devices Info Section

Figure 143: Periodic SNPM HD-CMP OpCode and Payload Format

HD-CMP OpCode – A broadcast SNPM has a „Type‟ field equal zero and three directional options

(DSPM, USPM and MXPM)

PDS – Like every broadcast SNPM, the HD-CMP payload shall start with a Path Description

Section (see section ‎5.2.4.1)

o Periodic Edge SNPMs shall contain a “PDS Entries Max Count” of zero and a “PDS

Entries Occ Count” of zero with no PDS entries, since these messages are not propagated

throughout the network

o Periodic Intra SNPMs shall contain a “PDS Entries Max Count” value of 7


191

Confidential

o Future devices may use other PDS sizes so propagating SDMEs shall not assume these

sizes (0 or 7)

NPA – Like every broadcast SNPM, the payload continues with the Network Path Availability

section (see ‎5.2.4.2)

Devices Info Section – The rest of the payload is a variable length series containing a DIS (Device

Info Section) per reported device (see ‎5.2.4.4). This section shall be built by the generator entity of

the SNPM describing end node and edge switch devices with their embedded T-Groups and T-

Adaptors. Propagating SDMEs shall not update/change this section. Upon reception of a periodic

SNPM with a loop (identified using the PDS), the information conveyed in this section shall be

discarded and shall not be learned/stored by the receiving entity.

Only edge SDMEs shall generate periodic Intra SNPMs:

o Periodic Intra DSPMs shall be generated towards all downstream output ports conveying

information “learned” from edge DSPMs.

o Periodic Intra USPMs shall be generated towards all downstream input ports conveying

information “learned” from edge USPMs.

o Periodic Intra MXPMs shall be generated towards each port conveying all information

“learned” from edge SNPMs which was not already sent to that port in periodic DSPMs or

USPMs.

o Embedded active T-adaptors shall be treated as virtual edge node. The internal

connectivity between the embedded T-Adaptors and the switching function within the

switch device is implementation depended, and may be DS, US, or Bi-Directional.

Embedded T-Adaptor information shall be reported accordingly in the proper directional

periodic SNPM.

o When generating periodic Intra SNPMs, encapsulated in Ethernet frames, the max packet

size shall be limited to 1500 bytes and each DIS entry within the packet shall be

complete. The Edge SDME shall send all the relevant information using a minimum

number of Ethernet packets.


192

Confidential

5.2.6.4 Informative - Periodic SNPM Generation and Propagation

Examples

Example 1:

S1

S2

S3 S4

S5

E1E2

E3

E5

E4

E6

E7E8

2

12

34

1

2

34

12

13

1

2

3

3

4

4

DSPM: E8

USPM: E2

USPM: E

1

DSPM

: E3 D

SPM

: E4

USPM

: E6

USPM

: E7

S1

S1

1

1

E1

E1

Edge Switch

Intra Switch

Edge Port

Intra Port

End Node device

Embedded T-Adaptors

Edge Link

Intra Link

1 Virtual Edge Port


Ethernet Termination4

Figure 144: PDMEs Generating Periodic Edge SNPMs – Example

Each end node PDME generates edge SNPMs according to the directionality of its link, for example E8,

E3, and E4 are generating periodic DSPM messages towards their downstream outputs.

End nodes which do not provide Ethernet termination (E3, E4) transmit their edge SNPM over HLIC.


193

Confidential

Example 2:

S1

S2

S3 S4

S5

E1E2

E3

E5

E4

E6

E7E8

2

12

34

1

2

34

12

13

1

2

3

3

4

4

USPM: E1, E2

MXPM: E8

DSPM: E3, E4

DSPM: E3, E4

USPM: E7, E6

MXPM: E7, E6

DSPM: E

5

MXPM: E5

MXPM

: E5

This is an HDMI

Source T-Adaptor

S1

S1

1

1

E1

E1

Edge Switch

Intra Switch

Edge Port

Intra Port

End Node device

Embedded T-Adaptors

Edge Link

Intra Link

1 Virtual Edge Port



Figure 145: Edge SDMEs Generating Periodic Intra SNPMs – Example

Periodic Intra SNPMs are generated only towards intra ports. For example, S1 generates Intra SNPMs

only towards port 4 which is its only Intra port.

Periodic Intra SNPMs convey information regarding all end nodes connected to this Edge SDME. Since

port 4 is a downstream input, S1 generates a periodic USPM towards port 4 reporting the information of E1

and E2, which was learned by S1 from previous edge USPMs. Additionally, S1 sends a MXPM to port 4

reporting the information from E8 learned from previous DSPMs, E1 and E2 are not reported in this MXPM

since they were already reported by the USPM towards port 4.

Generated Intra SNPMs convey information learned only from previous Edge SNPM and embedded T-

Adaptors info. For example, S3 generates DSPMs towards ports 1 and 4 reporting E3 and E4 but S3 does

not generate MXPMs nor reports E5 since the information regarding E5 arrives to S3 using Intra SNPMs and

not edge SNPMs. S4 reports E5 in its generated Intra SNPMs since E5 is an embedded T-Adaptor within S4.

Since the internal connectivity inside S4 through the virtual edge port 4 is considered, by S4, as downstream

input (E5 is a HDMI source T-Adaptor), it reports E5 in MXPMs to its other downstream inputs and as DSPMs

to its downstream output.

Periodic Intra SNPMs are generated only by Edge SDMEs. S2 does not generate any SNPMs, it only

propagates SNPMs, since it does not have any edge ports nor embedded T-Adaptors.


194

Confidential

Example 3:

S1

S2

S3 S4

S5

E1E2

E3

E5

E4

E6

E7E8

2

12

34

1

2

34

12

13

1

2

3

3

4

4

DSPM: E3, E4

This is an HDMI

Source T-Adaptor

S1

S1

1

1

E1

E1

Edge Switch

Intra Switch

Edge Port

Intra Port

End Node device

Embedded T-Adaptors

Edge Link

Intra Link

1 Virtual Edge Port



Figure 146: Propagating Periodic Intra SNPMs – Example - Step 1

S3 generates a periodic intra DSPM conveying the information collected from E3 and E4.

S1

S2

S3 S4

S5

E1E2

E3

E5

E4

E6

E7E8

2

12

34

1

2

34

12

13

1

2

3

3

4

4

DSPM: E3, E4

This is an HDMI

Source T-Adaptor

S1

S1

1

1

E1

E1

Edge Switch

Intra Switch

Edge Port

Intra Port

End Node device

Embedded T-Adaptors

Edge Link

Intra Link

1 Virtual Edge Port



DSPM: E3, E4

DSPM: E3, E4

MXPM: E3, E4


S2 propagates the incoming DSPM to its downstream outputs (1 and 3) and as a MXPM to its other

downstream input.


195

Confidential

S1

S2

S3 S4

S5

E1E2

E3

E5

E4

E6

E7E8

2

12

34

1

2

34

12

13

1

2

3

3

4

4

DSPM: E3, E4

This is an HDMI

Source T-Adaptor

S1

S1

1

1

E1

E1

Edge Switch

Intra Switch

Edge Port

Intra Port

End Node device

Embedded T-Adaptors

Edge Link

Intra Link

1 Virtual Edge Port



DSPM: E3, E4

DSPM: E3, E4

MXPM: E3, E4

DSPM: E

3, E4

MXPM: E3, E4

MXP

M: E

3, E

4

Will be dropped by

loop protection


S1 does not propagate the incoming DSPM since it does not have other intra ports.

S5 receives a MXPM through port 2 and propagates it to its other intra port (1).

S4 receive a DSPM through port 2 and propagates it to its downstream output (3). It also converts it to a

MXPM towards its downstream input (1).


196

Confidential

S1

S2

S3 S4

S5

E1E2

E3

E5

E4

E6

E7E8

2

12

34

1

2

34

12

13

1

2

3

3

4

4

DSPM: E3, E4

This is an HDMI

Source T-Adaptor

S1

S1

1

1

E1

E1

Edge Switch

Intra Switch

Edge Port

Intra Port

End Node device

Embedded T-Adaptors

Edge Link

Intra Link

1 Virtual Edge Port



DSPM: E3, E4

DSPM: E3, E4

MXPM: E3, E4

DSPM: E

3, E4

MXPM: E3, E4

MXP

M: E

3, E

4

Will be dropped by

loop protection

DSPM: E3, E4

MXPM

: E3, E4

MXPM: E3, E4


S3 receives through port 3 the MXPM sent by S4, checks the PDS entries, finds its own entry (discovers a

loop), and therefore discards the packet.

S4 receives through port 3 the MXPM sent by S5, and propagates it to its other intra ports (2 and 1).

S5 receives through port 1 the DSPM sent by S4, and propagates it to its other intra downstream output (2). It

does not propagate it to its edge ports (3 and 4).

In the next step, S2 will discover loops and hence discard the DSPM it receives through port 2 and the MXPM

it receives through port 3. Similarly, S3 will discard the MXPM it receives through port 4.


197

Confidential

Example 4:

S1

S2

S3 S4

S5

E1E2

E3

E5

E4

E6

E7E8

2

12

34

1

2

34

12

13

1

2

3

3

4

4

DSPM: E8, E3, E4, E5

MXPM: E2, E7, E6

DSPM: E8, E3, E4, E5

MXPM: E1, E7, E6

USPM: E1, E2

MXPM: E3, E4, E5, E7, E6

DSPM: E3, E4, E5

MXPM: E1, E2, E8, E6

DSPM: E3, E4, E5

MXPM: E1, E2, E8, E7

USPM: E1, E2, E7, E6

MXPM: E4, E5, E8 USPM: E1, E2, E7, E6

MXPM: E3, E5, E8

S1

S1

1

1

E1

E1

Edge Switch

Intra Switch

Edge Port

Intra Port

End Node device

Embedded T-Adaptors

Edge Link

Intra Link

1 Virtual Edge Port



Figure 150: Edge SDMEs Generating Periodic Edge SNPMs – Example

Each Edge SDME generates per each edge port an edge SNPM according to the directionality of the port, for

downstream input ports: USPM and for downstream output ports: DSPM. Each SNPM conveys all the

information learned from received intra SNPMs of the same type (DSPM/USPM) and information about its

embedded T-Adaptors (S4 does not generates edge SNPMs since it does not have edge ports only the virtual

edge port (4)). The rest of the end nodes‟ information is reported per port with an additional MXPM such that

each device is aware of all devices in the sub network.

Since E4 does not provide Ethernet termination, S3 sends its SNPMs over HLIC.


198

Confidential

5.2.6.5 Informative – PDS Usage in SNPM Example

S1

S2

S3 S4

S5

E1E2

E3

E5

E4

E6

E7E8

2

12

34

1

2

34

12

13

1

2

3

3

4

4

DSPM: E3, E4

This is an HDMI

Source T-Adaptor

S1

S1

1

1

E1

E1

Edge Switch

Intra Switch

Edge Port

Intra Port

End Node device

Embedded T-Adaptors

Edge Link

Intra Link

1 Virtual Edge Port



000

000

000

000

000

000

10S3

Output

Port

Input

Port

Device

000

000

000

000

000

000

10S3

Output

Port

Input

Port

Device

Max Count: 7 Occ Count: 1

PDS

E3

Figure 151: PDS Usage in Periodic DSPM – Example – Step 1

S3 generates a periodic intra DSPM towards port 1, initializes the PDS to 7 zeroed entries, puts its ID in the

first entry, sets the input port to zero and the output port to 1 and sets the Occ Count to 1.

S1

S2

S3 S4

S5

E1E2

E3

E5

E4

E6

E7E8

2

12

34

1

2

34

12

13

1

2

3

3

4

4

DSPM: E3, E4

This is an HDMI

Source T-Adaptor

S1

S1

1

1

E1

E1

Edge Switch

Intra Switch

Edge Port

Intra Port

End Node device

Embedded T-Adaptors

Edge Link

Intra Link

1 Virtual Edge Port



000

000

000

000

000

000

10S3

Output

Port

Input

Port

Device

000

000

000

000

000

000

10S3

Output

Port

Input

Port

Device


PDS

DSPM: E3, E4

PDS

E3

000

000

000

000

000

34S2

10S3

Output

Port

Input

Port

Device

000

000

000

000

000

34S2

10S3

Output

Port

Input

Port

Device


E3



199

Confidential

S2 checks the PDS of the DSPM it receives from port 4, and since it cannot find its own ID in it (no loop)

properly fills the next PDS entry and propagates the message to port 3.

S1

S2

S3 S4

S5

E1E2

E3

E5

E4

E6

E7E8

2

12

34

1

2

34

12

13

1

2

3

3

4

4

DSPM: E3, E4

This is an HDMI

Source T-Adaptor

S1

S1

1

1

E1

E1

Edge Switch

Intra Switch

Edge Port

Intra Port

End Node device

Embedded T-Adaptors

Edge Link

Intra Link

1 Virtual Edge Port



000

000

000

000

000

000

10S3

Output

Port

Input

Port

Device

000

000

000

000

000

000

10S3

Output

Port

Input

Port

Device


PDS

DSPM: E3, E4

E3

000

000

000

000

12S4

34S2

10S3

Output

Port

Input

Port

Device

000

000

000

000

12S4

34S2

10S3

Output

Port

Input

Port

Device


PDS

E3

000

000

000

000

000

34S2

10S3

Output

Port

Input

Port

Device

000

000

000

000

000

34S2

10S3

Output

Port

Input

Port

Device


MXPM: E3, E4

PDSE3

S3 will drop this

message since its device

ID already appears in

the PDS


S4 checks the PDS of the DSPM it receives from port 2, and since it cannot find its own ID in it (no loop)

properly fills the next PDS entry and propagates the message as a MXPM to port 1.

In the next stage, S4 will check the PDS of the MXPM it receives from port 4, and since it will find its own ID in

it (loop is detected) will discard it.

5.2.6.6 Update SNPM

Update SNPMs are used by the PDMEs/SDMEs to broadcast, to the sub network, a change in their

capabilities/status. The Update SNPMs shall use the same message format as the Periodic SNPMs (see

section ‎5.2.6.3) with the exception that the „Type‟ sub field within the HD-CMP OpCode shall contain the

value „one‟ (and not „zero‟ as in Periodic SNPMs). The Devices Info Section in the message shall contain

DISs of devices with changed information. Each DIS in the update SNPM shall contain the relevant TPGs and

T-Adaptors with changed information. The PDME/SDME should minimize the unchanged information sent by

the Update SNPM message to reduce unnecessary network traffic.


200

Confidential

5.2.7 Unicast SNPM

Unicast SNPMs (U_SNPM) shall be used to create sub network restricted messages between source and

final destination management entities, passing all intermediate management entities on the network path

between them. Unlike broadcast SNPMs which propagate, according to a certain direction, to all available sub

network links without a specific final destination entity, a unicast SNPM conveys a source entity and a final

destination entity and the propagation of the message is stopped at the final destination. The motivation for

U_SNPM is to query/search-for a network path between two management entities and/or to collect information

from / configure the devices along a path. These functionalities are needed for example for session creation,

termination and maintenance.

SDMEs propagate U_SNPMs to their link partners in a similar way to Periodic SNPMs with additional

restrictions according to the HD-CMP Op Code and the final destination entity reference.

When a U_SNPM reaches its final destination entity or an edge SDME which is connected to this final

destination device its propagation is stopped by the SDME.

Unlike Periodic SNPMs, edge U_SNPMs are also propagated by the SDMEs. This allows PDMEs to send

U_SNPMs to other PDMEs.

SDMEs and PDMES should send their U_SNPMs encapsulated within HLIC packets.

SDMEs and PDMEs shall accept U_SNPMs received in both Ethernet and HLIC encapsulations.

The following figure depicts the, U_SNPM, HD-CMP OpCode and payload formats:

HD-CMP

Msg OpCode

Network Path

Availability

2 Bytes 12 bytes

Final Target

Reference

8 Bytes

Real Source

Reference

8 Bytes

PDS

Variable Length

Per Op Code U_SNPM

Body

Variable Length

0 0 0 0 0 0 0 1 DirMod

Session ID

Query

1 or 33 Bytes

Figure 154: U_SNPM HD-CMP OpCode and Payload Formats

HD-CMP OpCode:

o Broadcast/unicast bit (b8) shall be set to one

o Type – A four bit field which defines up to 16 types of U_SNPM

o Mod – A two bit field which determines the U_SNPM directional propagation method:

00 – „All Ports‟: Propagate to all ports with the proper direction according to the

type of the U_SNPM (U_DSPM, U_USPM and U_MXPM)

01 – „With Path‟: Propagate to all proper directional ports with known path to the

final destination device

10 – „Best Path‟: Propagate only to the proper directional port with the best path

to the final destination device

11 – „By PDS‟: Propagate according to the PDS list within this message

o Dir – A Two bit field which defines the propagation directionality of this message:


201

Confidential

00 – Not in Use : shall be discarded upon reception

01 – U_DSPM : downstream SNPM, shall be propagated only to downstream

outputs

10 – U_USPM : upstream SNPM, shall be propagated only to downstream inputs

11 – U_MXPM : mixed path SNPM, shall be propagated to both downstream

inputs and outputs

Final Destination Entity Reference (FDER)- The HD-CMP payload shall start with an eight byte

(Device ID : TPG) reference to the final destination management entity of this message. This field

shall be propagated intact along the network path and shall be used, by the intermediate SDMEs,

in conjunction with the OpCode to determine the proper propagation.

Real Source Entity Reference (RSER) - The HD-CMP payload shall continue with an eight byte

(Device ID : TPG) reference to the source management entity of this message. This field shall be

propagated intact along the network path.

PDS - The HD-CMP payload shall continue with a Path Description Section (see section ‎5.2.4.1).

The generator entity of the message shall allocate/initialize the proper section size and each

intermediate device shall update the PDS properly before propagating it.

NPA – The payload continues with the Network Path Availability section (see section ‎5.2.4.2). The


intermediate device shall update the NPA properly before propagating it.

Session ID Query (SIQ) - The SIQ field is used to find out which are the active/already allocated

session ids (SIDs) along the network path. The SIQ field comprises a series of 32 bytes which

creates a bitmap of 256 bits. The most significant bit of the first transmitted byte is marking the

existence of the SIQ field and the other 255 bits each represents a SID. The following figure depicts

the SIQ format:

E

…

32 Bytes

b0b7b0b7

Byte 0Byte 1Byte 31 Byte 30SIQ Exists

Flag

Represents

SID 1

Represents

SID 8

Represents

SID 255

Represents

SID 248

b6

Figure 155: U_SNPM Session ID Query Format

o SIQ Exists Flag: Byte 31 is transmitted first and the MSB (b7) in this byte, represents, if

set to one, the existence of the SIQ in this message. If the flag is zero then only byte 31

shall be transmitted. The U_SNPM generating entity shall set this flag according to the

U_SNPM message type.


202

Confidential

o SIQ Bitmap: Defined only when „SIQ Exists Flag‟ is set to one, and holding a bitmap of

255 bits (using 32 bytes) each bit represents a session id (SID), starting from SID 1 to SID

255. When sending the SIQ, the generating entity shall allocate a zeroed 255 bit map.

Each SDME, on the message path, shall set to one the proper bits in the SIQ bitmap

according to all allocated SIDs passing through any port of this SDME (not just the ports

this message arrive or continue through), such that at the end of the U_SNPM “journey”

the SIQ entries bitmap shows all the active / allocated session IDs along the network path.

Propagating SDMEs shall not clear to zero any bitmap bit.

Body: The rest of the U_SNPM message shall be constructed according to the message type

defined by the HD-CMP OpCode.

5.2.7.1 Unicast SNPM Propagation Rules

SDMEs shall propagate, a received U_SNPM, according to the following rules:

1. A received Intra U_SNPM, which contains a PDS entry occupied with the receiving device ID

(loop detected), shall be discarded.

2. A received U_SNPM, which contains an already full PDS (Number of occupied entries is

equal to PDS max entries) shall not be propagated.

3. SDMEs which receive a U_SNPM, with a Final Destination Entity Reference (FDER) field

matching an entity in the receiving switch device, shall not propagate the message to any of

its ports.

4. Edge SDMEs which receive a U_SNPM, with a FDER field matching a PDME which is

directly connected in a proper direction according to the OpCode‟s „Dir‟ sub field, shall

propagate the message to the edge port directly attached to this PDME and shall not

propagate the message to any other port.

5. Edge SDMEs which receive a U_SNPM, with a FDER field matching a PDME which is

directly connected not in the proper direction according to the OpCode‟s „Dir‟ sub field, shall

discard the message.

6. A „By PDS‟ („Mod‟ sub field in the OpCode equals 11) U_SNPM shall be propagated

according to the „By PDS‟ rules (see section ‎5.2.4.1) regardless of the OpCode‟s „Dir‟ sub

field content.

7. SDMEs receiving a „By PDS‟ U_SNPM identifying that it is the last device on the message

path (last PDS entry when Occ Count is positive or first PDS entry when Occ Count is

negative, see section ‎5.2.4.1) shall compare the device id portion of the message FDER to

its own device id:

a. When device ids matches – The SDME shall check the Port ID sub field of the

FDER and if it matches a PDME “borrowed” identity (see section ‎5.1.4.3), it shall

forward the message to that, directly attached, matching PDME.


203

Confidential

b. When device ids do not match – The SDME shall check the directly attached PDME

device ids and if it finds a matching one, it shall forward the message to that,

directly attached, matching PDME.

8. A Bi-Directional port shall be considered as both a downstream input port and a downstream

output port implemented on the same port.

9. Non „By PDS‟, Unicast Downstream SNPM (U_DSPM): When received from a downstream

input, shall be propagated, according to the „Mod‟ sub field, to all, matching, other

downstream outputs.

10. Non „By PDS‟, Unicast Upstream SNPM (U_USPM): When received from a downstream

output, shall be propagated, according to the „Mod‟ sub field, to all, matching, other

downstream inputs.

11. Non „By PDS‟, Unicast Mixed Path SNPM (U_MXPM): When received from a port, shall be

propagated, according to the „Mod‟ sub field, to all, matching, ports.

12. SDMEs receiving a „Best Path‟ U_SNPM, with a FDER field not matching an entity in the

receiving switch device, which cannot find a best path port, with the proper directionality as

conveyed in the „Dir‟ sub field, shall change the „Mod‟ sub field to „With Path‟ and try to

propagate the modified message.

13. SDMEs receiving a „With Path‟ U_SNPM, with a FDER field not matching an entity in the

receiving switch device or trying to propagate a message which was modified to „With Path‟,

which cannot find a port with a path to that FDER with the proper directionality as conveyed in

the „Dir‟ sub field, shall change the „Mod‟ sub field to „All Ports‟ and try to propagate the

modified message.

14. SDMEs receiving an „All Ports‟ U_SNPM, with a FDER field not matching an entity in the

receiving switch device or trying to propagate a message which was modified to „All Ports‟,

which cannot find a port with the proper directionality as conveyed in the „Dir‟ sub field, shall

discard the message.


204

Confidential

5.2.7.2 Informative – ‘With Path’ U_DSPM Propagation Example

0 1x x x x

S1

S2

S3 S4

S5

E1E2

E3

E5

E4

E6

E7E8

2

12

34

1

2

34

12

13

1

2

3

3

4

4

“With Path” U_DSPM:

From E3 to E7

This is an HDMI

Source T-Adaptor

S1

S1

1

1

E1

E1

Edge Switch

Intra Switch

Edge Port

Intra Port

End Node device

Embedded T-Adaptors

Edge Link

Intra Link

1 Virtual Edge Port



000

000

000

000

000

000

10E3

Output

Port

Input

Port

Device

000

000

000

000

000

000

10E3

Output

Port

Input

Port

Device


PDS

E3

0 0 0 0 0 0 0 1 0 1

Mod Dir

HD-CMP Op Code

Figure 156: ‘With Path’ U_DSPM Propagation – Example – Step 1 - Generation

E3 generates a „With Path‟ U_DSPM targeting E7 towards port 1, initializes the PDS to 7 zeroed entries, puts

its own ID in the first entry, sets the input port to zero and the output port to 1 and sets the Occ Count to 1.

S1

S2

S3 S4

S5

E1E2

E3

E5

E4

E6

E7E8

2

12

34

1

2

34

12

13

1

2

3

3

4

4


From E3 to E7

This is an HDMI

Source T-Adaptor

S1

S1

1

1

E1

E1

Edge Switch

Intra Switch

Edge Port

Intra Port

End Node device

Embedded T-Adaptors

Edge Link

Intra Link

1 Virtual Edge Port



000

000

000

000

000

12S3

10E3

Output

Port

Input

Port

Device

000

000

000

000

000

12S3

10E3

Output

Port

Input

Port

Device


E3

PDS


From E3 to E7

E3

000

000

000

000

000

42S3

10E3

Output

Port

Input

Port

Device

000

000

000

000

000

42S3

10E3

Output

Port

Input

Port

Device


PDS

Figure 157: ‘With Path’ U_DSPM Propagation – Example – Step 2 - First Propagation


205

Confidential

S3 propagates the „With Path‟ U_DSPM towards its DS outputs (ports 1 and 3) since from both of them there

is a DS path to E7. Per propagated message S3 updates the PDS accordingly and sets the Occ Count to 2.

Note that S3 does not propagate the message to port 3 since it is not a DS output with a path to E7.

S1

S2

S3 S4

S5

E1E2

E3

E5

E4

E6

E7E8

2

12

34

1

2

34

12

13

1

2

3

3

4

4


From E3 to E7

This is an HDMI

Source T-Adaptor

S1

S1

1

1

E1

E1

Edge Switch

Intra Switch

Edge Port

Intra Port

End Node device

Embedded T-Adaptors

Edge Link

Intra Link

1 Virtual Edge Port



000

000

000

000

34S2

12S3

10E3

Output

Port

Input

Port

Device

000

000

000

000

34S2

12S3

10E3

Output

Port

Input

Port

Device


E3

PDS


From E3 to E7

E3

000

000

000

000

31S4

42S3

10E3

Output

Port

Input

Port

Device

000

000

000

000

31S4

42S3

10E3

Output

Port

Input

Port

Device


PDS

S2 doesn’t propagate

to port 1 since Port 1

doesn’t have a DS

path to E7

Figure 158: ‘With Path’ U_DSPM Propagation – Example – Step 3 - Second Propagation

S2 propagates the „With Path‟ U_DSPM towards port 3 since it is a DS output with a path to E7. S2 does not

propagate the message to port 1 since port 1 (which is also a DS output) does not have a DS path to E7. S4

propagates the „With Path‟ U_DSPM, received from port 1, towards port 3 since it is a DS output with path to

E7.


206

Confidential

S1

S2

S3 S4

S5

E1

E2

E3

E5

E4

E6

E7E8

21

2

3

4

1

2

34

12

13

1

2

3

3

4

4


From E3 to E7

This is an HDMI

Source T-Adaptor

S1

S1

1

1

E1

E1

Edge Switch

Intra Switch

Edge Port

Intra Port

End Node device

Embedded T-Adaptors

Edge Link

Intra Link

1 Virtual Edge Port



000

000

000

32S4

34S2

12S3

10E3

Output

Port

Input

Port

Device

000

000

000

32S4

34S2

12S3

10E3

Output

Port

Input

Port

Device


E3

PDS


From E3 to E7

E3

000

000

000

31S5

31S4

42S3

10E3

Output

Port

Input

Port

Device

000

000

000

31S5

31S4

42S3

10E3

Output

Port

Input

Port

Device


PDS

First, 4 hops,

message

reached E7

Figure 159: ‘With Path’ U_DSPM Propagation – Example – Step 4 - Third Propagation

S5 propagates the „With Path‟ U_DSPM, received from port 1, towards port 3, since it is a DS output and is

directly connected to E7. S5 does not propagate the message to any other port since it‟s the Edge SDME

directly connected to E7. The four hops message then arrives to E7.

S4 propagates, another „With Path‟ U_DSPM, received from port 2, towards port 3 since it is a DS output with

a path to E7.


207

Confidential

S1

S2

S3 S4

S5

E1

E2

E3

E5

E4

E6

E7E8

2

1

2

3

4

1

2

34

12

13

1

2

3

3

4

4


From E3 to E7

This is an HDMI

Source T-Adaptor

S1

S1

1

1

E1

E1

Edge Switch

Intra Switch

Edge Port

Intra Port

End Node device

Embedded T-Adaptors

Edge Link

Intra Link

1 Virtual Edge Port



000

000

31S5

32S4

34S2

12S3

10E3

Output

Port

Input

Port

Device

000

000

31S5

32S4

34S2

12S3

10E3

Output

Port

Input

Port

Device


E3

PDS

Second, 5 hops,

message

reached E7

Figure 160: ‘With Path’ U_DSPM Propagation – Example – Step 5 - Fourth Propagation

S5 propagates the second „With Path‟ U_DSPM, received from port 1, towards port 3, since it is a DS output

and is directly connected to E7. S5 does not propagate the message to any other port since it‟s the Edge

SDME directly connected to E7. The second five hops message then arrives to E7.


208

Confidential

5.2.7.3 Informative – Backwards ‘By PDS’ U_USPM Propagation

Example

x x x xS1

S2

S3 S4

S5

E2

E5

E4

E6

E7E8

2

2

3

1

2

34

12

13

1

2

3

3

4

4

This is an HDMI

Source T-Adaptor

S1

S1

1

1

E1

E1

Edge Switch

Intra Switch

Edge Port

Intra Port

End Node device

Embedded T-Adaptors

Edge Link

Intra Link

1 Virtual Edge Port



E3

“By PDS” U_USPM:

From E7 to E3

E3

31S5

31S4

42S3

10E3

Output

Port

Input

Port

Device

31S5

31S4

42S3

10E3

Output

Port

Input

Port

Device

Max Count: 4 Occ Count: -4

PDS

0 0 0 0 0 0 0 1 1 01 1

Mod Dir

HD-CMP Op Code

Figure 161: Backwards ‘By PDS’ U_USPM Propagation – Example – Step 1 - Generation

E7 generates a backwards „By PDS‟ U_USPM message targeting E3, it sets the FDER to the reference of E3

and the Real Source Entity Reference to its own reference (E7). It uses the PDS it received in the previous

example (see Figure 159), setting Max Count to four and Occ Count to minus four to mark backwards „By

PDS‟ (see section ‎5.2.4.1):

Type

HD-CMP

Msg OpCode

Network Path

Availability

2 Bytes 10 bytes

FDER

E3:1

8 Bytes

RSER

E7:1

8 Bytes

PDS

42 Bytes

Body

Variable Length

0 0 0 0 0 0 0 1 1 01 1

Session ID

Query

1 or 32 Bytes

b0b15 b8

Destination Entity

S5:3

Source Entity

E7:1

8 Bytes 8 Bytes

31S5

31S4

42S3

10E3

Output

Port

Input

Port

Device

31S5

31S4

42S3

10E3

Output

Port

Input

Port

Device


Figure 162: Backward ‘By PDS’ U_USPM Propagation – Example – Step 1 - Message Format


209

Confidential

In the next step:

S1

S2

S3 S4

S5

E2

E5

E4

E6

E7E8

2

2

3

1

2

34

12

13

1

2

3

3

4

4

This is an HDMI

Source T-Adaptor

S1

S1

1

1

E1

E1

Edge Switch

Intra Switch

Edge Port

Intra Port

End Node device

Embedded T-Adaptors

Edge Link

Intra Link

1 Virtual Edge Port



E3


From E7 to E3

E3

31S5

31S4

42S3

10E3

Output

Port

Input

Port

Device

31S5

31S4

42S3

10E3

Output

Port

Input

Port

Device


PDS

Figure 163: Backward ‘By PDS’ U_USPM Propagation – Example – Step 2 – First Propagation

S5 receives the backwards „By PDS‟ U_USPM from port 3 with “-4” Occ Count Value, it identifies that this is a

backward „By PDS‟ message and therefore it uses the input port field of the fourth PDS entry as the output

port (port 1). It sets Occ Count to “-3” to mark the next entry on the PDS for the next SDME (S4):

Type

HD-CMP

Msg OpCode

Network Path

Availability

2 Bytes 10 bytes

FDER

E3:1

8 Bytes

RSER

E7:1

8 Bytes

PDS

42 Bytes

Body

Variable Length

0 0 0 0 0 0 0 1 1 01 1

Session ID

Query

1 or 32 Bytes

b0b15 b8

Destination Entity

S4:3

Source Entity

S5:1

8 Bytes 8 Bytes


31S5

31S4

42S3

10E3

Output

Port

Input

Port

Device

31S5

31S4

42S3

10E3

Output

Port

Input

Port

Device

Figure 164: Backward ‘By PDS’ U_USPM Propagation – Example – Step 2 - Message Format


210

Confidential

In the next step:

S1

S2

S3 S4

S5

E2

E5

E4

E6

E7E8

2

2

3

1

2

34

12

13

1

2

3

3

4

4

This is an HDMI

Source T-Adaptor

S1

S1

1

1

E1

E1

Edge Switch

Intra Switch

Edge Port

Intra Port

End Node device

Embedded T-Adaptors

Edge Link

Intra Link

1 Virtual Edge Port



E3


From E7 to E3

E3

31S5

31S4

42S3

10E3

Output

Port

Input

Port

Device

31S5

31S4

42S3

10E3

Output

Port

Input

Port

Device


PDS

Figure 165: Backward ‘By PDS’ U_USPM Propagation – Example – Step 3 – Second Propagation

S4 receives the backward „By PDS‟ U_USPM from port 3 with “-3” Occ Count Value, it identifies that this is a

backward „By PDS‟ message and therefore it uses the input port field of the third PDS entry as the output port

(port 1). It sets Occ Count to “-2” to mark the next entry on the PDS for the next SDME (S3).

S1

S2

S3 S4

S5

E2

E5

E4

E6

E7E8

2

2

3

1

2

34

12

13

1

2

3

3

4

4

This is an HDMI

Source T-Adaptor

S1

S1

1

1

E1

E1

Edge Switch

Intra Switch

Edge Port

Intra Port

End Node device

Embedded T-Adaptors

Edge Link

Intra Link

1 Virtual Edge Port



E3


From E7 to E3

E3

31S5

31S4

42S3

10E3

Output

Port

Input

Port

Device

31S5

31S4

42S3

10E3

Output

Port

Input

Port

Device


PDS

Message

reached E3

Figure 166: Backward ‘By PDS’ U_USPM Propagation – Example – Step 4 – Third Propagation


211

Confidential

S3 receives the backward „By PDS‟ U_USPM from port 4 with “-2” Occ Count Value, it identifies that this is a

backward „By PDS‟ message and therefore it uses the input port field of the second PDS entry as the output

port (port 2). It sets Occ Count to “-1” to mark the next entry on the PDS for the next PDME (E3).

Finally, E3 receives the message and identifies that the message FDER is E3.

5.3 Devices & T-Network Topology Discovery

5.3.1 General

Each management entity shall discover and maintain a knowledge base regarding the HDBaseT network

according to the following, per entity, specification:

PDMEs – shall discover and maintain a knowledge base regarding all other T-Adaptors located with

the proper direction, at the same sub network, which are potential session partners for the local T-

Adaptors, associated with this PDME.

SDMEs - shall discover and maintain a knowledge base regarding all T-Adaptors located at the

same sub network with their associated devices (PDMEs and Edge SDMEs with embedded T-

Adaptors) and their directional connectivity with this SDME. Using this knowledge base, SDMEs

shall be able to compute an output port targeting a certain T-Adaptor/End-Node at the proper

directionality.

CPMEs – shall discover and maintain a knowledge base regarding all T-Adaptors with their

associated devices (PDMEs and Edge SDMEs with embedded T-Adaptors) in all reachable sub-

networks and the directional connectivity of each one of them to the others. A CPME is not required

to maintain the full topology of the network but it shall be able to present which T-Adaptors/End-

nodes can be connected to which other T-Adaptors/End-nodes.

RPE – shall conform to the CPME requirements and in addition shall discover and maintain a

knowledge base regarding all the devices in the network, the directional connectivity of each one of

them to its neighbors and the status of those connecting links.

5.3.2 PDME Functions

PDMEs shall use periodic SNPMs to report, their local T-Adaptors capabilities and status, to their attached

edge SDME:

• Each T-Adaptor shall identify its connected native edge device, collect its capabilities and status,

using various methods according to the T-Adaptor type and report them to its local PDME/SDME.

• Each PDME shall generate periodic Edge SNPMs, on behalf of all its T-Groups and their associated

T-Adaptors, towards its connected edge SDME. The PDME shall send these messages periodically

with an interval of 2 seconds +/- 100mSec between consecutive periodic messages.


212

Confidential

PDMEs shall use periodic SNPMs, sent by their directly attached edge SDME, to build their knowledge base

regarding other T-Adaptors capabilities, status and directional connectivity in the same sub network:

• Each edge SDME shall generate periodic edge SNPMs towards its edge ports conveying to its

connected PDMEs its knowledge about all the other, directionally connected, T-Adaptors in the T-

Network. The edge SDME shall send these edge messages periodically with an interval of 2

seconds +/- 100mSec between consecutive periodic messages.

• Each PDME/SDME shall convey to each of its embedded T-Adaptors all the needed information

regarding other T-Adaptors, considering the directional connectivity and type of those other T-

Adaptors

5.3.3 SDME Functions

Edge SDMEs shall use periodic SNPMs, sent by their directly attached PDMEs, to build their knowledge base

regarding the directly connected T-Adaptors capabilities, status and directional connectivity. Edge SDMEs

shall use periodic SNPMs to report, their directly connected T-Adaptors capabilities and status, to the rest of

the sub network:

• Each edge SDME shall generate periodic intra SNPMs towards its intra ports, on behalf of all its

directly connected end nodes and on behalf of all the integrated T-Adaptors/T-Groups in this switch

device. The edge SDME shall send these intra messages periodically with an interval of 3 seconds

+/- 100mSec between consecutive periodic messages.

• Each SDME shall propagate periodic SNPMs which it receives through its intra ports towards its

other intra ports according to the SNPM propagation rules.

The periodic SNPMs allow each SDME to learn/store which T-Adaptors exists in the T-Network, what are their

capabilities, status and their directional connectivity from this SDME. SDMEs shall also use these periodic

SNPMs to build a switching table, marking which end node devices are accessible, per direction, through

which port devices of the switch, with how many hops and with what network path availability.

Each SDME shall discover and maintain a knowledge base regarding all the devices which include embedded

T-Adaptors (PDMEs and Edge SDMEs with embedded T-Adaptors) located at the same sub network. Per

such device, the SDME shall also store the directly connected Edge SDME. Per Edge SDME, “this SDME”

shall store the currently “best” port ID per direction connecting to that target Edge SDME. “Best Port”, on all

directions, shall be computed in terms of largest DS available throughput as extracted from the periodic

SNPMs. Per Edge SDME‟s Best Port, “this SDME” shall store the PDS OCC_Count (number of hops) and

NPA, as extracted from the Periodic SNPM to be used for future best port computation and for the

propagation of U_SNPMs.

The following figure depicts a possible, partial, representation for S1‟s knowledge base capturing the relation

between Devices with T-Adaptors, their related Edge switches and the directional connectivity of Edge

Switches with S1, provided here as an informative clarification:


213

Confidential

140S4

101S5

440S3

Best MX Port

2 bytes Port ID

Best US Port

2 bytes Port ID

Best DS Port

2 bytes Port ID

Edge SDME

6 bytes Device ID

140S4

101S5

440S3

Best MX Port

2 bytes Port ID

Best US Port

2 bytes Port ID

Best DS Port

2 bytes Port ID

Edge SDME

6 bytes Device ID

S1

S2

S3 S4

S5

E2

E5

E4

E6

E7

E8

2

2

3

1

2

34

12

13

1

2

3

3

4

4

This is an HDMI

Source T-Adaptor

S1

S1

1

1

E1

E1

Edge Switch

Intra Switch

Edge Port

Intra Port

End Node device

Edge Link

Intra Link

1 Virtual Edge Port

E1

4

E3

4

1

DownstreamS5E6 PDME reference: E6:1

UpstreamS4E5 reference: S4:4

UpstreamS3E4 PDME reference: S3:3


UpstreamS3E3 PDME reference: E3:1

Edge SDME to T-

Adaptors Directionality

1 byte

Associated Edge SDME

6 bytes Device ID

Device with embedded T-Adaptor

8 bytes TPG Reference


UpstreamS4E5 reference: S4:4

UpstreamS3E4 PDME reference: S3:3


UpstreamS3E3 PDME reference: E3:1

Edge SDME to T-

Adaptors Directionality

1 byte

Associated Edge SDME

6 bytes Device ID

Device with embedded T-Adaptor

8 bytes TPG Reference

S1 table of its directional connectivity with the other edge switches

S1 table of other end nodes and their associated edge switches

Figure 167: S1 Partial knowledge base example – Informative

5.3.4 Control Point Functions

Control Point (CP) functions may be implemented at an end node, a switch or a pure Ethernet device. A CPME

is the management entity of a CP. A CPME shall provide Ethernet termination. The CPME functionality is

needed for the CP to present the devices in the network with their directional connectivity and to initiate

sessions.

The following figure depicts an example of a control point screen image, which can be created by the device

discovery scheme.


214

Confidential

Figure 168: Control Point Screen Presenting the Discovered Devices - Example

The CPME builds and maintains its knowledge base through interaction with the SDMEs and other CPMEs:

Device Discovery - CPMEs shall use Device Status messages sent by edge SDMEs to discover:

o T-Adaptors in the network

o The local-PDME/Edge-SDME associated with each of these T-Adaptors

o The associated edge SDME which is directly connected to the above mentioned

local PDMEs

o The directional connectivity between the T-Adaptors and their associated edge

SDME

Directional Connectivity Discovery - CPMEs shall use Device Connectivity messages sent by edge

SDMEs to discover the directional connectivity between edge SDMEs in the sub network. When

combining the information gathered from the Device Discovery and the Directional Connectivity step,

the CPME may store the directional connectivity between T-Adaptors/PDMEs in the network.

Session Route Computation – When an RPE does not exist in the network, the CPME shall use the

U_SNPM, DRS method for the computation of session sub network route/path and ID (see section

‎5.4.3). When an RPE exists in the network the CPME shall use the RPE route and ID computation

services.

In addition to the information gathered using the Device Status messages the CPME may directly access each

device HDCD, using HLIC over HD-CMP, to retrieve deeper information regarding this device properties,

capabilities and status.


215

Confidential

Multiple CPs may be functional at the same time in the HDBaseT network. In order to balance between the

number of Discovery messages sent by the SDMEs and the will to minimize general Etherent broadcasts, a

CP registration mechanism is defined. Each CPME shall broadcast periodically its existence in the network;

edge SDMEs shall track these messages and shall store an internal list of registered CPMEs. These list

entries shall be aged out if the CPME did not continue to send the registration messages. When the number

of active CPMEs is defined as “Few” the edge SDME shall send the Device Status and Directional

Connectivity messages as unicast messages to each registered CPME. When the number of active CPMEs is

defined as “Many” the edge SDME shall broadcast the Device Status and Directional Connectivity messages

to all CPMEs. The threshold number when “Few” becomes “Many” shall be stored in the SDME HDCD, as a

RW entity, with default value of 3 (3 CPs considered as “Many”, 2 are still “Few”). A CP may change this

HDCD entity value during operation.

If the active CPME list is not empty, each edge SDME shall send periodic Device and Directional Connectivity

messages, summarizing the information of all its directly connected PDMEs and its embedded T-Adaptors,

with the same period as periodic SNPMs (see section ‎5.2.6.3). Upon a detection of a change (change in its

internal T-adaptors or a received Edge update SNPM) it shall send update Device and Directional

Connectivity message.

An Edge SDME which is broadcasting Periodic/Update Device Status messages shall send its intra network,

periodic SNPM, without the DIS (not to duplicate information sent in the Device Status broadcasts).

SDMEs shall monitor Periodic/Update Device Status broadcasts and shall update their knowledge base

accordingly as if the information was received in a periodic SNPM.

5.3.5 Routing Processor Functions

The HDBaseT network enables the usage of an optional Routing Processor Entity (RPE) (see section ‎5.1.5.2)

which may be implemented, at any device, on top of the CPME functionality. The combination of RPE and CPME

provides a single entity which is aware and can maintain the full topology and status of each link in the network,

and is capable of computing the optimal route and a valid session ID for each session upon creation. For Device

and Directional Connectivity Discovery the RPE is using the CPME methods. In addition, the RPE shall build and

maintain its knowledge base about the exact topology and status of the network through Link Status messages

sent by the SDMEs/CPMEs. Using its knowledge base, the RPE shall provide session route computation

services for any management entity upon request.

While the CPME sends the CPME registration messages it shall also specify if it includes RPE functionality

allowing the SDMEs to keep track of the RPEs currently active in the network (see section ‎5.3.4). When the

number of active RPEs is defined as “Few” the SDME shall send the Link Status messages as unicast messages

to each registered RPE. When the number of active RPEs is defined as “Many” the SDME shall broadcast the

Link Status messages to all RPEs.

If the active RPE list is not empty each SDME shall send Link Status messages, summarizing the information of

all its directly connected HDBaseT links, periodically, and upon a detection of a change.


216

Confidential

5.3.6 Summary of Discovery Methods per Management Entity

The following table specifies the different discovery methods used by each management entity at the different,

possible, management entities constellations, in the HDBaseT network. Note that since the RPE contains the

functionality of a CPME, if there are no CPs there are no RPEs, if there are a “Few” RPEs there are at least a

“Few” CPs and also if there are only a “Few” CPs there are not “Many” RPEs.

Table 44: Discovery Methods per Entity

Session Possible Routes

Discovery Method

Device Directional Connectivity

Discovery Method

Device Discovery Method

PDME: By Unicast SNPM / f rom RPE

SDME: By Unicast SNPM / f rom RPE

CPME: From RPE

RPE: Link Status Broadcast

PDME: By Periodic SNPM

SDME: By Periodic SNPM

CPME: Directional Connectivity Broadcast

RPE: Directional Connectivity Broadcast


SDME: Device Status Broadcast

CPME: Device Status Broadcast

RPE: Device Status Broadcast

“Many” CPs &

“Many” RPEs



CPME: From RPE

RPE: Link Status Unicast




RPE: Directional Connectivity Broadcast




RPE: Device Status Broadcast

“Many” CPs &

“Few” RPEs



CPME: From RPE

RPE: Link Status Unicast



CPME: Directional Connectivity Unicast

RPE: Directional Connectivity Unicast



CPME: Device Status Unicast

RPE: Device Status Unicast

“Few” CPs &

“Few” RPEs

PDME: By Unicast SNPM

SDME: By Unicast SNPM

CPME: By Unicast SNPM







“Many” CPs &

No RPEs



CPME: By Unicast SNPM



CPME: Directional Connectivity Unicast



CPME: Device Status Unicast

“Few” CPs &

No RPEs







No CPs & No

RPEs

5.3.7 Device Status Messages

Device Status Messages are Direct HD-CMP messages used by CPs and SDMEs to discover devices and to

exchange status information. These messages are used in the following cases:

Periodic Device/T-Adaptor Status Notification: When CPs exists in the network, the Edge SDMEs shall

periodically send, at the same period as their periodic SNPMs, Device Status Notify messages. The messages

shall be sent using unicast or broadcast according to the number of active CP‟s in the network (see section

‎5.3.4).

Event basis (update) Device/T-Adaptor Status Notification :Whenever the status of a device or T-Adaptor is

changed the Device should generate an update SNPM towards its Edge SDME and the Edge SDME shall send

a unicast/broadcast Device Status Notify message according to the number of active CP‟s in the network (see

section ‎5.3.4).

Request/Response basis Status exchange: A device requests a device status, for example a newly attached

CP requests the device status of devices in the network.In response to a device status request, a CP sends the

device status information of all the devices that it has discovered.


217

Confidential

Rather than sending a long message of all status and capability information, sending a short message essential

for detecting active status, device failure (error) would be efficient.

Device Capability Summary Exchange: Includes Device Description - Device type, Device Model Name, and

user defined device Name.

It includes all T-Adaptor Capability - Device capability represents all available T-Adaptor Types of the device

(HDMI, Ethernet, USB, IR remote control…)

T-Adaptor capability summary information will be enough for Control point to provide the device discovery and

selection screen on the left.

T-Adaptor capability summary information will be enough for Control point to provide the device discovery and

selection screen on the left.

Since such message exchanges for device discovery (among CPs and devices) are frequent so small size of

device summary information is more efficient than large set of device information.

The detail information of each T-Adaptor would be necessary when setting up the session routing from source to

destination.

5.3.7.1 Device Status Request Message

TBD

5.3.7.2 Device Status Notify Message

When a control point receives a unicast Device Status Request, it shall respond with the device status

information of all active devices in the network, gathered from Device Status Notify messages. When a SDME

receives Device Status Request, it shall respond with device status information on behalf of all the edge

PDMEs connected to this SDME and embedded T-Adaptors within this SDME (if exist).

A control point shall keep the active device information from device status notify messages.

When a new control point discovers an existing control point with its activity value set, the new control point

may not need to discover all the other HDBaseT devices. Instead, it can receive the discovered device

information from the existing control point.

5.3.7.3 Active Device Time Out

A control point must check for Active Device Time Out. To do this, the control point sets the interval

Tdevice_active [TBD sec] for a device at the time of receiving a Device Status Notify reporting that device. If

such a message do not arrive within Tdevice_active the device is removed from the active device list. The

control point must perform this check at least once in each Tdevice_active interval.


218

Confidential

5.3.8 SDMEs Directional Connectivity (SDC) Messages

Directional Connectivity Messages are Direct HD-CMP messages used by CPs to discover the directional

connectivity between SDMEs in the sub network. These messages are used in the following cases:

Periodic SDC Notification: When CPs exists in the network, the Edge SDMEs shall periodically send, at the

same period as their periodic SNPMs, SDC Notify messages to notify their directional connectivity with all other

Edge SDMEs in the sub-network. The messages shall be sent using unicast or broadcast according to the

number of active CP‟s in the network (see section ‎5.3.4).

Event basis (update) SDC Notification: Whenever the Directional Connectivity of Edge SDME with another

edge SDME is changed, the Edge SDME shall generate a unicast/broadcast SDC notify message according to

the number of active CP‟s in the network (see section ‎5.3.4), Containing only the changed information.

Request/Response basis Status exchange: A CP requests a SDC response from a SDME or from another

CP, for example a newly attached CP requests the SDC status of devices in the network from another CP.In

response to a SDC request, a CP sends the SDC information of all the devices that it has discovered.

5.3.8.1 SDME Directional Connectivity Request Message

TBD

5.3.8.2 SDME Directional Connectivity Notify Message

TBD

5.3.9 SDME Link Status (SLS) Messages

Link status Messages are Direct HD-CMP messages used by RPEs to discover the network topology and

status. Each SLS notify message conveys the directionality and status of the links connecting SDMEs with their

neighboring devices. These messages are used in the following cases:

Periodic SLS Notification: When RPEs exists in the network, SDMEs shall periodically send, at the same

period as periodic SNPMs, SLS Notify messages to notify their direct links status. The messages shall be sent

using unicast or broadcast according to the number of active RPE‟s in the network (see section ‎5.3.5).

Event basis (update) SLS Notification :Whenever a direct link status is changed, the SDME shall generate a

unicast/broadcast SLS notify message according to the number of active RPE‟s in the network (see section

‎5.3.5), Containing only the changed information.

Request/Response basis Status exchange: A RPE requests a SLS response from a SDME or from another

RPE, for example a newly attached RPE requests the SLS from a SDME. In response to a SLS request, the

SDME sends the SLS information of all its direct links.

5.3.9.1 SDME Link Status Request Message

TBD


219

Confidential

5.3.9.2 SDME Link Status Notify Message

TBD

5.3.10 CPME Registration (CPR) Message

CPME Registration Message is a Broadcast HD-CMP message sent by the CPME/RPE to notify all SDMEs

and other CPMEs, its existence in the network (see ‎5.3.4 and ‎5.3.5) and its capabilities. Each CPME shall

broadcast periodically with a period of 4 seconds its existence in the network upon a change in the CPME

status for example when the CPME starts to function it also shall broadcast CPR message. Edge SDMEs

shall track these messages and shall store an internal list of registered CPMEs. If a Edge SDME does not

receive CPR from a certain registered CPME for more than 13 seconds, the SDME shall delete this CPME

from the registered CPME list. All SDMEs shall track these messages sent by CPMEs with RPE capability

and shall store an internal list of registered RPEs. If a SDME does not receive CPR from a certain registered

RPE for more than 13 seconds, the SDME shall delete this RPE from the registered RPE list.

5.3.10.1 CPR Message Format

TBD

5.4 T-Network Sessions

5.4.1 General

In order for a T-Adaptor to communicate over the T-Network, with another T-Adaptor, a session must be

created. The session defines a bi-directional communication, sub network path and reserves the proper

service along it. Each active session shall be marked by an eight bit SID (Session ID) token, with valid values

of 1 to 255. This SID token shall be carried by each HDBaseT packet, belonging to this session. The T-

Switches along the sub network path, shall switch those packets according to their SID tokens. The SID shall

be unique per switch device on the path. Different sessions, active at the same time, may share the same SID

if their network paths do not have a common switch device.

Each session consists of several T-Streams each comprised of several packet streams. The packet streams

may flow in both directions (from T-Adaptor A to T-Adaptor B and from T-Adaptor B to T-Adaptor A) along the

sub network path. Each packet stream shall pass through exactly the same links/hops, intermediate switch

devices and ports (but may flow in opposite directions).

A Session is created by an Initiating Entity between two Session Partners, a First Partner and a Second

Partner.

5.4.1.1 Session Requirements from the sub network path

Upon creation, each session shall reserve the required, path throughput per direction (downstream and

upstream). The required directional throughput for a session shall be determined according to the aggregated

packet stream throughput used by this session (see section ‎5.2.4.2).


220

Confidential

For a given sub network path, the available path throughput per direction is defined as the throughput of the

link with the minimal throughput at the proper direction from all the links which compose the path.The

available throughput and the number of committed PSU per sub network path, per direction, per priority are

collected using the Periodic SNPM as explained in ‎5.2.5

Upon creation, each session shall reserve the required path PSU budget per priority, per direction (DS and

US), see section ‎5.2.4.3. The required PSU budget for a session shall be determined according to the

aggregation of packet streams used by this session.

Session requirements shall be represented using a NPA structure (see section ‎5.2.4.2).

5.4.1.2 PSU Limits per sub network path

In order to control Latency Variation the HDBaseT network limits the max packet size per priority and the

amount of interfering PSU per sub network path, per direction, per priority.

The following table specifies the DS path PSU limits per priority (see section ‎5.2.4.3):

Table 45: Full DS Path PSU Budget per Priority

Priority Max “Max Packet Size”

Class Name To be Used

Full Path DPSU Budget Remark

1 Full Size 640 ~20uS latency variation

2 Half Size 320 ~10uS latency variation

3 Small Size 120 ~2uS latency variation

The following table specifies the US path PSU limits per priority (see section ‎5.2.4.3):

Table 46: Full US Path PSU Budget per Priority

Priority Max Packet Size Full Path UPSU Budget Remark

1 100 symbols 2000 ~80uS latency variation

2 50 symbols 640 ~25uS latency variation

3 8 symbols 240 ~10uS

The Full Path PSU Budget represents the max number of interfering packet streams (in PSU) a victim packet

from a certain priority may encounter over the full sub network path. This scheme allows congesting more

streams into the network by dynamically reducing the max packet size as long as there is enough available

bandwidth to accommodate for the framing overhead increase.


221

Confidential

Each T-Adaptor declares the PSU usage per priority it needs for its T-Stream and the session declares the

accumulation of PSU per Priority over all T-Adaptors in the session. A session shall use a sub network path

only if the path can accommodate the additional required PSU within the defined budget in Table 45.

5.4.2 Session Routing Overview

Unlike other widely spread “dynamic switching/routing per packet” schemes, the T-Network operates using

fixed route sessions. The session route shall be set upon creation over a sub network path and shall not be

changed. If the network topology/conditions change such that the route is no longer valid for this session, the

session shall be terminated and another session shall be created. While the session is active over a certain

route the incoming packets shall be routed by the T-Switches according to their SID token.

Therefore, the main session routing task is to identify possible valid paths / SIDs for a certain session creation

and select the optimal path among them.

A sub network path is a “valid path” for a certain session creation only if the following conditions are met:

a. The path shall consist of no more than 5 hops.

b. The path shall have available DS throughput which is larger than the DS throughput

required by the session.

c. The path shall have available US throughput which is larger than the US throughput

required by the session.

d. The path shall be able to accommodate the additional DS PSU requested by the session

within the DS Full Path PSU budget.

e. The path shall be able to accommodate the additional US PSU requested by the session

within the US Full Path PSU budget.

f. The creation of this session using this path shall not cause another session, using another

path which is partly overlapping with this path, to violate its DS/US Full Path PSU budget

(Cross Path PSU Violation (XPSU)).

g. A unique, over the path, session ID can be allocated (SID which is not used by any of the

switches along the path).

5.4.3 Session Creation

The following definitions are being used in the session creation process description:

Initiating Entity – Any management entity (PDME/SDME/CPME), requesting a session initiation.

Session Partners – The session is defined between two edge management entities (and their

associated T-Group/T-Adaptors), these entities are referred to as the “Session Partners”.

First Partner – One of the “Session Partners” entities, as selected by the “Initiating Entity”.


222

Confidential

Second Partner – The other one of the “Session Partners” entities, as selected by the

“Initiating Entity”.

Selecting Entity – The entity which chooses one of the possible paths for the session creation.

A PDME/SDME, which is not intended to be one of the future “Session Partners”, shall not act as the “Initiating

Entity” for that session (Only a CPME may initiate a session which it does not participate in).

A PDME/SDME which is acting as the “Initiating Entity” for a session, shall act also as the “Second Partner”.

The default DRS session creation process comprises the following steps:

1. Session Initiation Request (SIR): The “Initiating Entity” shall send, Direct HD-CMP, Session Initiation

Request messages (see sections ‎5.4.3.5 and ‎5.4.3.6), to both “Session Partners” management entities,

checking their availability and requirements for such a session. The “Initiating Entity” selects the First and

Second partners identity and instructs them, how to execute the next steps of the session creation

process.The First and Second Partner respond with SIR responses to the SIR requests.

2. Session Route Query (SRQ): As instructed, by the “Initiating Entity”, the First session Partner shall send

a Session Route Query U_SNPM (see section ‎5.4.3.7) targeting the second session partner. The First

Partner shall also send the corresponding Send SRQ SIR response to the Second Partner notifying it of the

start of the SRQ stage.

3. Session Route Select (SRSL): The second session partner shall operate according to the instructions

embedded in the Session Route Query with the following options:

a. The second partner selects by itself the best route out of all the received queries results

b. The second partner collects all/some of the route queries results and sends a Direct

Session Route Select Request (see sections ‎5.4.3.8 and ‎5.4.3.9) to another entity, the

“selecting entity”. The “selecting entity” will decide on the best route and reply with a

Direct Session Route Select Response containing the selected PDS and session ID.

4. Session Route Set (SRST): The second session partner shall send a Session Route Set, „By PDS‟,

backward U_SNPM which sets the session and reserves the resources on all the intermediate devices

along the path (see section ‎5.4.3.10). If one of the devices along the path (SDMEs or the “First Partner”)

cannot set the session it shall reply back to the “Second Partner” with „By PDS‟, Session Termination

U_SNPM (STU) to terminate the session already created on all the previous devices on the SRST path.

The “Second Partner” shall try to resolve the problem according to the termination cause as stated in the

STU and if it can (or “thinks it can”), it shall send an additional SRST. If it cannot resolve the problem, it

shall notify the “First Partner” and the “Initiating Entity” that this session cannot be set using a direct

Session Termination Response (see section‎5.4.5.3).

5. Session Creation Completed (SCC): When the first session partner receives the Session Route Set

message it shall generate a direct broadcast Session Status Response message (see section ‎5.4.3.11) to

announce the session creation to all the CPs in the network.


223

Confidential

The network may include multiple Control Points, which can initiate sessions simultaneously. Per T-adaptor

once a SRQ message is sent the Session Creation process should be resolved before another session creation

involving the same T-adaptor is started. Different sessions involving the same T-adaptor (Multi T-stream)

should therefore be created sequentially. In the SIR response, a Session Partner should notify an Initiating

Entity if it is requesting to initiate a session involving a T-adaptor which is already involved in a Session

Creation process (beyond step 2 above). A Session Partner should reject a request for sending a SRQ

involving a T-adaptor which is already involved in a Session Creation process (beyond step 2 above).

5.4.3.1 DRS Session Creation Examples

The following figure depicts an example for the DRS session creation steps:

Session Initiation Request (Get Requirements)

Session Route Query

“Best Path” U_DSPM

BDP Living Room TV Control Point

Session Creation Completed

Switch S1 Switch S2

Session Established

HDBaseT Control Point

DV


DV

Session Initiation Response (Ack)

Session Initiation Request (Send SRQ)

Session Initiation Response (Send SRQ Ack)

Session

Initiation

Session

Route Query

Session

Route Select

TV Selects The

Best Route

Session Route Set

“By PDS” Backward

U_USPMSession

Route Set

Session

Creation

Completed

“Initiating Entity”

“Second Partner”

&

“Selecting Entity”

“First Partner”

Direct Broadcast

Session Route Query


Session Initiation Response (Send SRQ Ack)

Figure 169: DRS Session Creation Process – Example 1 – CP Initiating

In the above figure red arrows represents Direct HD-CMP messages and the blue arrows represents U_SNPM.

In this example the control point within the mobile phone is the “Initiating Entity” and it creates an HDMI session

between a HDMI Source T-Adaptor within the BDP, which it selects as the “First Partner” and a HDMI Sink T-

Adaptor within the TV, which is the “Second Partner”. The CP sends Session Initiation Requests to the “Second

Partner” and the “First Partner” (BDP) to verify their ability to participate in such session and to get their

requirements form the session route, when Ack Responses arrives with the session requirments, it sends

another Session Initiation Request to the “First Partner” (BDP) and instruct it to send the SRQ, „Best Path‟,

U_DSPM towards the TV marking that the TV should also act as the “Selecting Entity” in this process. The BDP

is sending the SRQ to the TV marking the FDER with the T-Group reference associated with the HDMI sink T-

Adaptor within the TV.


224

Confidential

The SRQ propagates,, according to the U_SNPM propagation rules, as a „Best Path‟ U_DSPM, through S1 and

S2 to the TV. In this example the message reaches the TV still as a „Best Path‟ message which means that S1

and S2 had a record for the best path targeting the TV. When a „Best Path‟ SRQ reaches the second partner

there is no need to select the path from several path options, since „Best Path‟ defines single message hence

single option. In this example the path conveyed in the arriving U_DSPM‟s PDS, is adequate to accommodate

the session and therefore the TV selects it as the path for the session.

The TV (as the second partner) sends a backward „By PDS‟, U_USPM, SRST using the same PDS as received

from the SRQ. This message will go to S2, S1 and finally to the BDP where in each device it sets the chosen

session id and reserve the resources for it. The session is now active on all the devices.

In order to update CPs in the network about the new session, when the SRST reaches the First Partner (BDP) it

send a Direct Broadcast Session Status Response message announcing the session id, chosen PDS and

committed resources for the session, to any CP in the network. The Second Partner (TV) may not receive this

broadcast message since it does not have to provide Ethernet termination but the TV can now sense the

activity of the session through incoming periodic session maintenance packets.

This example, of course, is describing a smooth process without error conditions which will be described in

details in each Session Creation Step detailed description, sub section.

The following figure depicts another example for the DRS session creation steps:

Session Route Query




Session EstablishedHDBaseT Control Point

DV


DV



Session

Initiation

Session

Route Query

Session

Route Select

TV Selects The

Best Route

Session Route Set


U_USPMSession

Route Set

Session

Creation

Completed


&


&


“First Partner”

Direct Broadcast


DV


DV

Switch S1 Switch S2

Session Route Query


Figure 170: DRS Session Creation Process – Example 2 – TV Initiating


225

Confidential

In this case the TV is the “Initiating Entity”, “Second Partner” and “Selecting Entity” therefore the Session

Initiation step is shorter. The “Initiating Entity” also sends a „Send SRQ‟ SIR to the “First Partner” without the

preceding „Get Requirements‟ SIR (as was in Example 1), in this case the “First Partner” may update the

Session Requirements field, send the SRQ and notify the “Initiating Entity” of the requirement update (SIR

Response). Note that in any case, the “Initiating Entity” shall get first the requirements of the “Second Partner”

before sending the „Send SRQ‟ SIR to the “First Partner”. In this example it is obvious since the “Initiating

Entity” is the “Second Entity”. The rest of the process is identical to the previous example.

The following figure depicts another example for the DRS session creation steps:

Session Route Query


BDP Legacy HDMI-CEC TV Control Point


Session EstablishedHDBaseT Control Point

DV


DV

Session Initiation Request (First)


Session

Initiation

Session

Route Query

Session

Route Select

S2 Selects The

Best Route

Session Route Set


U_USPM

Session

Route Set

Session

Creation

Completed


&


&


“First Partner”

Direct Broadcast


DV


DV

Switch S1 Switch S2

Session Route Query


HDMI signaling

Using native

CEC the TV

selects the

BDP

Figure 171: DRS Session Creation Process – Example 3 – Switch Initiating

In this case the TV is a legacy HDMI-CEC TV which selects the BDP using native CEC mechanism. S2 in this

case has an embedded HDMI Sink T-Adaptor which is connected using regular HDMI cable to the legacy TV,

this T-Adaptor intercept the CEC command and instructs S2 SDME to create the proper session. S2 is then

taking the roles of “Initiating Entity”, “Second Partner” and “Selecting Entity”. The rest of the process is identical

to the previous example. Note that in this example there is no need for any HDBaseT CP function, in the

network, since the control is done using legacy CEC and the DRS is taking care of the rest. The CP in this

example is just informed of the new session and does not take any active role in the process.

The following figure depicts a more complex example for the DRS session creation steps:


226

Confidential

Session Route Query




Session Established


DV


DV

Session Initiation Response (Ack)Session

Initiation

Session

Route Query

Session

Route Select

Session Route Set


U_USPMSession

Route Set

Session

Creation

Completed


&


“Second Partner”“First Partner”

Direct Broadcast

Route Select Request

Route Select Response

Switch S1 Switch S2

Session Route Query

“With Path” U_DSPM

Session Initiation Request (Get Requirements)


Session Initiation Response (Send SRQ Ack)Session Initiation Response (Send SRQ Ack)

Figure 172: DRS Session Creation Process – Example 4 – CP Initiating & Selecting

This is a similar case to Example 1 with the following differences:

After retrieving the “Second Partner” session requirements the CP immediately send the „Send SRQ‟ SIR to the

“First Partner” (without preceding „Get Requirements‟ SIR) as was explained in Example 2. The CP instructs the

First Partner to embed in the SRQ it sends, the CP device ID (MAC address) as a reference for the Selecting

Entity for this process.

S1 does not “know” which is the best path for the TV and therefore convert the „Best Path‟ U_DSPM to „With

Path‟ U_DSPM (see section ‎5.2.7.1) and send it through several ports. Several „With Path‟ messages arrive to

S2 and to the TV. The TV (as the Second Partner) is then sends Session Route Select Request (see section

‎5.4.3.8) to the CP which selects the best path and return the Route Select Response (see section ‎5.4.3.9) with

the chosen PDS and session ID. The rest of the process is the same as in Example 1.

5.4.3.2 CRS Session Creation Example

In CRS a RPE is responsible for route selection therefore there is no need for the SRQ and the SRSL steps

The following figure depicts a CRS session creation steps:


227

Confidential

Session Initiation Request (Second)

BDP Living Room TV Control Point / RPE


Session Established


DV


DV


DV


DV


Session Initiation Request (First)


Session

Initiation

Session

Route Query

Session

Route Select

Session Route Set


U_USPMSession

Route Set

Session

Creation

Completed


&

“Computing Entity”

“Second Partner”“First Partner”

Direct Broadcast


There is no need for Session Route

Query Phase since the CP/RPE can

compute the route

CP/RPE notifies the “second

partner” about the route to be set

Switch S1 Switch S2

Figure 173: CRS Session Creation Process – Example 1 – CP/RPE Initiating & Computing

In this example the CP has RPE functionality therefore it is capable of computing the best route and a valid SID

for a session it wishes to initiate. After the Initiation step, where session properties are verified with the “Second

Partner” and the “First Partner”, the CP immediately sends a SRSL response to second partner, notifying it the

selected route and SID for the session. The “Second Partner” continues (as in DRS) to SRST step and from

there the process is the same as in DRS.

Based on its previous knowledge about the devices in the network, the CP/RPE may also skip the SIR step

going directly to the SRSL response.

The following figure depicts such CRS session creation steps:


228

Confidential

Control Point / RPE


Session Established


DV


DV


DV


DV

Session

Initiation

Session

Route Query

Session

Route Select

Session Route Set


U_USPMSession

Route Set

Session

Creation

Completed


&

“Computing Entity”

Direct Broadcast


There is no need for Session Route

Query Phase since the CP/RPE can

compute the route

CP/RPE notifies the “second

partner” about the route to be set

Figure 174: CRS Session Creation Process – Example 2 – CP/RPE Initiating & Computing – No SIR

The RPE does not have to integrated with the Initiating Entity. An Initiating Entity may use the services of a

RPE function implemented on another device using a sequence of Session Route Compute Request and

Response messages.

5.4.3.1 Initiating Entity Session Creation State Diagram

A Session can be created by a CPME initiator which is not a session partner or by a session partner acting as

a Second Partner.


229

Confidential

IE1: Determine

Session Properties

Create Session

TimerEvent (CP)

SRQ Sent

SSTS Succesful (CP) or

Session Activity (SP)

IE2: Wait for

Session Creation

IE3: Session

Created

IE4: Session

Failed

FAIL

CP1: Verify

Session

SSTS Succesful

FAIL

FAIL

SRSL Response for

“Best Path” or “With Port”

Figure 175: Initiating Entity Session Creation State Diagram

Figure 175 shows the Initiating Entity Session Creation state diagram. The IE may initiate several sessions in

parallel.

State IE1: Determine Session Properties. In this stage the IE establishes the availability and requirements

of the two session partners. During this stage the IE sends SIR requests to the First and Second Partners and

receives their responses. This state shall begin with a check requirement SIR to the Second Partner, and

shall end with a Send SRQ SIR to the First Partner with a successful response (SRQ sent). In between, the

IE may send additional check/get requirement SIRs to the First and Second Partners, or Send SRQ SIRs to

the First Partner which do not result in an SRQ sent response. For each SIR sent the IE expects to receive a

response within sir_response_wait_time (50msec), if a response is not received the IE shall resend the SIR (a

single retry). Other than a retry, the IE shall not send another SIR to the same partner before receiving a

response to a previous SIR to that partner. A “Not Yet” Response (Response Code „NT‟ bit is 1) shall not be

considered a valid response but shall reset the response timer (restart the sir_response_wait_time count). If

the Initiating Entity is a Session Partner, it shall designate itself as the Second Partner and shall not send

actual messages to the Second Partner (itself).

Transition IE1:IE2. The IE receives a SIR response from the First Partner indicating that the First Partner

sent or is going to send an SRQ to the Second Partner (Response Code „RQ‟ bit is 1).

Transition IE1:IE4. This indicates failure in the IE1 stage. This may occur for several reasons. One is a

check/get requirement SIR response which the IE determines does not enable the session creation (e.g.

T-Adaptor is not available). Another is a Send SRQ SIR response from the First Partner which indicates that

the First Partner did not and is not going to send the SRQ (Response Code „RQ‟ bit is 0) and the IE decides

that it does not enable the session creation. A third reason is a failure to receive a response from the First or

Second Partner after a retry (sir_response_wait_time timer expires after the SIR retry).

State IE2: Wait for Session Creation. If the IE is a CP it waits to receive the SSTS response indicating the

new session was created successusfully. If the IE is the Second Partner it waits to receive a session activity

indication. A session_activity_wait_time (500ms) timer is started at the beginning of this state.


230

Confidential

Transition IE2:CP1. The session_activity (500ms) timer of a CP expires.

Transition IE2:IE3. The IE receives a SSTS response indicating the creation of the requested new session

(Session Status „NW‟ bit is 1), or The IE receives a session activity indication.

Transition IE2:IE1. The IE receives a SRSL response with zero routes for a “Best Path” or “With Port” SRQ,

indicating that no valid route was found. If the SRSL response was received for a session creation using “Best

Path” SRQ, the IE may retry to create the session using “With Path” or “All Ports”. If the SRSL response was

received for a session creation using “With Path” SRQ, the IE may retry to create the session using “All

Ports”.

Transition IE2:IE4. The IE receives a SSTS response indicating a failure in the requested session creation or

the IE receives a SRSL response indicating that no valid route was found for an “All Ports” SRQ or the Second

Partner IE session_activity (500ms) timer expires.

State CP1: Verify Session. In this stage the CP sends a unicast SSTS request to the First or Second Partner

in order to find out if the session was created. The IE expects to receive a SSTS response within

verify_session_wait_time (50ms).

Transition CP1:IE3. The IE receives a SSTS response indicating the requested session is active.

Transition CP1:IE4. The IE receives a SSTS response indicating the requested session was not created (is

not active) or fails to receive a SSTS response within verify_session_wait_time.

State IE3: Session Created. This stage successfully concludes the session creation process.

State IE4: Session Failed. This stage unsuccessfully concludes the session creation process. The IE should

determine according to the failure reason whether to retry the session creation process.

5.4.3.2 Session Partner Session Initiation

Each potential Session Partner (PDME/SDME with embedded T-adaptors) shall receive SIR requests and

respond appropriately (see ‎5.4.3.6).


231

Confidential

SRQ Sent

P1: Session

Initiation Response

Response Not Ready

Received SIR

SRQ not Sent

P0: Idle

First Partner

Session

Initiation

Figure 176: Partner SIR State Diagram

Figure 176 shows a Session Partner SIR state diagram.

State P0: Idle. The Partner awaits to receive a Session Initiation Request (SIR).

Transition P0:P1. The Partner receives a Session Initiation Request (SIR), sets NT_count to 4.

State P1: Session Initiation Response. In this stage the Partner responds to a Session Initiation Request

sent by the Initiating Entity. When beginning this stage the partner shall start a sir_nyet_time (20msec) timer.

Transition P1:P0. When the Partner is ready to respond without sending an SRQ, the partner shall send the

SIR response.

Transition P1:P1. If the Partner is not ready to respond to the SIR after sir_nyet_time and NT_count is

positive, it shall decrease NT_count by 1, send a “Not Yet” Session Initiation Response (Response Code „NT‟

bit set to 1) and restart the sir_nyet_time timer. This can be repeated up to 5 times.

Transition P1:FP1. When the Partner is ready to respond with sending an SRQ, the partner shall send the

SIR response to the IE and the Second Partner and the SRQ message to the Second Partner. The partner is

designated as the First Partner and shall continue according to the First Partner Session Initiation State

Diagram (Error! Reference source not found.).

A Session Partner is designated as the “First Partner” when it receives a Send SRQ SIR request and sends

an SRQ message or when it receives a SRST message (CRS).

A Session Partner is designated as the “Second Partner” when it receives a SRQ message or a SRSL

response message (CRS).


232

Confidential

5.4.3.3 First Partner Session Initiation State Diagram

FP3: Session

Active

FP4: Session

Failed

FP2: Set

Session

Received valid SRST

SRQ Sent

FAIL

Received SRST (CRS)

FP1: Wait to

Set Session

FAIL

Received SRST

Figure 177: First Partner Session Initiation State Diagram

Figure 177 shows the Session Initiation state diagram of the First Partner. The Partner may participate in

several session initiation processes in parallel.

State FP1: Wait to Set Session. In this stage the First Partner waits to receive a SRST message, and starts

a srst_response_wait_time (500msec) timer.

Transition FP1:FP2. The First Partner receives a SRST message.

Transition FP1:FP4. This indicates failure in the FP1 stage. This may occur for several reasons. One is a

failure to receive a SRST message within srst_response_wait_time. In this case the First Partner shall send a

direct SSTS session termination message to the Second Partner and to the Initiating Entity. A second reason,

is receiving a STU message. In this case, the partner shall send a direct SSTS session termination message

to the Initiating Partner and/or the Second Partner if they are not the source of the STU message. A third

reason, is receiving a direct SSTS session termination message. In this case, the partner shall send a direct

SSTS session termination message to the Second Partner and/or Initiating Entity if they are not the source of

the message and if the SSTS contains a non-zero session ID the partner shall send a STU message to the

Second Partner.

State FP2: Set Session. When the First Partner receives a SRST message it shall verify its parameters and

allocate the required session resources.

Transition FP2:FP3. The First Partner received the SRST message, verified it and successfully allocated the

required resources.


233

Confidential

Transition FP2:FP4. This indicates failure in the FP2 stage. This may occur if the SRST do not provide an

adequate route or a failure to allocate the required resources. In these cases the First Partner shall send a

STU message and a direct SSTS session termination message to the Second Partner and a direct SSTS

session termination message to the Initiating Entity.

State FP3: Session Active. This stage successfully concludes the session creation process and handles the

active session (see TBD).

State FP4: Session Failed. This stage unsuccessfully concludes the session creation process. An internal

failure notification shall be given to the local device upper layer.

5.4.3.4 Second Partner Session Initiation State Diagram

SP6: Session

Active

SP7: Session

Failed

Session Activity

Received Resolvable

STU

Received SRQ w/o

SRSL enable

SP1: Select

Route

SP3: Wait for

Route Selection

SP5: Set

Session

Valid SRSL

Response

valid route

FAIL

FAIL

SP4: Check

Route Selection

Received SRSL Response

Received SRSL

Response (CRS)

FAIL

SP2: Wait for

SRQs

Received SRQ w/o

SRSL enable

Single SRQ and

valid route

Multiple SRQs or

(Single SRQ and invalid route)

Figure 178: Second Partner Session Initiation State Diagram

Figure 178 shows the Session Initiation state diagram of the Second Partner. The Partner may participate in

several session initiation processes in parallel.

Transition :SP1. Received SRQ w/o SRSL Enable.

Transition :SP2. Received SRQ with SRSL Enable.

Transition :SP4. Received SRSL Response (CRS).

State SP1: Select Route. In this stage the Second Partner waits for additional SRQs and selects the session

route itself. If the SRQ is received with „Best Path‟ than there is only one path (and no additional incoming

SRQs) and the Second Partner shall not need to wait for additional messages. Otherwise, the Second

Partner may wait up to srq_wait_time (50ms) for additional SRQ messages containing additional candidate

paths.

Transition SP1:SP5. The Second Partner finds a path with the required parameters.

Transition SP1:SP7. The Second Partner cannot find a path with the required parameters. The Second

Partner shall send a SRSL response with zero valid paths to the Initiating Entity.


234

Confidential

State SP2: Wait for SRQs. In this stage the Second Partner waits for additional SRQs in order to send to the

“Selecting Entity”. If the SRQ is received with „Best Path‟ than there is only one path (and no additional

incoming SRQs) and the Second Partner shall not wait for additional messages. Otherwise, the Second

Partner may wait up to srq_wait_time (50ms) for additional SRQ messages containing additional candidate

paths. If only a single SRQ is received (Best Path or other) and it is valid, the “Second Partner” shall choose it

by itself. Otherwise, it shall send or some of the SRQ routes to the Selection Entity specified in the SRQs (all

should contain the same one) in a Session Route Select (SRSL) Request, and start a

srsl_response_wait_time (200msec) timer.

Transition SP2:SP5. The Second Partner chooses a route by itself.

Transition SP2:SP3. The Second Partner sent a SRSL request to the “Selecting Entity”.

State SP3: Wait for Route Selection. In this stage the Second Partner waits to receive the SRSL response.

Transition SP3:SP4. The Second Partner receives a SRSL Response.

Transition SP3:SP7. The Second Partner does not receive a SRSL Response for srsl_response_wait_time.

The Second Partner shall send a direct SSTS session termination message with SID zero to the Initiating

Entity.

State SP4: Check Route Selection. In this stage the Second Partner verifies that the SRSL contains a valid

session route.

Transition SP4:SP5. The SRSL Response contains a valid path with the required parameters.

Transition SP4:SP7. The SRSL Response does not contain a path or the path is not sufficient. The Second

Partner shall send a SRSL response with zero valid paths to the Initiating Entity.

State SP5: Set Session. In this stage the Second Partner allocates the required session resources. If

successful, it sends a Session Route Set (SRST) message to the First Partner according to the selected route

and starts a session_activity_wait_time (500msec) timer.

Transition SP5:SP5. If the Second Partner receives a Session Termination U-SNPM (STU) message which

indicates a termination cause it can resolve it shall retransmit an updated SRST message to the First Partner

and restart the session_activity_wait_time timer.

Transition SP5:SP6. The Second Partner receives a Session Activity Indication from incoming periodic

session maintenance packets.

Transition SP5:SP7. This indicates failure in the SP5 stage. This may occur for several reasons. One is that

the Partner was not able to allocate the required resources (e.g. T-adaptor) or that the route does not provide

the required session resources. Another is the expiration of the session_activity_wait_time timer without

session activity indication. In this case the Second Partner deallocates the session resources and sends a

STU message and a direct SSTS session termination message to the First Partner. A third reason is reception

of a STU message which indicates a termination cause it cannot resolve, in which case the Partner

deallocates the session resources, and if the origin of the STU message is not the First Partner sends a direct

SSTS session termination message to the First Partner and to the Initiation Entity. A Fourth reason is

reception of a direct SSTS session termination message, in which case the Partner deallocates the session

resources, and if the origin of the message is not the First Partner sends a direct SSTS session termination

message to the First Partner and to the Initiation Entity.


235

Confidential

State SP6: Session Active. This stage successfully concludes the session creation process and handles the

active session (see TBD).

State SP7: Session Failed. This stage unsuccessfully concludes the session creation process. An internal

failure notification shall be given to the local device upper layer.

5.4.3.5 Session Initiation Request

Session Initiation Request messages are sent from the “Initiating Entity” to the “First Partner” or to the

“Second Partner” using Direct HD_CMP messages, typically over Ethernet.

The following figure depicts the Session Initiation Request message format with its mapping to an Ethernet

packet:

HD-CMP



Destination Entity

Device ID : TPG

Session Partner

Source Entity

Device ID : TPG

Initiating Entity

8 Bytes 8 Bytes

Destination MAC

Address

Source MAC

Address

Type: HD-CMP



Eth CRC

4 Bytes

Destination TPG

2 Bytes

Source TPG

2 Bytes

HD-CMP

Op Code

2 Bytes

Device ID Device ID

00000010 00100xxx

000 – Get Session Requirements

001 – Check Session Properties and Requirements

010 – Check and send SRQ

011 to 111 – Reserved

First Partner

T-Adaptors Ref

Second Partner

T-Adaptors Ref

Session

Requirements

SRQ

Type

Selecting Entity

Reference10+ Bytes 10+ Bytes 12 Bytes 1 Byte 8 Bytes

b0b3

Sub Type

Initiating Entity

Reference8 Bytes

Additional Info

1+ Bytes

Figure 179: Session Initiation Request OpCode and Payload Formats

Destination Entity Reference: The target “Session Partner” management entity reference is the

destination entity for this message.

Source Entity Reference: The “Initiating Entity” reference is the source entity for this message.

HD-CMP OpCode:

o Prefix - the 12 most significant bits shall be set to 0x022. Note that this is not a SNPM

message (the first 7 bits are not all zero)

o Request/Response Bit Flag – b3 is marking request/response and shall be zero to mark

a request packet

o Sub Type – The three least significant bits b2:b0 convey the sub type of this message

according to the following:

000 – Get session requirements. The Initiating Entity may send this sub type to

fetch the session requirements from any of the “Session Partners”.


236

Confidential

001 – Check session properties and requirements. The Initiating Entity shall send

this sub type to the “Second Partner” to verify its approval for the suggested

session properties and requirements.

010 – Check session as above and if ok, send the SRQ to the “Second Partner.

011 to 111 – Reserved values, shall not be generated by entities complying with

this specification. Upon reception of such a message at the final destination entity

such entity complying with this specification shall discard the message. SDMEs

shall switch/propagate such messages including to its edge links (over HLIC)

since future specifications may use these sub type values.

Initiating Entity Reference (IER) – If the Initiating Entity is a partner this is its TPG reference (8

bytes). If the Initiating Entity is a CPME this is the CPME‟s Ethernet MAC Address (6 bytes)

followed by a 2-byte Session Creation Index (SCI), which is unique to this session initiation process

within the IER. The SCI helps the CPME to initialize several sessions in parallel (with the same

partners).

First Partner T-Adaptors Reference (FPTR) - A 10+ byte reference (Device ID : TPG : T-Adaptors

Type Mask - see section ‎5.1.4) which shall hold the full reference for the T-Adaptors entities, at the

other session partner device, to be participating in this session.

Second Partner T-Adaptors Reference (SPTR) - A 10+ byte reference (Device ID : TPG : T-

Adaptors Type Mask - see section ‎5.1.4) which shall hold the full reference for the T-Adaptors

entities, at this session partner device (The destination entity for this message), to be participating in

this session. Note that the Destination entity reference at the HD-CMP header may not hold the full

TPG reference, only what is needed to identify the management entity, therefore only the TPTR

shall be used to identify the participating T-Adaptors.

Session Requirements - A twelve (12) byte field with the same format as the NPA (see section

‎5.2.4.2) conveying the session requirements in terms of available throughput and PSU budget from

the sub network path. If OpCodes‟s sub type is „Get Session Requirements‟ this field shall be all

zero.

SRQ Type – A one byte field which defines the properties of the U_SNPM SRQ message which will

be sent by the First Partner. The 4 LSBs are the Mod and Dir Subfields as defined for the 4 LSBs of

the U-SNPM opcode (see ‎5.2.7). The next bit (b4) is the SRSL Enable bit which shall be set to 1 if

the Second Partner is to use a “Selecting Entity” in the Route Selection phase. The 3 MSBs are

reserved and shall be set to 0.

DirModSRSL

EnReserved

b0b1b2b3b4b5b6b7

Figure 180: SRQ Type Field

Selecting Entity Reference – An eight byte field conveying the management entity reference of the

“Selecting Entity” to be used by the “Second Partner” in the SRSL stage in case the SRSL Enable

bit (b5 of SRQ Type) is set.


237

Confidential

Additional Info – The Additional Info Field is of variable length and holds additional info needed for

the session initiation by specific T-adaptors. It shall consist of 0 or more AI_Type (1 byte),

AI_Length (1 byte), AI_Value (Length bytes) sequences and shall end with a “0” byte.

o AI_Type – A 1 byte field holding the Type of additional info according to the following table:

Table 47: AI_Type

AI_Type Description

0 End of Additional Info Section

1 USB Devices

2-255 Reserved

o AI_Length – A 1 byte field holding the Length of the AI field in bytes (0-255).

o AI_Value – A sequence of “AI_Length” bytes holding the additional info of type “AI_Type”

5.4.3.6 Session Initiation Response

Session Initiation Response messages are sent from the “First Partner” or the “Second Partner” back to the

“Initiating Entity” using Direct HD_CMP messages typically over Ethernet. An SIR response is also sent by the

First Partner to the Second Partner when sending an SRQ.

The following figure depicts the Session Initiation Response message format with its mapping to an Ethernet

packet:

Figure 181: Session Initiation Response OpCode and Payload Formats

Destination Entity Reference: The “Initiating Entity” or the “Second Partner” (when the First

Partner sends a SRQ) is the reference is the destination entity for this message.


238

Confidential

Source Entity Reference: The “Session Partner” management entity reference is the source entity

for this message.

HD-CMP OpCode:

o Prefix the 12 most significant bits shall be set to 0x022. Note that this is not a SNPM


o Request/Response Bit Flag – b3 is marking request/response and shall be set to one to

mark a response packet.

o Sub Type – Shall use the same sub type as the request packet.

Initiating Entity Reference (IER) – shall be the same as in the request packet.

First Partner T-Adaptors Reference (FPTR)- If the “Session Partner” cannot use certain listed

T-Adaptors (as were sent in the request packet) for this session it shall update the FPTR and the

SPTR fields accordingly, otherwise it shall use the same FPTR as in the request packet. The

“Session Partner” shall not add additional non listed T-Adaptors to the response packet.

Second Partner T-Adaptors Reference (SPTR)- If the “Session Partner” cannot use certain listed

T-Adaptors (as were sent in the request packet) for this session it shall update the SPTR and the

FPTR fields accordingly, else it shall use the same SPTR as in the request packet. The “Session

Partner” shall not add additional non listed T-Adaptors to the response packet.

Session Requirements – This field shall be updated if the “Session Partner” requires more

resources than were listed in the request packet. If the “Session Partner” requires equal or fewer

resources than were listed in the request packet it shall not alter this field and shall use the same

value as in the request packet.

Response Code – One byte bit map field shall convey the response code of the “Session Partner”:

o „TG‟ bit (b0) – Shall be set to one if TPG reference is not valid for this session partner.

o „TA‟ bit (b1) – Shall be set to one if T-Adaptors type mask or Additional Info were updated,

FPTR and SPTR as well as Additional Info of this response packet contains the updated

values.

o „SR‟ bit (b2) – Shall be set to one if Session Requirements field was updated, this

response packet contains the updated value.

o „DR‟ bit (b3) – Shall be set to one if the instructed direction for the SRQ is not consistent

with this partner.

o „ER‟ bit (b4) – Shall be set to one if there is a general error in this session partner.

o „NT‟ bit (b5) – Shall be set to one if the session partner needs more time to assemble its

response. If it is set and the „TA‟ bit is also set it means that at least one of the T-adaptors

is already engaged in a Session Initiation process, and the Initiating Entity shall not resend

its request within the next 100msecs. Otherwise, If it is set to 1, the meaning of this code is

„Not yeT‟, response is not ready yet but “I am working on it” and the real response will

follow in a while. The session partner shall send this response code every 20mSec not

more than 5 times until the real response code is transmitted. This mechanism allows the

utilization of relatively short timers at the Initiating Entity to identify “no response condition”.


239

Confidential

o „RS‟ bit (b6) – Reserved bit shall be cleared to zero when transmitted and ignored upon

reception.

o „RQ‟ bit (b7) – Shall be set to one, if the session partner did transmit or is going to transmit

the SRQ message. If the SRQ was/will-be transmitted the response packet shall contain

the FPTR, SPTR, Session Requirements and Addition Info fields as were/will-be

transmitted in the SRQ packet. In the case that the „TG‟ bit or the „DR‟ bit or the „ER‟ bit are

set to one, the first partner shall not send the SRQ and shall clear the „RQ‟ bit in the

response code. In other cases the first partner has the flexibility to decide whether to

transmit the SRQ or not but it shall report its decision using the „RQ‟ bit. For example if the

first partner discovers it needs slightly more path throughput than what was listed in the

request packet, it may send the SRQ with the modified session requirements field and

mark the „RQ‟ bit in the response code. Another example is that if the first partner cannot

allocate one of the listed T-Adaptors in the session it may send the SRQ with modified

FPTR and SPTR, mark the „RQ‟ bit and update the FPTR/SPTR in the response packet.

Additional Info – If the “Session Partner” cannot comply with the Additional Info section (as sent in

the request packet) for this session it shall update the Additional Info section accordingly, otherwise

it shall use the same Additional Info as in the request packet.

5.4.3.7 Session Route Query (SRQ)

Session Route Query messages are sent from the “First Partner” to the “Second Partner”, using U_SNPM

messages. These messages shall be sent using short form HLIC encapsulation (see section ‎5.2.3.2) to

reduce their latency and network overhead.

The following figure depicts the Session Route Query message format with its mapping to HLIC packet and to

the SIR message whose initiate it:

Length HLIC

Short Form1 0 0 0 0 0 0

HD-CMP


2 Bytes

CRC-32


0 0 0 0

HD-CMP

Msg OpCode

Network Path

Availability

2 Bytes 12 bytes

FDER

Second Partner

8 Bytes

RSER

First Partner

8 Bytes

PDS

72 Bytes

Per Op Code U_SNPM

Body

Variable Length

0 0 0 0 0 0 0 1 DirMod

Session ID

Query

32 Bytes

b0b15 b8

U_SNPM

Format

FirstPartner

T-Adaptors Mask

SecondPartner

T-Adaptors Mask

Session

Requirements

SRQ

Type

Selecting Entity


SRQ Specific

Body

SIR Payload

Initiating Entity

Reference8 Bytes

First Partner

T-Adaptors Ref

Second Partner

T-Adaptors Ref

Session

Requirements

SRQ

Type

Selecting Entity


Initiating Entity

Reference8 Bytes

Additional Info

1+ Bytes

Additional Info

1+ Bytes

Figure 182: Session Route Query OpCode and Payload Formats with their Relations to SIR and HLIC


240

Confidential

HD-CMP OpCode:

o Prefix - The message is a U_SNPM and shall set the first OpCode‟s byte accordingly.

o U_SNPM Type – b7:b4 of the second byte shall be all zero marking the SRQ U_SNPM

type.

o U_SNPM Mod – The SRQ message shall be sent according to bits [b3:b2] of the SIR‟s

SRQ Type field.

o U_SNPM Dir – The SRQ message shall be sent according to bits [b1:b0] of the SIR‟s

SRQ Type field.

FDER – The FDER field shall contain the first eight bytes of the “Second Partner” (Device ID :

TPG).

RSER – The RSER field shall contain the first eight bytes of “First Partner” (Device ID : TPG).

PDS – The First Partner shall initialize a PDS with 7 entries and fill the first entry with its own info.

Each propagating entity shall properly update the PDS (see section ‎5.2.4.1)

NPA – The First Partner shall initialize a NPA. Each propagating entity shall properly update the

NPA (see section ‎5.2.4.2).

SIQ – The First Partner shall initialize a full SIQ section (32 bytes). Each propagating entity shall

properly update the SIQ (see section ‎5.2.4.2‎5.2.7).

Initiating Entity Reference (IER) – shall be the same as in the SIR request packet.

First Partner T-Adaptors Mask (FPTM) – A 2+ byte field which shall convey the “First Partner”

T-Adaptors Type Mask, such that the full reference of RSER:FPTM shall be the full reference for

the “First Partner” T-Adaptors entities, participating in this session (equal to the FPTR field as sent

in the SIR response).

Second Partner T-Adaptors Mask (SPTM) – A 2+ byte field which shall convey the “Second

Partner” T-Adaptors Type Mask, such that the full reference of FDER:SPTM shall be the full

reference for the “Second Partner” T-Adaptors entities, participating in this session (equal to the

SPTR field as sent in the SIR response).

Session Requirements – A twelve (12) byte field which shall convey the updated session

requirements as sent by the SIR. Note that these requirements may have been updated by the first

partner. This field shall travel intact to the FDER and it shall not be used by any SDME to stop the

propagation (in the case that the NPA+SR is bigger than the limit).

SRQ Type – The 5 LSBs shall be the same as in the SIR request packet. The 3 MSBs shall be

used to indicate Cross-PSU violation (XPSU). These bits shall denote the PDS entry index of the

propagating entity which discovered the violation (1-6), 0 indicates no violation, 7 indicates violation

beyond the sixth PDS entry index.

Selecting Entity Reference – shall be the same as in the SIR request packet.

Additional Info – shall be the same as in the SIR response packet.


241

Confidential

When propagating a SRQ message each SDME shall perform the following path validity checks:

Current Path Validity Check for „Best Path‟

Per each received „Best Path‟ SRQ message, each propagating SDME shall update the SRQ NPA as

explained in ‎5.2.5.1 and compute the additional effect, of this session‟s PSU requirements, on the path from

the first partner to the next hop. If this computation results in violation of the Full Path PSU budget (DS or US)

as in ‎5.4.1.2 or there is no available throughput in at least one direction, the propagating SDME shall convert

the message to an „All Ports‟ SRQ message and shall propagate it accordingly. The SDME shall compute the

additional effect of this session PSU requirements, per direction, using the following (TSR denotes This

Session Requirements as in the SR sub-field at the proper direction):

Additional_P1_PSU = TSR_P1_PSU + (TSR_P2_PSU + TSR_P3_PSU)*PDS_OCC_Count : For a

victim P1 packet, This Session P1 streams interfere only once in the path while This Session Priority

2 and 3 streams may re-interfere with P1 packet at each SDME.

Additional_P2_PSU = (TSR_P2_PSU + TSR_P3_PSU)*PDS_OCC: This Session Priority 2 and

Priority 3 streams may re-interfere with the victim P2 packet at each SDME.

Additional_P3_PSU = TSR_P3_PSU : For a victim P3 packet, This Session P3 streams may interfere

only once in the path.

Remaining Path Validity Check for „Best Path‟

Per each received SRQ message, each propagating SDME shall compute the additional effect, of this

session‟s PSU requirements, on the remaining path from this SDME to the target edge SDME using its “Best

Port” stored Best_PDS_OCC_Count (number of remaining hops on the best path) and stored NPA (see

‎5.3.3). If this computation results in violation of the Full Path PSU budget (DS or US) as in ‎5.4.1.2 or there is

no available throughput in at least one direction for the remaining path, the propagating SDME shall convert

the message to „All Ports‟ SRQ and shall propagate it accordingly. The SDME shall compute the additional

effect of this session PSU requirements, per direction, using the following (TSR denotes This Session

Requirements as in the SR sub-field at the proper direction):

Additional_P1_PSU = TSR_P1_PSU + (TSR_P2_PSU + TSR_P3_PSU)*Best_PDS_OCC_Count :

For a victim P1 packet, This Session P1 streams interfere only once in the path while This Session

Priority 2 and 3 streams may re-interfere with P1 packet at each SDME.

Additional_P2_PSU = (TSR_P2_PSU + TSR_P3_PSU)*Best_PDS_OCC: This Session Priority 2 and

Priority 3 streams may re-interfere with the victim P2 packet at each SDME.




242

Confidential

Cross Path PSU Validity Check

Per each received SRQ message, with a zero XPSU sub-field in the SRQ Type field, each propagating SDME

shall update the SRQ PDS according to the propogation port and detect if the additional effect, of this

session‟s PSU requirements, on each of the other sessions using the same propagation port, will cause this

other session to violate the Full Path PSU budget (DS or US) as in ‎5.4.1.2. If such violation is detected, the

propagating SDME shall update accordingly the XPSU sub-field in the SRQ Type field, convert (if needed) the

message to „All Ports‟ SRQ and shall propagate it accordingly. Per such “other session” the SDME shall use

its, per session, stored Full_Path_NPA and stored Full_Path_PDS (see ?????). The SDME shall compute the

additional effect as follows (TSR denotes This Session Requirements as in the SR sub-field at the proper

direction and OLHC denotes the number of hops shared between the new session‟s updated PDS and the

other session‟s FULL_PATH_PDS):

Additional_P1_PSU = TSR_P1_PSU + (TSR_P2_PSU + TSR_P3_PSU)*OSLC : For a victim P1

packet, This Session P1 streams interfere only once in the path while This Session Priority 2 and 3

streams may re-interfere with P1 packet at each SDME.

Additional_P2_PSU = (TSR_P2_PSU + TSR_P3_PSU)*OSLC: This Session Priority 2 and Priority 3

streams may re-interfere with the victim P2 packet at each SDME.



If the SDME is the first SDME in the SRQ path it shall also perform this check for all other sessions of the

SRQ‟s incoming port.

Note that in all cases, when changing the propagation mode to „All Ports‟ the SDME shall propagate the

message also to the “Best Port”.

5.4.3.8 Session Route Select (SRSL) Request

Session Route Select Request messages are sent from the “Second Partner” to the “Selecting Entity” using

Direct HD_CMP messages typically over Ethernet.

The following figure depicts the Session Route Select Request message format with its mapping to Ethernet

packet:


243

Confidential

HD-CMP



Destination Entity

Device ID : TPG

Selecting Entity

Source Entity

Device ID : TPG

Second Partner

8 Bytes 8 Bytes

Destination MAC

Address

Source MAC

Address

Type: HD-CMP



Eth CRC

4 Bytes

Destination TPG

2 Bytes

Source TPG

2 Bytes

HD-CMP

Op Code

2 Bytes

Device ID Device ID

00000010 01000xxx

First Partner

T-Adaptors Ref

Second Partner

T-Adaptors Ref

Session

Requirements

Route 1

Info

Route 2

Info10+ Bytes 10+ Bytes 12 Bytes Variable Variable

b0b3

Routes

Number

Route 7

Info…Variable

Network Path

Availability

12 bytes

PDS

Up to 72 Bytes

Valid

SIDs

2 bytes

General

HD-CMP

Message

Mapping to Ethernet

SRSL Request

Payload

Route Info

Entry Format

Initiating Entity

Reference8 Bytes

Additional Info

1+ Bytes

Figure 183: Session Route Select Request OpCode and Payload Formats

Destination Entity Reference: The “Selecting Entity” reference is the destination entity for this

message.

Source Entity Reference: The “Second Partner” management entity reference is the source entity

for this message.

HD-CMP OpCode:

o Prefix - the 12 most significant bits shall be set to 0x024. Note that this is not a SNPM


o Request/Response Bit Flag – b3 is marking request/response and shall be zero to mark

request packet.

o Routes Number – The three least significant bits b2:b0 shall convey the number of Route

Info Entries transmitted with this message.

Initiating Entity Reference (IER) – shall be the same as in the SRQ packets.



first partner device, to be participating in this session.

Second Partner T-Adaptors Reference (SPTR) - A 10+ byte reference (Device ID : TPG :

T-Adaptors Type Mask - see section ‎5.1.4) which shall hold the full reference for the T-Adaptors

entities, at the second partner device, to be participating in this session.



the sub network path.

Routes Info Entries –A vector of Route Info Entries which shall contain number of entries as listed

in the OpCode‟s „Routes Number‟ sub field. Each Route Entry shall represent an incoming SRQ

and shall contain the following fields:


244

Confidential

o PDS : An up to 72 byte field which shall contain only the occupied PDS entries as received

with the SRQ.

o NPA : A 12 byte field which shall contain the NPA as received with the SRQ.

o Valid SIDs : A two byte field which shall contain one or two optional valid SID for this

route, generated by the “Second Partner” from the SIQ it received with the SRQ. If it

cannot find even one valid SID the “Second Partner” shall discard such route and shall

not send it in the SRSL Request. If only one valid SID can be found the first byte shall

contain the valid SID and the second shall be zero.

Additional Info – shall be the same as in the SRQ packets.

5.4.3.9 Session Route Select (SRSL) Response

Session Route Select Response messages are sent from the “Selecting Entity” or an RPE to the “Second

Partner” using Direct HD_CMP messages typically over Ethernet. The “Selecting Entity” may send up to 7

valid routes prioritized such that the first route is the best and the last is the worst but all of these routes shall

be valid for this session. The “Second Partner” shall use these alternative routes whenever it cannot set the

best route.

The following figure depicts the Session Route Select Response message format with its mapping to Ethernet

packet:

HD-CMP



Destination Entity

Device ID : TPG

Second Entity

Source Entity

Device ID : TPG

Selecting Entity

8 Bytes 8 Bytes

Destination MAC

Address

Source MAC

Address

Type: HD-CMP



Eth CRC

4 Bytes

Destination TPG

2 Bytes

Source TPG

2 Bytes

HD-CMP

Op Code

2 Bytes

Device ID Device ID

00000010 01001xxx

First Partner

T-Adaptors Ref

Second Partner

T-Adaptors Ref

Session

Requirements

Termination

Mask

Valid (best)

Route 110+ Bytes 10+ Bytes 12 Bytes Variable Variable

b0b3

Routes

Number

Valid

Route 7…Variable

Network Path

Availability

12 bytes

PDS

Up to 72 Bytes

Valid

SIDs

2 bytes

General

HD-CMP

Message

Mapping to Ethernet

SRSL Response Payload

Route Info

Entry Format

Initiating Entity

Reference8 Bytes

Additional Info

Figure 184: Session Route Select Response OpCode and Payload Formats

Destination Entity Reference: The “Second Partner” management entity reference is the

destination entity for this message.

Source Entity Reference: The “Selecting Entity” reference is the source entity for this message.

HD-CMP OpCode:


245

Confidential

o Prefix - The 12 most significant bits shall be set to 0x024. Note that this is not a SNPM



mark response packet.

o Routes Number – The three least significant bits b2:b0 shall convey the number of Valid

Routes Info Entries transmitted with this message. If this number is zero it means that

there is no valid route for this session. If the number is larger than one it means that there

are several valid routes and their order in this message is from best to worst (Valid route 1

is the best).

Initiating Entity Reference (IER) – shall be the same as in the SRSL request packet.



first partner device, to be participating in this session.

Second Partner T-Adaptors Reference (SPTR) - A 10+ byte reference (Device ID : TPG :

T-Adaptors Type Mask - see section ‎5.1.4) which shall hold the full reference for the T-Adaptors

entities, at the second partner device, to be participating in this session.



the sub network path. Note that the “Selecting Entity” may change this field value from what was

transmitted in the request message, therefore the value conveyed in the response message shall

be used for setting the session.

Termination Mask – A one byte field indicating which termination errors shall be ignored during the

SRST stage (see ‎5.4.5.1). The 2 MSBs shall always be cleared to 0.

Routes Info Entries – A vector of Valid Route Info Entries which shall contain a number of entries

as listed in the OpCode‟s „Routes Number‟ sub field (0 to 7). Each Route Entry shall represents an

incoming SRQ and shall contain the following fields:

o PDS : An up to 72 byte field which shall contain only the occupied PDS entries as received

with the SRQ.

o NPA : A twelve (12) byte field which shall contain the NPA as received with the SRQ.

o Valid SIDs : A two byte field which shall contain one or two optional valid SID for this

route, if only one valid SID exists, the first byte shall contain the valid SID and the second

shall be zero.

Additional Info – shall be the same as in the SRSL request packet.

The SRSL Response shall also be used by the “Second Partner” to notify the “First Partner” and the “Initiating

Entity” that the SRQ attempt failed to find a valid route for this session. In this case the “Second Partner” shall

zero the OpCode‟s „Routes Number‟ sub field.


246

Confidential

5.4.3.10 Session Route Set (SRST)

Session Route Set messages are sent from the “Second Partner” to the “First Partner”, using U_SNPM

messages. These messages shall be sent using short form HLIC encapsulation (see section ‎5.2.3.2) to

reduce their latency and network overhead. Each intermediate SDME propagating this message shall activate

this session and reserve its resources until it is terminated. In the case a PDME/SDME cannot activate this

session it shall respond with a Session Route Terminate U_SNPM message targeting the initiator of the

SRST (Second Partner) to notify each node on the way that this session is terminating (see section ‎5.4.5.1).

The following figure depicts the SRST message format with its mapping to HLIC packet:

Length HLIC

Short Form1 0 0 0 0 0 0

HD-CMP


2 Bytes

CRC-32


0 0 0 1

HD-CMP

Msg OpCode

Network Path

Availability

2 Bytes 12 bytes

FDER

First Partner

8 Bytes

RSER

Second Partner

8 Bytes

PDS

Up to 72 Bytes

Per Op Code U_SNPM

Body

Variable Length

0 0 0 0 0 0 0 1 Dir1 1

Empty SIQ / Termination Mask

1 Byte

b0b15 b8

U_SNPM

Format

First Partner

T-Adaptors Mask

Second Partner

T-Adaptors Mask

Session

RequirementsSID

2+ Bytes 2+ Bytes 12 Bytes 1 Byte

SRST Specific

BodyInitiating Entity

Reference8 Bytes

Additional Info

1+ Bytes

Full Path NPA

12 Bytes

Figure 185: Session Route Set OpCode and Payload Formats with their HLIC Encapsulation

HD-CMP OpCode:


o U_SNPM Type – b7:b4 of the second byte shall be „1‟ indicating a SRST U_SNPM type.

o U_SNPM Mod – Shall be set to „By PDS‟.

o U_SNPM Dir – The “Second Partner” shall set the Dir sub field properly.

FDER – The FDER field shall contain the full TPG reference (Device ID : TPG) of the “First

Partner”.

RSER – The RSER field shall contain the full TPG reference (Device ID : TPG) of the “Second

Partner”.

PDS – The Second Partner shall properly initialize the PDS to the selected route using only the

occupied entries. If needed it shall mark backward PDS by setting Occ Count sub field to negative

value (see section ‎5.2.4.1).

NPA – The Second Partner shall initialize a NPA each propagating entity shall properly update the



247

Confidential

SIQ – The Second Partner shall initialize an empty SIQ section (1 byte with a zero MSB - see

section ‎5.2.7). The rest of the bits are reused for a Termination Cause Mask indicating which

termination errors shall be ignored during the SRST stage (see ‎5.4.5.1). The 2 MSBs of the SIQ

shall always be cleared to 0

Initiating Entity Reference (IER) – Reference to the Session Initiating Entity.


T-Adaptors Type Mask, such that the full reference of FDER:FPTM shall be the full reference for

the “First Partner” T-Adaptors entities participating in this session.


Partner” T-Adaptors Type Mask, such that the full reference of RSER:SPTM shall be the full

reference for the “Second Partner” T-Adaptors entities.

Session Requirements – A twelve (12) byte field which shall convey the updated session

requirements. These requirements shall be committed by each node on the path

SID – A one byte field which shall convey the new Session ID to be use by each node on the path,

until the session is terminated.

Full Path NPA – A Twelve (12) byte field sent by the Second Partner indicating the NPA of the

selected route with the effect of the new session. It is calculated by adding to the selected route

NPA (as received in the SRSL response or in the selected SRQ when there is no “Selecting Entity”)

the following quantities (TSR denotes This Session Requirements as in the SR sub-field at the

proper direction):

o Additional_P1_PSU = TSR_P1_PSU + (TSR_P2_PSU + TSR_P3_PSU)*PDS_Max_Count

: For a victim P1 packet, This Session P1 streams interfere only once in the path while This

Session Priority 2 and 3 streams may re-interfere with P1 packet at each SDME.

o Additional_P2_PSU = (TSR_P2_PSU + TSR_P3_PSU)*PDS_Max_Count: This Session

Priority 2 and Priority 3 streams may re-interfere with the victim P2 packet at each SDME.

o Additional_P3_PSU = TSR_P3_PSU : For a victim P3 packet, This Session P3 streams

may interfere only once in the path.

Additional Info – shall be the same as in the SRQ packet.

5.4.3.11 Session Creation Completed (SCC)

When the “First Partner” receives a successful SRST it shall use broadcast SSTS Response to inform all the

CPs in the network about the newly created session. The message shall be directed to broadcast Ethernet

MAC address, shall contain only one session status entry (the new one), shall set the „NW‟ bit in the session

status field and shall provide the PDS for the new session (see section ‎5.4.3.13).

5.4.3.12 Session Status (SSTS) Request

TBD


248

Confidential

5.4.3.13 Session Status (SSTS) Response

A Session Status Response messages shall be sent as a response for a SSTS request or whenever there are

changes in the sessions status. The message is a Direct Broadcast/Unicast HD_CMP message typically sent

over Ethernet. The sender may send up to 7 session status entries. The following use cases are an example

for SSTS response usage:

1. “First Partner” broadcast newly created session.

2. “Session Partner” broadcast terminated session.

3. SDME is responding to a CP SSTS request.

4. CP is responding to another CP SSTS request.

The following figure depicts the SSTS Response message format with its mapping to Ethernet packet:

RSNW TR

HD-CMP



Destination Entity

Device ID : TPG

Source Entity

Device ID : TPG

8 Bytes 8 Bytes

Destination MAC

Address

Source MAC

Address

Type: HD-CMP



Eth CRC

4 Bytes

Destination TPG

2 Bytes

Source TPG

2 Bytes

HD-CMP

Op Code

2 Bytes

Device ID Device ID

00000010 00111xxx

First Partner

T-Adaptors Ref

Second Partner

T-Adaptors Ref

Committed

SR10+ Bytes 10+ Bytes 12 Bytes

b0b3

Sessions

Number

AC SRDS TA

b0b7 b3

General

HD-CMP

Message

Mapping to Ethernet

Session 1

Status

Session 2

Status

Session 7

Status…Variable Variable Variable

Session

Status1 Byte

SID

1 Byte

Actual

SR12 Bytes

SSTS Response

Payload

SSTS Entry

Format

DS Input

Port ID2 Bytes

DS Output

Port ID2 Bytes

PDS

Up to 72 Bytes

PD

Initiating Entity

Reference8 Bytes

Additional Info

1+ Bytes

Full Path NPA

12 Bytes

Figure 186: Session Status Response OpCode and Payload Formats

Destination Entity Reference: Shall contain the requesting management entity or Ethernet

Broadcast address with zero TPG to broadcast this status to all CPs in the network.

Source Entity Reference: The management entity, sending this response, reference.

HD-CMP OpCode:

o Prefix - The 12 most significant bits shall be set to 0x023. Note that this is not a SNPM



mark response packet.

o Sessions Number – The three least significant bits b2:b0 shall convey the number of

session status entries transmitted with this message.


249

Confidential

Session Status Entries – The rest of the payload shall be a vector of session status entries which

shall contain the number of entries as listed in the OpCode‟s „Sessions Number‟ sub field (0 to 7).

Each Entry shall contain the following fields:

o SID : A one byte field which shall contain the SID for this session entry.

o Session Status – A one byte bit map field which shall convey the status code of the

session:

„TA‟ bit (b0) – Shall be set to one if any of the partners T-Adaptors references or

the Addition Info field have been updated.

„SR‟ bit (b1) – Shall be set to one if the Session Requirements field was updated,

this response packet contains the updated value.

„AC‟ bit (b2) – Shall be set to one if the Actual Session Requirements field is valid

in this entry. If this bit is zero, the receiver of this message shall ignore the

content of the Actual SR field (the sender still shall allocate the Actual SR field in

this entry).

„DS‟ bit (b3) – Shall be set to one if this session includes a DS path.

„PD‟ bit (b4) – Shall be set to one if this entry contains a PDS (PDS shall contain

only the occupied entries). If this bit is zero this entry shall not contain a PDS

(not allocated by the sender).

„RS‟ bit (b5) – Reserved bit. Shall be cleared to zero when transmitted and

ignored upon reception.

„TR‟ bit (b6) – Shall be set to one if this session is terminated.

„NW‟ bit (b7) – Shall be set to one if this is a new session just created. If set to

one, the „PD‟ bit shall be also set to one. After receiving a successful SRST, the

“First Partner” shall use this option to broadcast a successful session creation to

all CPs.

o Initiating Entity Reference (IER) – Reference to the Session Initiating Entity.

o First Partner T-Adaptors Reference (FPTR)- A 10+ byte reference (Device ID : TPG :

T-Adaptors Type Mask - see section ‎5.1.4) which shall hold the updated full reference for

the T-Adaptors entities, at the first partner device, to be participating in this session.

o Second Partner T-Adaptors Reference (SPTR)- A 10+ byte reference (Device ID : TPG :

T-Adaptors Type Mask - see section ‎5.1.4) which shall hold the updated full reference for

the T-Adaptors entities, at the second partner device, to be participating in this session.

o Committed Session Requirements - A twelve (12) byte field with the same format as the

NPA (see section ‎5.2.4.2) conveying the updated committed session requirements in terms

of available throughput and PSU budget from the sub network path.

o Actual Session Requirements - A twelve (12) byte field with the same format as the NPA

(see section ‎5.2.4.2) conveying real time measurements of the actual network resources

usage by the session. This field shall be valid only if the „AC‟ bit is set to one in the

session status field.


250

Confidential

o DS Input Port ID - A two byte field conveying the DS input port ID of the reporting device

used for this session. The SDME shall fill this field with valid port ID according to the „DS‟

bit in the session status field. In the case „DS‟ bit is zero the SDME may choose each of

the two ports, involved with this session, to be marked as „Input Port ID‟.

o DS Output Port ID - A two byte field conveying the DS output port ID of the reporting

device used for this session. The SDME shall fill this field with valid port ID according to

the „DS‟ bit in the session status field. In the case „DS‟ bit is zero the SDME shall choose

the „other port‟ (not the one marked as „Input‟) of the two ports, involved with this session,

to be marked as „Output Port ID‟ .

o Full Path NPA – A Twelve (12) byte field indicating the NPA of the session route.

o PDS : An up to 72 byte field which shall contain only the occupied PDS entries, conveying

this session PDS. This field shall be allocated only when the „PD‟ bit in the session status

field is set to one.

o Additional Info – Specifies the Additional Info for the session.

5.4.4 Session Maintenance

Each session partner shall send periodically a „by PDS‟ Session Maintenance Unicast SNPM (SMU)

encapsulated using a short form HLIC packet, the SMU message updates the session‟s descriptors at each

intermediate node along the session‟s path and keeps the session active. The period between transmissions

of consecutive SMU messages (of the same session) shall be no longer than smu_period (500msec). Upon

detection of a change in a session the session partner shall send a SMU message.

If a session partner does not receive a SMU message from the other session partner for a smu_aging_time

(2sec) it shall regard the session as terminated and send an SSTS termination message to the other Partner

and the Initiating Entity.

If a SDME does not receive a SMU message from a certain direction (for a certain session) for a

smu_aging_time (2sec) it shall regard the session as terminated.

The information conveyed in the SMU shall be used by the message receivers to update their Session

Descriptors (see ‎5.4.6).

5.4.4.1 Session Maintenance U_SNPM (SMU)

The following figure depicts the SMU message format with its mapping to a short form HLIC packet:


251

Confidential

Length HLIC

Short Form1 0 0 0 0 0 0

HD-CMP


2 Bytes

CRC-32


0 0 1 0

HD-CMP

Msg OpCode

Network Path

Availability

2 Bytes 12 bytes

FDER

Partner Entity

8 Bytes

RSER

Partner Entity

8 Bytes

PDS

Up to 72 Bytes

Per Op Code U_SNPM

Body

Variable Length

0 0 0 0 0 0 0 1 Dir1 1

Empty SIQ

1 Byte

b0b15 b8

U_SNPM

Format

SMU Specific

Body

Reserved SPAC Dir

First Partner

T-Adaptors Mask

Second Partner

T-Adaptors Mask

Partner Committed SR

2+ Bytes 2+ Bytes 6 Bytes

Session

Properties1 Byte

SID

1 Byte

Partner

Actual SR6 Bytes

Full Path

NPA12 Bytes

Figure 187: Session Maintenance U_SNPM OpCode and Payload Formats with their HLIC

Encapsulation

HD-CMP OpCode:


o U_SNPM Type – b7:b4 of the second byte shall represent the value „0010‟ marking the

SMU type.


o U_SNPM Dir – The sender shall set the Dir sub field properly.

FDER – The FDER field shall contain the full TPG reference (Device ID : TPG) of the target

partner.

RSER – The RSER field shall contain the full TPG reference (Device ID : TPG) of the sender

partner.

PDS – The sender shall properly initialize the PDS to the selected session route using only the





SIQ – The partner shall initialize an empty SIQ section (1 byte - see section ‎5.2.7).

SID – A one byte field which shall convey the Session ID.

Session Properties – A one byte bit map field which shall convey the properties of the session and

message:

o Dir (b1:b0) – Defines the direction of the session from the First to the Second Partner with

the same format as the Dir sub-field U-SNPM opcode (see ‎5.2.7).

o SP (b2) – Set to 0 if the sender is the First Partner, 1 if the sender is the Second Partner.


252

Confidential

o AC (b3) – Set to1 if the Partner Actual SR field is valid.

o The rest of the bits are reserved and shall be zero.


T-Adaptors Type Mask, such that the full reference of FDER:FPTM if the sender is the Second

Partner (SP bit of Session Properties is 1) or RSER:FPTM if the sender is the First Partner (SP bit

of Session Properties is 0) shall be the full reference for the “First Partner” T-Adaptors entities

participating in this session.


Partner” T-Adaptors Type Mask, such that the full reference of FDER:FPTM if the sender is the First

Partner (SP bit of Session Properties is 0) or RSER:FPTM if the sender is the Second Partner (SP

bit of Session Properties is 1) shall be the full reference for the “Second Partner” T-Adaptors

entities participating in this session.

Partner Committed Session Requirements - A six (6) byte field with the same format as the

US/DS Path Availability (see section ‎5.2.4.2) conveying the updated committed session

requirements in terms of available throughput and PSU budget from the sub network path in the

direction going out of the message sender.

Partner Actual Session Requirements - A six (6) byte field with the same format as the US/DS

Path Availability (see section ‎5.2.4.2) conveying real time measurements of the actual network

resources usage by the session in the direction going out of the message sender. This field shall be

valid only if the „AC‟ bit is set to one in the session properties field.

Full Path NPA – A Twelve (12) byte field indicating the NPA of the session route.

5.4.5 Session Termination

5.4.5.1 Session Termination U_SNPM (STU)

Session Termination U_SNPM messages shall be sent in order to inform all devices along the session path

that this session is terminating. The message shall target a session partner and the generator of the message

shall be the other session partner or one of the intermediate SDMEs along the path. These messages shall

be sent using short form HLIC encapsulation (see section ‎5.2.3.2) to reduce their latency and network

overhead. The sender and each intermediate SDME propagating this message shall free the committed

resources attached with this session upon message transmission and the destination partner shall free all

session resources upon reception of the message.

The following figure depicts the STU message format with its mapping to HLIC packet:


253

Confidential

ER

Length HLIC

Short Form1 0 0 0 0 0 0

HD-CMP


2 Bytes

CRC-32


0 0 1 1

HD-CMP

Msg OpCode

Network Path

Availability

2 Bytes 12 bytes

FDER

Partner Entity

8 Bytes

RSER

8 Bytes

PDS

Up to 72 Bytes

Per Op Code U_SNPM

Body

Variable Length

0 0 0 0 0 0 0 1 Dir1 1

Empty SIQ

1 Byte

b0b15 b8

U_SNPM

Format

STU Specific

BodySID

1 Byte

RSBR PA SRID TA

Termination

Cause1 Byte

PD

First Partner

T-Adaptors Ref

Second Partner

T-Adaptors Ref10+ Bytes 10+ Bytes

Initiating Entity

Reference8 Bytes

Figure 188: Session Termination U_SNPM OpCode and Payload Formats with their HLIC

Encapsulation

HD-CMP OpCode:


o U_SNPM Type – b7:b4 of the second byte shall represent the value „0010‟ marking the

STU type.


o U_SNPM Dir – The sender shall set the Dir sub field properly.

FDER – The FDER field shall contain the full TPG reference (Device ID : TPG) of the target

partner.

RSER – The RSER field shall contain the full TPG reference (Device ID : TPG) of the sender.

PDS – The sender shall properly initialize the PDS to the selected session route using only the





SIQ – The Second Partner shall initialize an empty SIQ section (1 byte - see section ‎5.2.7).

SID – A one byte field which shall convey the terminating Session ID.

Termination Cause Code – A one byte bit map field which shall convey the session termination

cause code :

o „TA‟ bit (b0) – Shall be set to one, by a session partner, if TPG or T-Adaptors type mask or

Adaptor Info is not valid (for example one of the listed T-Adaptors cannot participate).


254

Confidential

o „SR‟ bit (b1) – Shall be set to one, by a session partner, if Session Requirements are too

low.

o „PA‟ bit (b2) – Shall be set to one, by a SDME, if Session Requirements are too high for

this path availability.

o „ID‟ bit (b3) – Shall be set to one, as a response to SRST, if session ID is not valid.

o „PD‟ bit (b4) – Shall be set to one, by a SDME, if the PDS is not valid anymore, for

example when topology changes.

o „RS‟ bit (b5) – Reserved bit. Shall be cleared to zero when transmitted and ignored upon

reception.

o „ER‟ bit (b6) – Shall be set to one if there is a general error in one of the devices.

o „BR‟ bit (b7) – Shall be set to one, if the destination session partner shall transmit a

broadcast termination response to notify all CPs about this termination.

5.4.5.2 Session Termination Request

TBD

5.4.5.3 Session Termination Response

TBD

5.4.6 Session Descriptors

Each management entity shall maintain a knowledge base of session descriptors according to the following.

5.4.6.1 Session Descriptor Format

For each session the following figure shows the Session Descriptor.

SID - A one byte field which shall contain the SID for this session entry.

Session Properties – A one byte bit map field which shall convey the properties of the session:

o Dir (b1-b0) – Defines the direction of the session from the First to the Second Partner with

the same format as the Dir sub-field U-SNPM opcode (see ‎5.2.7).

o The rest of the bits are reserved and shall be zero.

Initiating Entity Reference (IER) – Reference to the Session Initiating Entity.


Type Mask - see section ‎5.1.4) to the session‟s First Partner device.


255

Confidential

Second Partner T-Adaptors Reference (SPTR) - A 10+ byte reference (Device ID : TPG : T-

Adaptors Type Mask - see section ‎5.1.4) to the session‟s second partner device.

Committed Session Requirements - A twelve (12) byte field with the same format as the NPA (see

section ‎5.2.4.2) conveying the updated committed session requirements in terms of available

throughput and PSU budget from the sub network path.

Actual Session Requirements - A twelve (12) byte field with the same format as the NPA (see

section ‎5.2.4.2) conveying real time measurements of the actual network resources usage by the

session.

Full Path NPA – A Twelve (12) byte field indicating the NPA of the session route.

PDS - An up to 72 byte field conveying the session‟s PDS.

5.4.6.2 Management Entity Session Database

Each management entity shall maintain a knowledge base regarding the HDBaseT sessions according to the

following, per entity, specification:

PDMEs – shall maintain a knowledge base containing its sessions‟ descriptors and T-adaptor

Additional Info. The knowledge is updated upon session creation (SRST), termination (STU, SSTS

termination).

SDMEs - shall discover and maintain a knowledge base containing descriptors of all session which

have this SDME as part of their path. The knowledge base is updated upon session creation (SRST),

maintenance (SMU) and termination (STU) or aging (lack of SMU).

CPMEs – shall discover and maintain a knowledge base containing all sessions. The knowledge

base is updated upon session creation and termination (SSTS). CPMEs may not store session‟s

PDSs.

RPE – shall conform to the CPME requirements, and store also PDSs.

5.5 Centralized Routing Scheme (CRS) Using Link state Routing

• In order to support session routing we need to monitor link status and discover optimal routes according to the

link status as defined in Chap. [TBD].

• Link status routing is applied to implement HDBaseT Session routing. RPE will send Link Status Request only

to SDME. The SDME of a device which received Link Status Request shall send its local connectivity

information, Link Status, to RPEs of other devices in the same sub network.

• One RPE may discover and interact with other RPE exchanging Routing Table Information

• A RPE of a device collects the link status updates, builds a complete network topology, and uses this topology

to compute paths to all destinations. Because a RPE of a node has knowledge of the full network topology,

there is minimal dependence among nodes in the routing computation.


256

Confidential

• All RPEs have complete topology information and link cost information by Link Status Notify packets. The

representation of link status and session routing information is defined in Chap. [TBD].

• All RPEs have the Link Status Table which represents global topology information and link cost information.

The Link Status Table is built and updated by receiving the Link status Notify messages after sending Link

Status Request. Link status includes TX port and RX port ID for indicating a specific HDBaseT Link, bandwidth

information and active session information.

• HD-CMP or HD-CMP over HLIC is used to transfer session routing information which includes the following

information types:

Link Status Notify

Session Initiation Request and Session Initiation Response

Session Route Request, Session Route Response

Session Release Request and Session Release Response

• HD-CMP over HLIC is to allow an End node on the edge links of the sub network to exchange HD-CMP

messages.

• RPE or SDME of a device can compute the optimal path and Session routing information from a source to a

sink based on link status information.

• Fig [TBD] illustrates the basic principle of session routing.


257

Confidential

Figure 189: CRS Session Routing Example

5.5.1 Link Status Notify

• The maintenance of link status is based on the flooding of “Link status Notify” messages. Each Device

manages its Session Routing information from valid Link Status Notify messages.

• A RPE can broadcast or unicast link status requests via Ethernet. According to the request the responding

device send a unicast or broadcast response.


258

Confidential

• Link status information can be exchanged between RPEs. If a RPE_A receives a Link Status Request from

another RPE_B, the RPE_B shall send Link Status Response to RPE_A with all link status information of all

devices.

• Session Routing Tables can be exchanged between RPEs via Unicast. Session Routing Table Request and

Session Routing Table Response are used to exchange RPE tables between RPEs.

• When a device receives new Link Status Notify message from other device, the message shall be added in its

Link Status Table.

• Figure [TBD] illustrates an example of Link Status Notify.

Figure 190: Link Status Notify Example

5.5.2 RPE for Session Routing

RPE is an entity which computes the optimal path and Session routing information from a source to a sink

based on link status information.

RPE manages and configures the Link Status Table and Session Routing Table of a device.

Link Status Table: When a device receives new Link Status Notify packets from other devices, the messages

are added in its Link Status Table.

Route Computation: a RPE computes the optimal paths to all Devices with Link Status Table by Dijkstra

algorithm.

Link Cost: Link Cost is base on the assigned bandwidth of the link.

The session routing mechanism using link state routing has 3 levels of route selection priority.

1. Higher Available Bandwidth of the route

Link cost is based on the total available bandwidth of the link.


259

Confidential

Link cost = 1 / (the total available bandwidth of the link)

3. Lower number of hops

Link cost is based on the number of hops. If a device has a link (a TX port) connecting it with another device

then the cost of link is 1.4. HighTh/MidTh/LowTh packet streams number

Link cost is based on the number of HighTh/MidTh/LowTh packet streams number[TBD].

Routing Table Management: Based on the computed route from source to destination, a RPE compute a TX

port for each destination and update Routing Table.

General RPE server function for nodes which don’t have RPE functions: On behalf of the node which

does not have a RPE or SDME, the RPE or SDME on the edge switch can compute routes for the sessions of

the node. The end node can communicate HD-CMP over the HLIC through the RPE or SDME on the switch.

5.5.3 Path Computation for Session Routing

RPE computes the optimal path and Session routing information from a source to a sink based on link status

information by the following steps.

Step 1: Assign to every node a link cost. Set it to zero for our source node (initial node) and to infinity for all

other nodes.

Step 2: Mark all nodes as unvisited. Set source device (initial device) as current node.

Step 3: For current device, consider all its unvisited neighbor devices and calculate their link cost (from the

initial device) by the bandwidth information in Link Status Table. Link cost is base on the assigned bandwidth

of the link as defined in Section [TBD]. Depending on the types of session data the link cost is calculated by

one of the following three cases.

Case 1: Downstream Session Data

Check the link cost of the downstream link (a TX port) connecting the device with another device. For

example, if current node (A) has link cost of 2, has a downstream link (a TX port) connecting it with

another device (B) and the link cost 2, then the link cost to B through A will be 6+2=8. If this link cost is

less than the previously recorded distance (infinity in the beginning, zero for the initial node), overwrite the

distance.

Case 2: Upstream Session Data

Check the link cost of the upstream link (a RX port) connecting the device with another device. For

example, if current node (A) has link cost of 2, has a upstream link (a RX port) connecting it with another

device (B) and the link cost 2, then the link cost to B through A will be 6+2=8. If this link cost is less than

the previously recorded distance (infinity in the beginning, zero for the initial node), overwrite the distance.

Case 3: Hybrid Session Data


260

Confidential

Check the link cost of both the downstream link (a TX port) and the upstream link (a RX port) connecting

the device with another device. For example, if current node (A) has link cost of 2, has a upstream (a RX

port) or downstream link (a TX port) connecting it with another device (B) and the link cost 2, then the link

cost to B through A will be 6+2=8. If this link cost is less than the previously recorded distance (infinity in

the beginning, zero for the initial node), overwrite the distance.

Step 4: When we are done considering all neighbor devices of the current node, mark it as visited. A visited

node will not be checked ever again; its link cost recorded now is final and minimal.

Step 5: Set the unvisited device with the smallest link cost (from the initial node) as the next "current node"

and continue from step 3.

5.5.4 Link State Update for Session Routing

The following steps show the basic operations of session routing of a device.

Step 1: The device finds neighbor Devices (by exchanging Device Status Request and Device Status

Response Message, or using periodic SNPM).

Step 2: The RPE sends Link Status Request Messages to devices requesting link information.

Step 3: The devices which received the Link Status Request makes Link Status Notify Message.

Step 4: The devices sends Link Status Notify Message.

Step 5: The RPE collects the Link Status Notify Messages from the other devices.

Step 6: From the received Link Status Notify Messages the RPE updates Link Status Table.

Step 7: RPE computes the optimal routes to all Devices with Link Status Table by Dijkstra algorithm.

Step 8: Based on the path information from source to destination, RPE computes a TX port for each

destination and update Session Routing Table.

5.5.5 Session Control Packets for Session Routing

HD-CMP or HD-CMP over HLIC is used to transfer session routing information which includes the following

information types:

Link Status Notify

Session Initiation Request and Session Initiation Response

Session Route Request, Session Route Response

Session Release Request and Session Release Response


261

Confidential

5.5.5.1 Link Status Notify Packet

This packet is used to notify the link status information of a HDBaseT link. The message can be sent by Direct

Ethernet message (either unicast for a specific RPE or broadcast to all RPEs) between two management

entities in the HDBaseT subnetwork.

Figure 191: Link Status Notify Packet Structure

Table 48: Link Status Notify

Definition Remark

HD-CMP Msg OP

Code

Link Status Notify Message

Response Code • 000: Reserved • 001: Success- Request has been completed successfully • 010: Redirection- Request should be tried at another device

• 011: Sender Error- Request was not completed because of an error in the request, can be retried when corrected

• 101: Receiver Error- Request was not completed because of an error in the recipient, can be

retried at another device • 110:Global Failure - Request has failed and should not be retried again

Length Active Session Information data byte length including this header. Length is dependant on

the number of discovered Sessions on the link

TX Device ID Sender‟s Device ID

TX Port ID TX Port ID of Sender‟s Device

RX Device ID Immediate (directly connected) Neighbor‟s Device‟s Device ID

RX Port ID RX Port ID of Immediate (directly connected) Neighbor‟s Device‟s Device ID

Operation Mode the current operation mode of that link (LPPF #1, LPPF #2, Active 8G…)


262

Confidential

Total Downstream

Bandwidth

Maximum Bandwidth of the Downstream link

Available

Downstream

Bandwidth

Available Bandwidth of the Downstream link

Total Upstream

Bandwidth

Maximum Bandwidth of the Upstream link

Available

Upstream

Bandwidth

Available Bandwidth of the Upstream link

5.5.5.2 Link Status Request Packet

This packet is used to request the link status information of HDBaseT links. The message can be sent by

Direct Ethernet message (either unicast for a specific RPE or broadcast to all RPEs) between two

management entities in the HDBaseT subnetwork.

Definition Remark

HD-CMP Msg OP Code

Link Status Request Message

Link Status Request Type

Link Status Request Type

• 00: The Link status Information of all devices which the receiver knows • 01: The Link status Information of all immediate neighbor devices of the receiver • 10: The Link status Information of the receiver

• 11: The specific link information indicated by this request.

Length data byte length including this header. Length is dependant on the number of links





263

Confidential


Figure 192: Link Status Request Packet Structure

5.5.5.3 Session Status Table

This table is used to manage the link status information of all available links found in the network. When a

device receives new Link Status Notify message from other device, the message shall be added in its Link

Status Table.

Figure 193: Link Status Table Example

Definition Remark





Total Bandwidth Maximum Bandwidth of the link

Available Downstream Bandwidth

Available Bandwidth of the Downstream link

Available Upstream Bandwidth

Available Bandwidth of the Upstream link

Assigned Session IDs

The Session IDs of active sessions on the TX port ID of the device


264

Confidential

Table 49: Link Status Table

5.5.5.4 Session Routing Table

This table is used to manage the session routing information of all available TX ports of a device. Based on

the path information from a source to a destination computed by RPE, a RPE of a device computes a TX port

ID for each destination and updates the TX port ID field of its Session Routing Table.

Figure 194: Session Routing Table Example

Definition Remark

Sink ID device ID of sink device


Routing Path The ordered Path Information from the Source and Sink represented by PDS of HD-CMP.

Assigned Session IDs

The Session IDs of active sessions on the TX port ID of the device

Table 50: Session Routing Table


265

Confidential

5.5.5.5 Session Routing Table Request

TBD

5.5.5.6 Session Routing Table Response

TBD

5.5.6 Bandwidth Assessments and Reservation for Session Routing

5.5.6.1 Bandwidth Verification for Session Routing

To send Session Route Response, a RPE should verify all links in the routing path have enough bandwidth to

route the session data.

The following figure illustrates the basic operations of bandwidth verification of a Central RPE:


266

Confidential

Figure 195: Bandwidth Verification for CRS

The following steps show the basic operations of bandwidth verification of a device for session routing.

Step 1: A device receives a Session Route Request.

Step 2: Set the Source ID in the Session Route Request as the start node of bandwidth verification

Step 3: The RPE verifies that Sink ID of the Session Route Request is in its Session Routing Table. If the

Sink ID is not present in the session routing Table then the device sends Session Initiation Response (NACK,

non-zero OP code).

Step 4: The RPE verifies that a TX port ID to route session data to the Sink ID is in its Session Routing Table.

If a TX port ID is not in its Session Routing Table (all the TX ports are not available to route the session data)

then the device sends Session Initiation Response (NACK, Not a Success Response Code).


267

Confidential

Step 5: The RPE verifies that the selected TX port has enough bandwidth available both for upstream and

downstream to route the session data. If the available upstream bandwidth of the TX port is smaller than the

upstream data size of the session then the device sends Session Initiation Response (NACK, Not a Success

Response Code) not to allow Session Initiation Request. If the available downstream bandwidth of the TX port

is smaller than downstream data size of the session data then the device sends Session Initiation Response

(NACK, non-zero OP code) not to allow Session Initiation Request.

Step 6: The RPE verifies that all links in the routing path have enough bandwidth to route the session data. If

any node in the routing path is to be verified for bandwidth, the RPE sets the next node in the routing path as

the node of bandwidth verification

Step 7: if all links in the routing path have enough bandwidth to route the session data, the device sends

Session Initiation Response (ACK, zero OP code).

5.5.7 Session Routing Examples

• The following figure illustrates an example of session routing from Source BDP (Device ID = A) to Sink TV

(Device ID = H):

Figure 196: Session Routing Example – BDP is the Initiating Entity with RPE


268

Confidential

• The Session connection shall be initiated by the Control Point, Source or Sink device sending Session Initiation

Requests.

• In the case of CRS the RPE in the control point computes the best path from Source and Sink. The RPE send

the best route path in the session Initiation Request at the form of PDS from here the method should be similar

to DRS [Need detail].

• In the above session initiation example, the source device, BDP, is the Session Initiator. Control Point has a

RPE which manages global link status information and routing table from BDP to TV. Session Route Requests

may be not needed since RPE can verify all nodes and links in the route from the source to the sink by

exchanging link status information with devices in the subnetwork.

• The RPE shall send Session Initiation Requests to the Source and the Sink.

• Each Session Initiation Request shall be successfully completed with reception of a successful OP code in the

Session Route Response before proceeding on the next request. The RPE shall abort the session initiation

process immediately if any Session Initiation Response has a failure OP code.

• Sink and intermediate devices (switches and/or daisy chain devices) in the route shall respond to each Session

Initiation Request and Session Route Set with an OP code in the Session Route Response packet according to

its resource (Link, Port, and Device) status within Session Route Set Timer, TBD second. If a RPE does not

receive the Session Route Responses from the Source, Sink and all intermediate devices within Session Route

Set Timer (TBD second) then the RPE shall abort the session initiation process immediately.

• For Multi Session Support, a source may have multiple Session outputs at a single port and a Sink may have

multiple Session inputs a single port.

•


269

Confidential

Figure 197: Session Routing Example – CP is the Initiating Entity with RPE

5.5.7.1 Link Status Notify examples

Figure [TBD] show the examples of Link Status Notify packets to support the session routing. When a device

receives new Link Status Notify packets from other devices, the messages are added in its Link Status Table.


270

Confidential

Figure 198: Link Status Notify for Session Routing - Example

5.5.7.2 An example of Operation of RPE

The RPE of each device computes the optimal paths to all devices in its Link Status Table by Dijkstra

algorithm.

Based on the computed route from source to destination, a RPE compute a TX port for each destination and

update Routing Table.

Fig [TBD] illustrates an example of the operations of RPE of Switch (ID = C) for session routing example from

Source A to Sink H.


271

Confidential

Figure 199: Operation Example of RPE implemented on SDME (ID=C)

5.5.7.3 An example of Routing Table for Session Routing

• Fig [TBD] illustrates an example of session routing from Source A to Sink H. In Figure [TBD] session routing

configures a HDBaseT route from the HDMI Source port of Source A to the HDMI Sink port of Sink H

supporting the level 3 referencing.


272

Confidential

Figure 200: An example of Routing Tables for Session Routing. Source ID = A (BDP), Sink ID = H (TV).

5.5.8 Dijkstra’s Algorithm

Let the node we are starting be called an initial node. Let a distance of a node Y be the distance from

the initial node to it. Dijkstra's algorithm will assign some initial distance values and will try to improve them

step-by-step.

Step 1: Assign to every node a distance value. Set it to zero for our initial node and to infinity for all other

nodes.

Step 2: Mark all nodes as unvisited. Set initial node as current.

Step 3: For current node, consider all its unvisited neighbors and calculate their distance (from the initial

node). For example, if current node (A) has distance of 6, and an edge connecting it with another node (B) is

2, the distance to B through A will be 6+2=8. If this distance is less than the previously recorded distance

(infinity in the beginning, zero for the initial node), overwrite the distance.

Step 4: When we are done considering all neighbors of the current node, mark it as visited. A visited node will

not be checked ever again; its distance recorded now is final and minimal.

Step 5: Set the unvisited node with the smallest distance (from the initial node) as the next "current node" and

continue from step 3.


273

Confidential

Figure 201: An example of Link State Packets for Link State Routing Using Dijkstra’s algorithm

Figure 202: An example of Link State Table for Link State Routing Using Dijkstra’s algorithm


274

Confidential

Figure 203: An example of Routing Tables for Link State Routing Using Dijkstra’s algorithm


275

Confidential

6 Ethernet over HDBaseT

6.1 General

In active mode, an HDBaseT port of a switch device shall support Ethernet data transmission, while an

HDBaseT port of an end-node device may support Ethernet data transmission. Each end node device shall

mark in its HDCD its support for Ethernet transmission. Each HDBaseT port device shall be able to receive

correctly Ethernet over HDBaseT data even if its upper layers do not support it. When supported, Ethernet

data shall be transmitted, continuously, bi-directionally, over the HDBaseT Downstream and Upstream sub

links. Ethernet data shall be transmitted using, Retransmission-Protected, Ethernet over HDBaseT packets

(packet type = 1) with the associated Transfer-Quality, Scheduling-Priority properties as in Table 7.

Although actual implementation may be different, for the clarity of the description, the following section

assumes that the interface between the Ethernet MAC/Switch entity and the HDBaseT source/sink entity is

MII (according to IEEE Std 802.3-2005 section 2) or RMII (according to RMII Consortium RMII Specification

Rev 1.2 Mar 20 1998) and uses signal names defined in these specifications.

Ethernet data, coming from the MII/RMII interface, is encoded first in 65-bit blocks, as described hereafter.

These 65-bit Ethernet data blocks are sent over the HDBaseT link and on the other end are decoded back to

the Ethernet Data transferred to the MII/RMII.

The HDBaseT Link rate is assumed to be asynchronous with both end MII/RMII ref clocks therefore an

HDBaseT device shall apply clock compensation when decoding the HDBaseT 65-bit blocks back to the

MII/RMII interface as described in ‎6.1.2.

6.1.1 MII/RMII I/F to HDBaseT

Before being encoded to 65-bit blocks, the data received from the MII/RMII I/F is mapped into octets. These

octets contain either Data or Control information.

The Data octet is formed from the MII Nibbles or the RMII Di-Bits as described below:

MII First Nibble

b7 b6 b5 b4 b3 b2 b1 b0

MII Second Nibble

RMII First

Di-Bit

RMII Second

Di-Bit

RMII Third

Di-Bit

RMII Fourth

Di-Bit

D7 D6 D5 D4 D3 D2 D1 D0

Figure 204: Ethernet Over HDBaseT Data Octet

The Control octets are used to pass Idle, Error, Start-of-Stream delimiter (SSD) and End-of-Stream delimiter

(ESD) information:


276

Confidential

Idle control shall be transmitted between Ethernet data streams to support continuous transmission

over the HDBaseT Link; it is transmitted at the Ethernet rate whenever there is no Ethernet data to

transmit (TX_EN is de-asserted).

Error control shall be used to propagate TX_ER received from the MII I/F (not used in RMII) over the

HDBaseT Link, it is transmitted instead of the related data.

The SSD and ESD controls are used to describe the boundary of the Ethernet data stream

transmitted. They are derived from the TX_EN signal, and inserted between Data and IDLE octets.

SSD shall be inserted to the 65-bit Ethernet block encoder after the last IDLE control octet and

before the first Data octet received from the MII/RMII interface. ESD shall be inserted to the 65-bit

Ethernet block encoder after the last Data octet received from the MII/RMII interface and before the

first IDLE control.

The coding of Ethernet control types is described below:

Table 51: Ethernet Control Types

Control Type Type Description

00 IDLE Idle indication

01 ERROR Error indication

10 SSD Start of stream delimiter

indication

11 ESD End of stream indication

The result is an octet stream which includes the added control octets. This stream is passed to the 65-bit

block encoder.

Each 8 octets (64-bits) are encoded into one block which is transformed to a 65-bit block by adding one bit to

indicate whether this block contains control information. Formal description of this 64B/65B coding is

described in “Generic framing procedure (GFP) - ITU-T Rec. G.7041/Y.1303 (08/2005)” document. A

simplified description of this coding scheme is presented here as well.

Ethernet data octets are not changed while Ethernet control octets are moved to the beginning of the 65-bit

block and filled as described below:

NEXTOriginal

Position

Control

Data

Control

Type

b7 b6 b5 b4 b3 b2 b1 b0

Figure 205: Ethernet Over HDBaseT Control Octet

Next (b7) – a bit that indicates that the next octet is a control octet. When this bit value is zero (0), the

next octet is a data octet.


277

Confidential

Original Position (b6,b5,b4) – three bits that indicate the original position of this control octet in the

original pack of eight (8) octets.

Control Data (b3,b2) – Used with the ERROR Control indication to store the two LSB‟s of the

erroneous Data Octet (i.e. D1,D0 in Figure 204), in order to force Error on the data as described in

section ‎6.1.2. Otherwise, set to zero.

Control Type (b1,b0) – two bits that indicate the control type as described in Table 51.

An example for the 64B/65B coding is described below:

Octet number 000 001 010 011 100 101 110

Byte stream D1 C1 D2 D3 D4 C2 D5

111

D6

Octet number 000 001 010 011 100 101 110

Byte stream 1 001 C1 0 101 C2 D1 D2 D3 D4 D5

111

D6

F

1

This block

contains

control

Next

octet is

control as

well

Original

octet

position

Control

InformationNext

octet is

data

Figure 206: 64B/65B Scheme

6.1.2 HDBaseT to MII/RMII I/F

The 65-bit blocks received from the HDBaseT Link shall be decoded and transferred to the MII/RMII interface,

using a sufficient elastic buffer and clock compensation procedure to compensate for the frequency difference

between the MII/RMII Ref Clocks on both ends of the HDBaseT link. An HDBaseT source and sink shall

tolerate +/- 200ppm frequency difference including support for jumbo packets.

The clock compensation procedure is done by omitting or inserting an extra Idle control octet towards the

MII/RMII interface (de-assertion of RX_DV / CRS_DV). The clock compensation procedure shall not violate

the minimum received 36 bit Inter Packet Gap (IPG) requirement.


278

Confidential

Reception of an Idle octet from the HDBaseT Link will cause the RX_DV signal on the MII I/F or CRS_DV

signal on the RMII I/F to remain de-asserted. The RX_DV/CRS_DV signal shall be asserted only upon

reception of a SSD control octet. When the RX_DV/CRS_DV is asserted the first octet transferred to the

MII/RMII shall be the content of the next octet after the SSD control octet (the SSD octet was inserted at the

MII/RMII to HDBaseT direction and dropped at the other direction). The RX_DV/CRS_DV signal shall be de-

asserted upon reception of ESD/Idle control from the HDBaseT Link. The reception of an ESD control octet

shall not consume an octet period towards the MII/RMII (the ESD octet is inserted at the MII/RMII to

HDBaseT interface and dropped at the opposite interface).

Since Ethernet over HDBaseT uses octets, Reception of an Error Control Octet from the HDBaseT Link will

cause the RX_ER signal on MII/RMII I/F to be asserted on Byte boundary (i.e two MII Nibbles or four RMII Di-

Bits). In order to force Error on the MII Data (RXD) along with the assertion of RX_ER, the Control Data bits

(b3,b2 in Figure 204) are inverted and transmitted on the MII RXD[1:0] Data bus. For RMII I/F the Data on

RXD[1:0] should be “01” along with assertion of RX_ER as described in the RMII Specification.

It is recommended that, upon reception of a 65-bit Ethernet data block from the HDBaseT Link with a Bad

CRC Indication, the error indication will be propagated toward the Ethernet entity, by replacing all 8 octets of

that block with Error Control Octets.

The Ethernet over HDBaseT protocol supports False Carrier Indication. False Carrier is detected when data or

control octets other than SSD are received after an IDLE octet. A False Carrier event shall cause the

assertion of RX_ER and force RXD[3:0] to be “1110” on MII I/F, or RXD[1:0] to be “10” on RMII I/F.

A summary of the Ethernet Error Handling is described in the table below:

Table 52: Ethernet Error Handling

MII RXD RMII RXD

ERROR Propagated 000000 b3¯¯ b2¯¯ 01010101

False Carrier Indication 11101110 10101010

6.2 Downstream Ethernet Packets

The Ethernet data is packed in 65-bit blocks as described above. Each Ethernet downstream packet carries

the information contained in twelve (12) 65-bit blocks (780 bits) that are mapped to TokDx tokens, according

to the link conditions as explained in ‎2.2.2. As a result the following full payload structures shall be created

per error resistance level:

Payload Token Type is TokD16 – 4 TokD12 + 46 TokD16 (where the last token‟s most-significant

nibble serves as zero padding) to give a total of 50 payload tokens with an additional extended

control info token, at the packet header, marking the zero padding at the last token (see ‎2.2.3.11).

Payload Token Type is TokD12 – 65 TokD12 tokens


279

Confidential

Payload Token Type is TokD8 – 98 TokD8 tokens (where the last token‟s most-significant nibble

serves as zero padding) with an additional extended info token, at the packet header, marking the

zero padding at the last token.

The following figure depicts an example of mapping the twelve (12) Ethernet 64B/65B blocks to TokD12

tokens:





LSB

LSB



. . .

. . .

Figure 207: Downstream - 64B/65B Blocks to TokD12 Tokens Assignment

The twelve 65-bit blocks form a 780 bit long sequence that is mapped, starting from the LSB of the first block

to the MSB of the last block, over the HBaseT tokens, from the LSB of the first token towards the MSB of the

last token. The last token MSBs are zero padded as needed. The tokens are placed in the packet‟s payload

according to the order of creation (starting from Ether-1 in the above example).

Downstream Ethernet packets shall be transmitted periodically with a period of 12*8bytes/block=96 Ethernet-

bytes (7.68uSec for 100MbE). The period shall be accurate up to the scheduling interference caused at the

transmitter function.

In the case that at least one of the twelve (12) 64B/65B blocks contains only Idle control octets (“Idle Block”)

the transmitter shall transmit a Sparse Ethernet over HDBaseT packet with the following format:

Session

ID (0)… Idle…

Payload

TokD8

Packet

Type

TokPtp

Header Tail

RTS

Header

TokD8 TokDxx TokCrc TokIdl

Payload

Length

TokD8 TokCrcTokCrcTokCrc

CRC 32Control

Ext Info

Generic

Ext Info

Generic

Ext Info

TokD8 TokD8 TokD8

Extended Info


1 Extended Info


011

1Nibbles

Pad Num

Bad

CRC0 0 01


0 0 B12 B11 B10 B9 B8 B7 B6 B5 B4 B3 B2 B1

Packet Type

Token

Type 1 0 0 0 11

Figure 208: Sparse Ethernet Packet format

The Sparse Ethernet packet header shall contain 3 extended info tokens; the first one is an Extended Control

Info token marking Bad CRC and zero padding nibbles as needed. The second and third are Generic

Extended Info tokens conveying a 12 bit bitmap as defined in the above figure where each one of the B1 to

B12 bits represents, if set to one, that the corresponding 64B/65B block is an Idle Block. For example if B2 is

set to one then the second 64B/65B block is an Idle Block. Idle Blocks data is not transferred in the sparse

packet payload, the non Idle Blocks data bits, are continuously mapped into the sparse packet payload tokens

as described for a full Ethernet packet. Note that the last token zero-padding may not be in nibble quantas.


280

Confidential





LSB

LSB



. . .

. . .

Figure 209: Sparse Packet - 64B/65B Blocks to TokD12 Tokens Assignment - Example

In the above example 64B/65B block 2 is an Idle Block therefore it is omitted from the bit sequence that is

being converted to the TokD12 payload tokens. Since there are actually eleven (11) 64B/65B blocks or 715

bits, the first 708 data bits are converted to 59 full TokD12 tokens, the remaining 7 bits are complemented to

two nibbles by adding one zero MSbit and these two nibbles, with an additional one zero MSNibble padding,

are placed in an additional TokD12 token for a total of 60 TokD12 payload tokens. The extended control info

token in the packet header shall hold the indication for this one nibble padding while the Ethernet E-Adaptor

shall also ignore the one extra zero padding bit when it is extracting the last 64B/65B block from the packet

payload.

In the case that all twelve (12) blocks are Idle Blocks (no actual data is needed to be transferred in the packet

payload) the transmitter shall mark it properly in the packet header and add a dummy payload token (since all

packets must contain at least one payload token).

6.3 Uptream Ethernet Packets

Please refer to ‎2.3.3 and ‎2.4.2.


281

Confidential

7 HDMI over HDBaseT

7.1.1 DDC over HDBaseT Link

VESA DDC, is based on the I²C bus and protocol. It is a two wire protocol to transfers bi-directional data.

Figure 210: Data Transfer on the I²C Bus

To transfer it over HDBaseT, the data is parsed and extract at one side and sent over to the other side where

it is reconstructed according to DDC/I²C specification. DDC is a fixed master/slave configuration in which the

source of the A/V stream always acts as the master and the sink of the A/V stream always acts as the slave.

In HDBaseT, all transactions in the direction of master to slave (e.g. device address, write data and master

acknowledge) are been transferred over the Downstream link and all transactions in the direction of slave to

master (e.g. read data and slave acknowledge) are been transferred over the Upstream link:

1. Master to Slave

a. Start Condition and Repeated Start Condition

b. Stop Condition

c. Data bit “1” / Master Not Acknowledge

d. Data bit “0” / Master Acknowledge

2. Slave to Master

a. Data bit “1” / Slave Acknowledge

b. Data bit “0” / Slave Not Acknowledge


282

Confidential

The actual mapping of the above information into HDBaseT packets are further explained in sections ‎7.1.1.1

and ‎7.1.1.2.

7.1.1.1 I²C Slave I/F in the Source

The slave unit translates the incoming I²C stream and extracts the information need to be transmitted to the

sink side (“Master to Slave” list above) over the Downstream sub link (see ‎7.1.4.8 for AV control packet

format). It receives the data from the sink side (Slave to Master” list above) over the Upstream sub link (see

‎2.3.4.1 for AV control upstream format) at the same time and reconstructs the transaction over the same I²C

interface.

A typical transaction is built as follows: START ADDRESS(6:0) DIRECTION ACKNOWLEDGE

… where all information except the acknowledge is directed from the source to the sink and the acknowledge

is directed from the sink to the source. Since the acknowledge information needs to travel all the way from the

sink device (e.g. TV) through the HDBaseT sink to the HDBaseT source and the “I²C Slave I/F”, the source

device‟s (e.g. DVD) “I²C Master I/F” needs to be stalled until the right information is available. This operation is

referred to as “stretch” in the I²C specification and is done by pulling down SCL line while the slave is not

ready yet with the information to the master.

The same stretching sequence is done on read transactions where the SCL is derived by the source and the

SDA is derived by the sink. In this case the HDBaseT source ““I²C Slave I/F” may stretch the SCL line until it

receives the read information from the sink side.

HDBaseT

Sink

HDBaseT

Source

UpstreamSource Device (e.g. DVD) Sink Device (e.g. TV)

I²C

Master

I²C

Slave

I²C

Slave

I²C

Master

Downstream

Link DelayStretchingStretching

Figure 211: HDBaseT I2C Flow

The duration of the stretching is affected by:

1. The I²C bit-rate differences between the source device (e.g. DVD) and sink device (e.g. TV). If the

source device generates I²C transactions at 100Kbps and the sink device can only conform to

50Kbps (meaning it stretches the HDBaseT sink‟s “I²C Master I/F”), the amount of stretching is

propagated to the source side.

2. The I²C bit-rate differences between the source device (e.g. DVD) and HDBaseT sink. If HDBaseT

sink‟s “I²C Master I/F” will generate I²C transaction at bit rate that is less than the bit rate that is

generated by the source device (e.g. DVD), then the stretching period will increased.


283

Confidential

3. The delay of the HDBaseT link. The time it takes for I²C information to pass through the Downstream

link must not exceed 2µS and for the I²C response information to pass through the Upstream link

must not exceed 2µS.

7.1.1.2 I²C Master I/F in the Sink

The master unit receives the data from the source side (“Master to Slave” list above) over the Downstream

sub link (see ‎7.1.4.8 for AV control packet format) and reconstructs the transaction over the same I²C

interface. It translates the incoming I²C stream at the same time and extracts the information need to be

transmitted to the source side (“Slave to Master” list above) over the Upstream sub link (see ‎2.3.4.1 for AV

control upstream format).

The HDBaseT “Master I²C” at the sink side should generate its I²C transactions at the maximal bit-rate

(100Kbps).

Example

Consider the following I²C transaction:

Start 0 0 1 1 0 0 1Slave

AckRead 1 1 0 0 1 1 0Master

NAck Stop

SCL

SDA

0

Device Address Data

Figure 212: An Example of I2C Transaction

The master request to read one byte from the slave at address 0x19 and in response it gets the data 0xCC

(from the salve at address 0x19).

The information sequence that is generated by this transaction is:

Master sends Start Master sends 0 Master sends 0 Master sends 1 Master sends 1 Master

sends 0 Master sends 0 Master sends 1 Master sends 1 (Read) Slave sends 0 (Slave Ack)

Slave sends 1 Slave sends 1 Slave sends 0 Slave sends 0 Slave sends 1 Slave sends 1

Slave sends 0 Slave sends 0 Master sends 1 (Master NAck) Master sends Stop

With HDBaseT, this information will be send Downstream (master to slave information – marked in red) and

Upstream (slave to master – marked in blue) as follows:


284

Confidential

I²C S

lave I/F

at

So

urce S

ide

Start

Bit 0

Bit 0

Bit 1

Bit 1

Bit 0

Bit 0

Bit 1Bit 1 (read)

Bit 0 (acknowledge)

Bit 1

Bit 1

Bit 0

Bit 0

Bit 1

Bit 1

Bit 0

Bit 0

Bit 1 (not acknowledge)Stop

I²C M

aster I/F at

Sin

k S

ide

stre

tch

HDBaseT LinkSource

Side

Sink

Side

I²C To DVD I²C To TV

Figure 213: An Example of I2C Transaction over HDBaseT

The stretching periods at the source side are the periods in which the I²C slave I/F at the source side waits for

the data to come from the sink side. During this time it holds down the SCL so the I²C Master at the source

device (e.g. DVD) will wait for the data as well.

7.1.2 CEC over HDBaseT Link

CEC is a bi-directional line that carries Consumer Electronic Control information, as described in the

supplemental to the HDMI-1.3 spec.

To transfer CEC over HDBaseT, the CEC line value/state is transferred from one side to the other, according

to the CEC traffic direction.


285

Confidential

CEC direction is defined by the Initiator and the Follower so that the data bit flows from the Initiator to the

Follower, with the exception of the acknowledge bit that flows from the Follower to the Initiator. CEC word

consists of 10 bits: 8 data bits, one EOM (End-Of-Message) bit and one ACK (Acknowledge) bit. The 8 data

bits and the EOM bit are sent from the Initiator to the Follower and the ACK bit is sent at the opposite

direction, from the Follower to the Initiator. Both the source and the sink can be Initiator of CEC transaction or

follower to a CEC transaction. There is only one Initiator in a CEC network at any one time. The CEC spec

defines arbitration and collision resolve procedures to handle the Initiator selection.

When HDBaseT Source is acting as Initiator, it Shall monitor its respective CEC line and shall inform a

change in the CEC line, caused by its respective HDMI source, by transmitting the new state of the CEC line

over the HDBaseT Downstream sub link. For system consistency, CEC state Shall be transmitted at least

once every 5 milliseconds over the HDBaseT Downstream sub link, in addition to change notifications.

When HDBaseT Source is acting as Follower, it Shall transmit CEC HIGH level notifications (at least once

every 5 milliseconds) over the HDBaseT Downstream during all the CEC data bits, with the exception of the

acknowledge bit. A detailed explanation is followed, concerning the acknowledge bit sequence.

When HDBaseT Sink is acting as Initiator, it Shall monitor its respective CEC line and inform a change in the

CEC line, caused by its respective HDMI sink, by transmitting the new state of the CEC line over the

HDBaseT Upstream sub link. For system consistency, CEC state Shall be transmitted at least once every 5

milliseconds over the HDBaseTUpstream sub link, in addition to change notifications.

When HDBaseT Sink is acting as Follower, it Shall transmit CEC HIGH level notifications (at least once every

5 milliseconds) over the HDBaseT Upstream during all the CEC data bits, with the exception of the

acknowledge bit. A detailed explanation is followed, concerning the acknowledge bit sequence.

Upon reception of a CEC line state notification over the HDBaseT link, the HDBaseT Source / Sink Shall alter

its respective CEC line state if needed, to match the notified state. The maximal time for CEC line to be

asserted low (by HDBaseT Source or Sink) is 7 milliseconds after which it should be released to high (one) by

any one of HDBaseT Sink or HDBaseT Source. This is done to prevent deadlock scenarios in which both

sides hold their CEC line low.

The task of identify and decide which side is the Initiator and which is the follower is implementation

dependent and out of scope for this document. Any implementation of this function should provide the

following:

Direction Resolve (e.g. Initiator, Follower).

Bit Track (e.g. data bit, acknowledge bit, bit timing).

Conflict Monitoring (e.g. receiving CEC HIGH level notification form HDBaseT link but respective

CEC line is held LOW by target device (TV or DVD). This scenario should end up with direction

change).

De Bouncing (e.g. preventing wrong direction changes, for example due to pull up delay time CEC

line may considered LOW while it is actually turning to HIGH as a result of change notification

coming from the HDBaseT link).

7.1.2.1 CEC traffic direction

In order to better explain the CEC direction and its effect on HDBaseT, this section gives an example of the

direction issue in a descriptive way.


286

Confidential

Since CEC is bi-directional, it has to be divided into two associated signals, ”CEC_To_HDBT” and

“CEC_From_HDBT” (much like an open drain behavior):

CEC_To_HDBT

CEC

CEC_From_HDBT

The “CEC_To_HDBT” is a reflection of “CEC” whenever “CEC_From_HDBT” is logically high (“1”). When

“CEC_From_HDBT” is logically low (“0”), the “CEC” is forced to low and “CEC_To_HDBT” is released to high

(“1”). This behavior enables the following directions:

Table 53: CEC directions

CEC_From_HDBT CEC_To_HDBT CEC Data

Flow

Direction

LOW Don‟t Care From

HDBaseT

side to

HDMI side

HIGH LOW From HDMI

side to

HDBaseT

side

HIGH HIGH Not

determined.

Usually,

keeping the

same

direction as

was before

A general view of a CEC system is shown in the following figure


287

Confidential

CEC_To_HDBaseT

CEC_From HDBaseT

Src Link

LayerHDBaseT

Downstream

Snk Link

Layer

CEC CEC

CEC

Direction

Resolver

CEC

Direction

Resolver

HDBaseT

Upstream

HDBaseT Source HDBaseT Sink

CEC_From HDBaseT

CEC_To_HDBaseT

DVD TV

Figure 214: CEC over HDBaseT system view example

When the source device (i.e. DVD) is acting as Initiator, the HDBaseT Sink, acting as Follower, will release its

"CEC_To_HDBaseT" line to HIGH level. This information will be transmitted in each CEC slot of the Upstream

packet (see TBD), resulting the "CEC_From_HDBaseT" line of the HDBaseT Source to signal constant HIGH

level. In this case, the "CEC_To_HDBaseT" line of the HDBaseT Source will reflect the CEC line of the source

device (i.e. DVD) and will generate state notifications on the HDBaseT Downstream whenever the CEC line

will change its state or every 5 milliseconds. This will further be reflected on the "CEC_From_HDBaseT" line

of the HDBaseT Sink and on to the sink device (i.e. TV) CEC line.

The same applies in the case where the sink device acts as Initiator.

The "CEC Direction Resolver" block is responsible for the task of identify and decide which side is the Initiator

and which is the follower and the related sub tasks, as described above.

7.1.2.2 Compensating for extra pull up

In pure HDMI system, the CEC protocol compensate for one pull-up rising time delay ("CEC 4: Electrical

Specifications" chapter in HDMI-1.3 specification). In HDBaseT link, there are two such pull ups, one in the

HDMI link between the source device (e.g. DVD) and the HDBaseT source and the second in the HDMI link

between the HDBaseT sink and the sink device (e.g. TV). This can cause additional delay that may result with

wrong bit timing (out of the CEC spec), as shown in the following figure


288

Confidential

Pull-Up # 2

Pull-Up # 1

TV

DVD

HDBaseT

Source

HDBaseT

Sink

HDMI Cable

HDMI Cable

CAT5e Cable

0 ms 1.6 ms 1.7 ms 1.8 ms

CEC bit transferred between the DVD and the

HDBaseT Source (DVD is the CEC Initiator)

DVD releases the CEC line after 1.6ms but

the HDBaseT Source see the high level of

CEC line only after the rise time delay (100us

in this example) and transmit it to the

HDBaseT Sink.

HDBaseT Sink releases the CEC line after

1.7ms but the TV see the high level of CEC

line only after the rise time delay (100us in

this example). Bit timing at the TV (1.8ms)

exceed the CEC spec (1.7ms).

1.

2.

3.

Figure 215: CEC bit timing violation example


289

Confidential

To prevent bit timing violation, the following operations must be done by the HDBaseT side which acts as

CEC Initiator: all the falling edges on the CEC line at the Initiator side are delayed 200us before they are

transmitted over the HDBaseT link. The rising edges are transmitted at their nominal timing, relative to the

delayed falling of the CEC line (to prevent short bits to be too short). This means that if the LOW period of the

CEC bit is now shorter than the nominal time(due to the 200us delay of falling edge), it will be stretched back

to the nominal time (delayed). It is guaranteed that the maximal LOW period, after the delayed falling edge is

the nominal LOW time.

TV

DVD

HDBaseT

Source

HDBaseT

Sink

HDMI Cable

HDMI Cable

CAT5e Cable

0 ms 1.6 ms1.7 ms

1.5 ms

1.8 ms

1.6 ms

CEC bit transferred between the DVD and the

HDBaseT Source (DVD is the CEC Initiator)

DVD releases the CEC line after 1.6ms but

the HDBaseT Source see the high level of

CEC line only after the rise time delay (100us

in this example) and transmit it to the

HDBaseT Sink because it is at the nominal bit

timing relative to the delayed falling edge.

HDBaseT Sink releases the CEC line after

1.5ms (related to falling edge) but the TV see

the high level of CEC line only after the rise

time delay (100us in this example). Bit timing

at TV is 1.6ms (within CEC spec.)

1.

2. Falling edge is delayed 200us

before it is transferred to the

other side3.

0 ms

4.

The 100us pull up delay is used in the previous examples only to ease the calculations. According to CEC

specification this number can not exceed 90us.

7.1.2.3 Acknowledge Bit Sequence

During the CEC Acknowledge Bit the direction of the data flow is changed from Initiator Follower to

Follower Initiator. This section describes the sequence of the acknowledge bit.

S0: Initiator Device drives its CEC line to LOW level, starting the acknowledge bit.

S1: HDBaseT at Initiator side sends a CEC LOW level indication on the HDBaseT link at 200us delay


290

Confidential

S3: HDBaseT at Follower side receives the CEC LOW indication from the HDBaseT link. It knows that this is

the acknowledge bit and that it acts as follower. It forces the CEC line to LOW towards the Follower Device

and sends a CEC LOW level indication on the HDBaseT link (up until now it constantly indicated a CEC HIGH

level on the HDBaseT link) to signal a direction change. This indication may be sent no later the 200us after

receiving the CEC LOW indication.

S4: HDBaseT at Initiator side receives a CEC LOW level indication from HDBaseT link. This indication signals

a direction change. It also forces the CEC line towards the Initiator Device to CEC LOW level even if the

Initiator Device tries to drive it to CEC HIGH level.

S5: HDBaseT at Initiator side sends constant CEC HIGH level on HDBaseT link, to complete the direction

change process and the Initiator side.

S6: HDBaseT at Follower side receives a CEC HIGH level indication from HDBaseT link.

S7: HDBaseT at Follower side update the CEC line towards the Follower Device to CEC HIGH level. The

actual value of the CEC line is controlled by the Follower Device itself. If the Follower Device drives the CEC

line to LOW it will be LOW and if it drives it to HIGH it will be HIGH. The current state of the CEC line is sent

on the HDBaseT link towards the Initiator side.

S8: HDBaseT at Initiator side receives the current state of the CEC line at the Follower side, according to the

value of the acknowledge bit (ACK or NACK) and update the CEC line towards the Initiator Device

accordingly.

S9: HDBaseT at Follower side sends CEC HIGH level indication on HDBaseT link. On NACK this has no

special meaning and can be omitted but on ACK, this indication provides for the Initiator to be at the nominal

bit timing. Note that this indication could come before the Follower Device actually drives the CEC line to

HIGH. This is possible because at this time it is well known that this is an ACK bit. On ACK bit, this indication

signal a direction change.

S10: HDBaseT at Initiator side receives CEC HIGH level indication from HDBaseT link and update the CEC

line towards the Initiator Device if needed (this indication may not come on NACK bit).

S11: HDBaseT at Initiator side sends the state of the CEC line on the HDBaseT link.

The following two figures describe the sequence and timing for ACK bit and NACK bit:


291

Confidential

0 ms 2.4 ms0.2 ms

0 ms 0.35 ms 2.4 ms

HDBaseT at Follower side receives CEC LOW level

indication from HDBaseT link, force CEC line of

Follower device to LOW level and sends a constant

CEC LOW level on HDBaseT link (instead of

constant CEC HIGH level).

HDBaseT at Initiator

side sends CEC LOW

level indication on

HDBaseT link

1.5 ms 1.7 ms

HDBaseT at Follower side sends

CEC HIGH level indication on

HDBaseT link. Follower device‟s

CEC line may stay at LOW level

until it releases it.

HDBaseT at Initiator side receives CEC

HIGH level indication from HDBaseT link

and update CEC line of Initiator device. It

may release CEC to HIGH even if not

receiving the CEC HIGH level indication.

Initiator

Side

Follower

Side

Initiator drives

its CEC line to

LOW level

HDBaseT at Initiator side

receives CEC LOW level

indication from HDBaseT link.

HDBaseT at Follower side receives

CEC HIGH level indication from

HDBaseT link. Does not change

CEC line yet.

HDBaseT at Initiator side sends

constant CEC HIGH level

indication on HDBaseT link.

HDBaseT at Initiator side starts to reflect

the CEC line state of the Initiator device

(currently HIGH level) on HDBaseT link

(instead of constant CEC HIGH level).

0.55 ms 1.5 ms

1.3 ms

HDBaseT at Follower side stop forcing CEC line

to LOW and update it to CEC HIGH level. At this

point the follower device is controlling the CEC

line. The current state of CEC line is sent on

HDBaseT link (CEC HIGH level in this case).

HDBaseT at Initiator side keep

receiving CEC LOW level

indication on HDBaseT link

0.6 ms

1.9 ms

Figure 216: CEC ACK sequence over HDBaseT


292

Confidential

0 ms 2.4 ms0.2 ms

0 ms 0.35 ms 2.4 ms

HDBaseT at Follower side receives CEC LOW level

indication from HDBaseT link, force CEC line of

Follower device to LOW level and sends a constant

CEC LOW level on HDBaseT link (instead of

constant CEC HIGH level).

HDBaseT at Initiator

side sends CEC LOW

level indication on

HDBaseT link

0.6 ms 0.8 ms

HDBaseT at Follower side sends

CEC HIGH level indication on

HDBaseT link. This has no effect

in NACK case.

HDBaseT at Initiator side receives CEC

HIGH level indication from HDBaseT link

and update CEC line of Initiator device. It

may release CEC to HIGH even if not

receiving the CEC HIGH level indication.

This has not effect in NACK case.

Initiator

Side

Follower

Side

Initiator drives

its CEC line to

LOW level


receives CEC LOW level

indication from HDBaseT link.

HDBaseT at Follower side receives

CEC HIGH level indication from

HDBaseT link. Does not change

CEC line yet.

HDBaseT at Initiator side sends

constant CEC HIGH level

indication on HDBaseT link.

HDBaseT at Initiator side start to reflect

the CEC line state of the Initiator device

(currently HIGH level) on HDBaseT link

(instead of constant CEC HIGH level).

0.55 ms 1.5 ms

0.4 ms

0.8 ms

HDBaseT at Follower side stop forcing CEC line

to LOW and update it to CEC HIGH level. At this

point the follower device is controlling the CEC

line. The current state of CEC line is sent on

HDBaseT link (CEC HIGH level in this case).


receive CEC HIGH level

indication on HDBaseT link

and udate the CEC line

Figure 217: CEC NACK bit sequence over HDBaseT

7.1.3 HPD / 5V Indication Over HDBaseT Link

HDBaseT Source Shall monitor its respective +5V line and shall inform a change in the +5V line, caused by

its respective HDMI source, by transmitting the new state of the +5V line over the HDBaseT Downstream sub

link. In addition to change notification, For system consistency, +5V state Shall be transmitted at least once

every 5 milliseconds over the HDBaseT Downstream sub link

HDBaseT Sink Shall transmit the current state of its respective HPD line in every Upstream packet.

Upon reception of a HPD/+5V line state notification over the HDBaseT link, the HDBaseT Source / Sink Shall

alter its respective HPD/+5V line state if needed, to match the notified state


293

Confidential

7.1.4 HDMI-AV over HDBaseT Link

HDBaseT transfers all the data and controls associated with an HDMI-AV stream.

HDMI – AV data consists of all the data which, while using regular HDMI physical interface, is transsmited

using the TMDS signals:

HDCP protected Active Pixels Data

HDCP protected Audio and Aux Data

HSYNC and VSYNC signals

CTLxx signals

Guard bands

HDMI AV Controls includs all control signals:

DDC

CEC

HPD

+5V Indication

In addition, the HDBaseT Source measures the frequency relation between the TMDS clock and the

HDBaseT Link Rate and transfers this information to the Sink side where the TMDS clock is regenerated.

7.1.4.1 HDMI-AV Data over HDBaseT Link

HDMI-AV Data is packed into proper packets in a sequential order such that the order of the packets sent over

the link matches the order of the Data within the TMDS stream.


294

Confidential

Figure 218: HDMI-AV (TMDS) Periods

An HDMI-AV (TMDS) stream contains the following data periods:

Active Pixels – each TMDS cycle carries 8 bits per channel to a total of 24 bits on all three channels

Data Island – each TMDS cycle carries 4 bits per channel to a total of 12 bits on all three channels

Control – each TMDS cycle carries 2 bits per channel to a total of 6 bits on all three channels

Active Pixels period

TMDS Clk

1

TMDS Clk

2

TMDS Clk

1

TMDS Clk

1

TMDS Clk

2

TMDS Channel 0

TMDS Channel 1

TMDS Channel 2

TokD16 TokD16 TokD16

48 Data

bits

3 TokD16 Link Tokens

Data Island period

TokD12

12 Data

bits

Control period

TokD12

1 TokD12 Link Token

12 Data

bits

1 TokD12 Link Token

Figure 219: Mapping HDMI-AV (TMDS) Periods to Link Tokens

Every two TMDS cycles of Active Pixels data are packed into 3 TokD16 Link Tokens.


295

Confidential

Each TMDS cycle of a Data Island period is packed into one TokD12 Link Token.

Every two TMDS cycles of Control period are packed into one TokD12 Link Token.

The HDBaseT Downstream Link Layer packs the TMDS data stream into packets according to the TMDS

periods to which the original data corresponds. The following HDBaseT Packet Types are used:

TMDS Active Pixels Data Packets

TMDS Data Island Packets

TMDS Control Data Packets

Guard band periods are considered as part of the TMDS Control period therefore they are packed into

HDBaseT TMDS Control Data Packets.

Each change in the TMDS stream period ends the packing of the current packet and a new packet will start for

the following TMDS period.

For example, when the packet type changes to Active Pixels Data, the Video Leading Guard Band will be the

last element packed into the Last HDBaseT TMDS Control data packet and the first Active Pixel in each line

will be packed first into a new HDBaseT TMDS Active Pixels data packet that follows.

7.1.4.2 TMDS Active Pixels Data TokD16 (PAM16) Packets

TMDS Active Pixels Data is packed into packets with the following Packet Type Token:

b7 b0b6

Packet Type

b4b5

0 0 0 0 1 0 0 0

Figure 220: Active Pixel TokD16 Packet Type Token

Packet Type Code = 8

Token Type = 0 .. which means: use TokD16 to encode data

No extended type

During TMDS Active Pixels period, each TMDS cycle, encodes 24 bits of HDCP protected data (8 bits per

channel). Normally every two TMDS cycles are encoded into three TokD16 Link Tokens:


296

Confidential

TMDS Channel 0

TMDS Channel 1

TMDS Channel 2

TMDS Clk

1 (first)

TMDS Clk

2 (second)

D0D0D7D7

[Chnl1clk1[7:0],Chnl0clk1[7:0]] [Chnl0clk2[7:0],Chnl2clk1[7:0]] [Chnl2clk2[7:0],Chnl1clk2[7:0]]

First TokD16 Second TokD16 Third TokD16

Msb Lsb Msb Lsb Msb Lsb

Figure 221: Encoding Two TMDS Cycles of Active Pixels data into Three TokD16 tokens

Although normally every two TMDS Active Pixels data cycles are encoded using three TokD16 tokens, the

first 4 tokens in a TMDS Active Pixels Data Packet payload, shall be TokD12 tokens. Therefore the first and

the second TMDS cycles encoded in a TMDS Active Pixels Data Packet are encoded as follows:

TMDS Channel 0

TMDS Channel 1

TMDS Channel 2

TMDS Clk

1 (first)

TMDS Clk

2 (second)

D0D0D7D7

[Chnl1clk1[3:0],Chnl0clk1[7:0]] [Chnl2clk1[7:0],Chnl1clk1[7:4]]

First TokD12 Second TokD12 Third TokD12

Msb Lsb Msb Lsb Msb Lsb

Fourth TokD12

[Chnl1clk2[3:0],Chnl0clk2[7:0]] [Chnl2clk2[7:0],Chnl1clk2[7:4]]

Msb Lsb

Figure 222: Encoding Two TMDS Cycles of Active Pixels data into Four TokD12 tokens

The reasons for the TokD12 tokens, usage, are:


297

Confidential

It provides better protection to the first pixel of a video frame (even with 48bpp) which HDCP may

use as part of its Enhanced Link Verification

It provides a more gradual transition into the PAM16 symbols aiding the receiver to decode them

properly

The maximum length of TMDS Active Pixels Data Packet is as follows:

TMDS Channel 0

TMDS Channel 1

TMDS Channel 2

D0D0D7D7

TokD12

Packet

Type

(Active Pixels)

D0D0D7D7 D0D0D7D7 D0D0D7D7

…

00001000 00000000 01100111

Payload

Length

(103)

TokD12 TokD12 TokD12 TokD16 TokD16 TokD16 TokD16 TokD16 TokD16 TokD16 TokD16 TokD16 CRC Idle…

1 2 3 4 5 6 67 68

1 2 3 4 5 6 7 8 9 10 101 102 103

Figure 223: Max length TMDS Active Pixels Data TokD16 Packet Structure

The longest TMDS Active Pixels Data Packet contains 103 payload tokens and encodes 68 TMDS cycles.

The first 4 tokens are TokD12 tokens which encodes two TMDS cycles followed by 99 TokD16 tokens which

encodes 66 TMDS cycles.

An HDBaseT Source device shall construct this max length frame as long as it is possible such that for every

line only the end of the TMDS Active Pixels line may be encoded using a shorter packet. The number of

TMDS cycles encoded in this last packet shall be the reminder of NumberOfTMDSCyclesInLine/68.

For example if the Active Pixels line contains 1920 TMDS cycles (1920=28*68+16), then it will be encoded

using 28 max length packets followed by an additional shorter packet which will encode the remaining 16

TMDS cycles using 25 payload tokens (4 TokD12 + 21 TokD16)

Encoding Active Pixels Data line with odd number of TMDS Cycles - Since usually every two TMDS

cycles are encoded using 3 TokD16 tokens a special treatment is needed in case the Active Pixels Data line

contains an odd number of TMDS cycles. In this case the last TMDS cycle in the line will be encoded using

two TokD16 tokens with 8 zeros padded as the MSBs of the last token data:


298

Confidential

TMDS Channel 0

TMDS Channel 1

TMDS Channel 2

Last

TMDS Clk

D0D7

[Chnl1[7:0],Chnl0[7:0]] [[0,0,0,0,0,0,0,0],Chnl2clk1[7:0]]


Msb Lsb Msb Lsb

Figure 224: Encoding Last TMDS Cycle of odd cycles number Active Pixels line

At the Downstream link decoder the case of an Active Pixels Data packet encoding odd number of TMDS

cycles, can be identified using the payload length field.

Active Pixels Data packets encoding 1,2 and 3 TMDS Cycles – As explained before the first two TMDS

cycles, if exist, are encoded using TokD12 tokens therefore packets encoding 1,2 and 3 TMDS cycles in their

payload will be as follows:

Encoding one TMDS cycle – Payload contains only 2 TokD12 tokens

Encoding two TMDS cycles – Payload contains only 4 TokD12 tokens

Encoding three TMDS cycles – Payload contains 4 TokD12 tokens and the last TMDS cycles is

encoded using the two TokD16 tokens according to the case with odd number of TMDS cycles

encoded in the payload.

7.1.4.3 TMDS Active Pixels Data TokD12 (PAM8) Packets

TokD12 packets are used to transfer less TMDS throughput at a better level of quality using TokD12 tokens

which will translate by the Phy to PAM8 symbols on the HDBaseT link. When ever operation using TokD12

packets can satisfy the TMDS stream the downstream transmitter shall use TokD12 packets unless it was

explicitly required to work in TokD16 only. HDBaseT downstream receiver shall support both TMDS TokD16

and TokD12 packets.

In TokD12 packets the TMDS Active Pixels Data is packed into packets with the following Packet Type Token:

b7 b6

Packet Type

b4b5

0 0 1 0 1 0 0 0

Figure 225: Active Pixel TokD12 Packet Type Token



299

Confidential


No extended type

During TMDS Active Pixels period, each TMDS cycle, encodes 24 bits of HDCP protected data (8 bits per

channel) and is being encoded using two TokD12 Link Tokens:

TMDS Channel 0

TMDS Channel 1

TMDS Channel 2

TMDS Clk

1

D0D7

[Chnl1[3:0],Chnl0[7:0]] [Chnl2[7:0],Chnl1[7:4]]


Msb Lsb Msb Lsb

Figure 226: Encoding one TMDS Cycle of Active Pixels data into Two TokD12 tokens

The maximum length of TMDS Active Pixels Data Packet is as follows:


300

Confidential

TMDS Channel 0

TMDS Channel 1

TMDS Channel 2

D0D0D7D7

TokD12

Packet

Type

(Active Pixels)

D0D0D7D7 D0D0D7D7 D0D0D7D7

…

00101000 00000000 01110100

Payload

Length

(116)

TokD12 TokD12 TokD12 TokD12 TokD12 TokD12 TokD12 TokD12 TokD12 TokD12 TokD12 CRC Idle…

1 2 3 4 5 6 57 58

1 2 3 4 5 6 7 8 9 10 115 116

Figure 227: Max length TMDS Active Pixels Data Packet Structure

The longest TMDS Active Pixels Data TokD12 Packet contains 116 payload tokens and encodes 58 TMDS

cycles..

An HDBaseT Source device shall construct this max length frame as long as it is possible such that for every

line only the end of the TMDS Active Pixels line may be encoded using a shorter packet. The number of

TMDS cycles encoded in this last packet shall be the reminder of NumberOfTMDSCyclesInLine/58.

7.1.4.4 TMDS Data Island Packets

TMDS Data Island data is packed into packets with the following Packet Type Token:

b7 b0b6

Packet Type

b4b5

0 0 1 0 1 0 0 1

Figure 228: Data Island Packet Type Token



No extended type

During TMDS Data Island period, each TMDS cycle, encodes 12 bits of HDCP protected data (4 bits per

channel). Each TMDS cycle is encoded into one TokD12 Link Token:


301

Confidential

TMDS Clk

1

TMDS Channel 0

TMDS Channel 1

TMDS Channel 2

Data Island period

[Chnl2[3:0],Chnl1[3:0],Chnl0[3:0] ]

12 Data

bits

1 TokD12 Link TokenMsb Lsb

Figure 229: Encoding A TMDS Data Island Cycle into One TokD12 token

TMDS Data Island periods are used to carry Audio Data and Aux Data in groups of 32 TMDS cycles. Each

Data Island period contains integer number (1 to 18) of these 32 cycles groups. HDBaseT considers the

Guard band cycles to be part of the control period therefore HDBaseT encodes Data Island period using

packets with payload of 32 or 64 TokD12 tokens.

HDBaseT encoder shall use packets with 64 tokens payload whenever possible (at least two 32 cycles

groups still need to be encoded in the current Data Island period).

HDBaseT encoder shall use a packet with 32 tokens payload when only one 32 cycle group is left to be

encoded in the current Data Island period.

TMDS Channel 0

TMDS Channel 1

TMDS Channel 2

D0D0D7D7

TokD12

Packet

Type

(Data Island)

D0D0D7D7 D0D0D7D7

…

00101001 00000000 01000000

Payload

Length

(64)

TokD12 TokD12 TokD12 CRC Idle…

1 2 3 4 63

1 2 3 4 63 64

TokD12 TokD12

64

Data Island period

Figure 230: Max length TMDS Data Island Packet Structure


302

Confidential

7.1.4.5 TMDS Control Data Packets

HDBaseT considers TMDS guard bands to be part of the Control period, therefore a Control period may start

and/or may end with guard band symbols. HDBaseT uses four types of TMDS Control Data packets:

CC – Packet payload encoding a Control period which does not contains guard bands.

CG – Packet payload encoding a Control period which ends with a guard band.

GC – Packet payload encoding a Control period which starts with a guard band.

GCG – Packet payload encoding a Control period which starts and ends with a guard band.

During TMDS Control period, each TMDS cycle encodes 6 bits of data (2 bits per channel). Every two TMDS

cycles are encoded into one TokD12 Link Token:

TMDS Clk

1

TMDS Clk

2

TMDS Channel 0

TMDS Channel 1

TMDS Channel 2

[Chnl2Clk2[1:0],Chnl1Clk2[1:0],Chnl0Clk2[1:0] ,Chnl2Clk1[1:0],Chnl1Clk1[1:0],Chnl0Clk1[1:0] ]

Control period

1 TokD12 Link Token

12 Data

bits

Msb Lsb

Figure 231: Encoding Two TMDS Control Cycles into One TokD12 token

The longest payload of a TMDS Control Data Packet contains 38 payload tokens and encodes 76 TMDS

cycles.

An HDBaseT Source device shall construct this max payload length packet as long as it is possible such that

for every TMDS Control period only the end of the TMDS Control period may be encoded using a shorter

packet. The number of TMDS cycles encoded in this last packet shall be the reminder of

NumberOfTMDSCyclesInControlPeriod/76.

For example if the TMDS Control period contains (including guard bands) 170 TMDS cycles (170=2*76+18),

then it will be encoded using 2 max length packets followed by an additional shorter packet which encodes the

remaining 18 TMDS cycles using 9 payload tokens (18/2 TokD12)


303

Confidential

TMDS Channel 0

TMDS Channel 1

TMDS Channel 2

D0D0D7D7

TokD12

Packet

Type

(Control (CC))

D0D0D7D7 D0D0D7D7

…

00100100 00000000 00100110

Payload

Length

(38)

TokD12 CRC Idle…

1 2 3 4 75

1 2 38

TokD12

76

Control period

Figure 232: Max Payload length TMDS Control Data Packet (CC) Structure

HDMI-TMDS has 3 types of Guard bands:

Video Active Pixels Leading guard band period – two TMDS cycles of a pre defined TMDS word for

each of the three TMDS channels.

Data Island Leading guard band period – two TMDS cycles of a pre defined TMDS word for each

channel 1 and 2, channel 0 continues to carry Hsync and Vsync signals.

Data Island Trailing guard band period - two TMDS cycles of a pre defined TMDS word for each

channel 1 and 2, channel 0 continues to carry Hsync and Vsync signals.

HDBaseT encodes the two cycles of guard band using one TokD12 token:

TMDS Clk

1

TMDS Clk

2

TMDS Channel 0

TMDS Channel 1

TMDS Channel 2

[01,01,Chnl0Clk2[1:0] ,01,01,Chnl0Clk1[1:0] ]

Data Island

Leading and Trailing

Guard Band


TMDS Clk

1

TMDS Clk

2

[ 000000000000 ]

Video Active Pixels

Leading

Guard Band


12 Zeros2x2bits of chnl0 data, chnl1

and chnl2 are fixed to 01

Figure 233: Guard Band Encoding

A TokD12 token which encodes a Data Island trailing guard band shall be the first token in the packet payload

(GC or GCG packets).


304

Confidential

A TokD12 token which encodes Video Active Pixels leading guard band or Data Island leading guard band

shall be the last token in the packet payload (CG or GCG packets).

Upon reception of a CG or GCG packet with payload length of one token, the first TokD12 token shall be

interpreted as encoding a (Video Active Pixels or Data Island) leading guard band

Encoding Control period with odd number of TMDS Cycles - Since usually every two TMDS cycles are

encoded using 1 TokD12 token a special treatment is needed in case the Control period contains an odd

number of TMDS cycles. In this case the last TMDS cycle, before the guard band, if exists, shall be encoded

using 1 TokD16 tokens with 6 zeros padded as the MSBs of the token data:

Last TMDS Clk Before

Guard band (if exists)

TMDS Channel 0

TMDS Channel 1

TMDS Channel 2

[000000 ,Chnl2[1:0],Chnl1[1:0],Chnl0[1:0] ]

Control period


Figure 234: Encoding Last TMDS Cycle before GB of odd cycles number Control period

A packet (CC, CG , GC, GCG) encoding an odd number of TMDS cycles of TMDS Control period, shall use

an Extended Packet Type token with token data = 1.

For example, the following figure describes a CG packet encoding 15 TMDS cycles (including the Video

Leading GB) of a Control period, using a payload containing 8 TokD12 tokens:

TMDS Clk

11

TMDS Clk

12

TokD12

12 Data

bits

TokD12

TMDS Clk

13

6 Data bits

Padded with 6

zeros

TMDS Clk

1

TMDS Clk

2

TokD12

12 Data

bits

…

TMDS Clk

14

TMDS Clk

15

TokD12

12 zeros

Control Period Video Guard Band

1 6 7 8

000010000000000000000001 CRC Idle10100101

Packet

Type

(Control (CG))

With Extended

Type

Extended

Type:

Odd TMDS

Cycles Number

Payload

Length

(8)

Figure 235: An Extended Type CG Packet encoding an odd number (15) of TMDS Cycles


305

Confidential

A packet (CC, CG, GC, GCG) encoding an even number of TMDS cycles, of TMDS Control period, shall not

use an Extended Packet Type token.

7.1.4.6 TMDS Clock over HDBaseT Link

In order to enable the regeneration of the TMDS clock at the Sink side (TMDS_CLK_OUT), the HDBaseT

Source Link Layer measures the ratio between the incoming TMDS clock (TMDS_CLK_IN) and the HDBaseT

Link rate (LINK_RATE: 250M or 500M depending on the mode of operation).

For every LINK_COUNT_PERIOD Link Periods the Source HDBaseT Link Layer counts the number of

incoming TMDS clock cycles (TMDS_IN_COUNT) passed during that period. Therefore:

RATELINK

PERIODCOUNTLINK

INCLKTMDS

COUNTINTMDS

_

__

__

__

The count result TMDS_IN_COUNT is sent to the Sink side where the LINK_COUNT_PERIOD is known.

Since the Sink must recover the exact LINK_RATE as defined by the Source in order to be able to receive the

Downstream symbols, it is therefore possible to to regenerate the output TMDS clock (TMDS_CLK_OUT) in

the Sink by calculating the ratio:

INCLKTMDSPERIODCOUNTLINK

RATELINKCOUNTINTMDSOUTCLKTMDS __

__

_*____

LINK_COUNT_PERIOD is defined to be 1024, meaning that for every 1024 Link Periods (1024 Link Tokens,

1024/250M or 1024/500M) the Source counts the number of TMDS clock cycles in that period. Since the

TMDS clock is asynchronous to the Link Rate, this count may vary from one count period to another..

The Source shall ensure that ALL TMDS clock cycles are counted in ONE and ONLY ONE count period.

The HDBaseT Sink Link Layer shall include means to regenerate clock frequencies in the range that is

specified in HDMI 1.3 specifications such as a Frequency Synthesizer module.

The regenerated output TMDS clock, shall comply with the HDMI 1.3 specifications.

7.1.4.7 TMDS Clock Info Control Packet

TokPtp


TokD8 TokD8

Clk Cnt

HighCRC-8 Idle

TokD8 TokCrc TokIdlTokD8

Clk Cnt

Low

Header Clock Count Payload Tail


306

Confidential

Figure 236: TMDS Clock Info Control Packet

For every LINK_COUNT_PERIOD the HDBaseT Source shall send to the Sink side the 16 bit count result,

TMDS_IN_COUNT value, using the following packet format:

Figure 237: TMDS Clock Info Packet arrangenment

7.1.4.8 HDMI-AV Controls Packet

Header

TokPtp


TokD8 TokD8

Ctrl-1 CRC-8 Idle

Control Payload

TokD8 TokCrc TokIdl

Tail

TokD8

Ctrl-2

Figure 238: HDMI-AV Control Packet

The control payload is built from two tokens of type TokD8 that contains 8-bit of data each:

DDC InfoDDC

Valid5VCEC InfoReserved

Ctrl-1 Ctrl-2MSB MSB

Figure 239: HDMI-AV Control Token Assignment

The DDC content is described below:

TokD8

Packet

Type

(Periodic Stream)

01000010 00000000 00000010

Payload

Length

(2)

TokD8 CRC Idle

1 2

TMDS_IN_COUNT

Msb Lsb

8 bits 8 bits


307

Confidential

Table 54: Downstream – DDC over HDBaseT

DDC

Field

Value

Description

0 No DDC data

1 DDC data bit is zero (0) or Master Acknowledge

2 DDC data bit is one (1) or Master Not-Acknowledge

3 Stop Condition

4 Start Condition

5-7 Reserved

The CEC content is described below:

Table 55: Downstream – CEC over HDBaseT

CEC

Field

Value

Description

0 No CEC data

1 CEC line is LOW

2 CEC line is HIGH

3 Reserved

The 5V content is described below:

Table 56: Downstream – 5V over HDBaseT

5V

Field

Value

Description

0 5V line is zero (0)

1 5V line one (1)


308

Confidential

8 USB over HDBaseT

9 Power over HDBaseT (PoH)

10 Other Interfaces Over HDBaseT

10.1 General 10.2 Requirements 10.3 IR over HDBaseT

10.3.1 General

IR Remote Controls use a modulated signal to drive an Infra-red transmitter. The modulation is done

according to a variety of protocols (“Consumer IR (CIR)” protocols). Each command is encoded in a series of

pulses which are modulated at a carrier frequency, typically somewhere between 33 to 40 kHz or 50 to 60

kHz. The duty cycle is typically 25% to 50%.

In an IR over HDBaseT session the IR TX T-adaptor translates the IR signal to HDBaseT IR T-stream to be

carried over the HDBaseT link, and an IR RX T-adaptor translates the HDBaseT IR T-stream back to an IR

signal.

IR HDBase-T Packets are of Type 12, as are UART HDBase-T Packets. They are distinguished from UART

packets by the fact that their payload is always three token long.

10.3.2 HDBaseT IR Messages

The IR signal is translated into a sequence of carrier-modulated pulses (bursts) and silence periods (inter-

bursts). Each burst or inter-burst period is translated into a single 24-bit message. The two LSBs describe the

type of signal according to Table 57.

Table 57: IR Message Type

Value Type

0 Burst

1 Inter-Burst

2-3 Reserved

For the burst message (type=0), the 12 MSBs describe the period of the carrier in a resolution of 120nsec,

and the next 10 bits describe the number of cycles in the burst. The duty cycle is not stated and can be

assumed to be 25% to 50%.


309

Confidential

For the inter-burst message (type=1), the 22 MSBs describe the inter-burst (silence) period in a resolution of

120nsec. There is no need to describe inter-burst periods of MAX_IR_INTERBURST [120nsec] (216

=

7.86msec) or more.

It is possible to send “partial” messages, indicating the start of a burst or inter-burst with a yet unknown

duration. For a burst message this is done by setting the Cycles field to zero (the period should still be stated).

In this case the following IR message shall be a “full” burst message indicating both the Cycles and Period of

the burst. A “partial” inter-burst message is sent by setting the Time_Off field to zero (the 24-bit IR message is

0x000001). The next message shall be a “full” inter-burst message indicating the actual inter-burst length,

except when the inter-burst length is longer than MAX_IR_INTERBURST.

Period (12 bit) Cycles (10 bit) 00

Time Off (22 bit) 01

Burst

Inter-Burst

Type

(2 bit)

LSBMSB

Figure 240: HDBaseT IR Message Format

The maximum latency introduced by the IR TX T-adaptor shall not exceed 1msec. The maximum latency

introduced by the IR RX T-adaptor shall not exceed 128nsec.

Table 58: IR Source and Sink T-adaptor Attributes

Attribute Value Remarks

Type 12 Payload length is always 3 tokens

Priority 3 Payload is always PAM4 on DS, PAM8 on US

Quality 3

Use Retransmission No

Use NibbleStream No

Multi T-Stream Supporting TX – Duplicate IR T-stream per session

RX – Service all incoming T-streams

Path Type Mixed Path

Bad CRC handling No

Use clock service No

Session Initiation Association /

CPME

Cannot self initiate session


310

Confidential

10.3.3 T-Adaptor Info Format

The Spec 2.0 IR T-adaptor Info shall consist of the Info Length (4) Byte, T-A Type 2-Byte Code (0x1000 for IR

TX, 0x2000 for IR RX), The IR Version Byte (0x02), the Minimal Modulation Frequency Byte and the Maximal

Modulation Frequency Byte.

Max Mod Freq:Min Mod Freq:UART Version:

0x02

T-A Type Code:

0x1000/0x2000

Info Length:

5

1 Byte 2 Bytes 1 Byte 1 Byte 1 Byte

Figure 241: IR T-Adaptor Info Format

The Minimal and Maximal Modulation Frequencies shall be stated in kHz units.

10.3.4 IR Downstream Packets

A basic IR downstream packet consists of a Packet Type Token (Ext. 0, Token Type 2, Packet Type 12), a

Session ID (SID) token, a Payload Length Token with a value of 3, followed by three 8-bit-token payload, and

ending with a CRC token and an IDLE token. The payload tokens carry the 24-bit IR message described

above, first the 8 LSBs (bits 0 to 7), then bits 8-16 and finally the 8 MSBs (bits 16-23).

Ext.

0

Token Type

2

Packet Type Code

12

Packet Type SID Token

SID

Payload Length

3

Payload Token #1

IR Message [b7:b0]

b1b2b3b4 b0b5b6b7 b4b5b6b7 b0b1b2b3 b4b5b6b7 b0b1b2b3 b4b5b6b7 b0b1b2b3

Payload Token #2

IR Message [b15:b8]

b4b5b6b7 b0b1b2b3

Payload Token #3

IR Message [b23:b16]

b4b5b6b7 b0b1b2b3

Figure 242: Basic IR Downstream packet (CRC and IDLE tokens not shown)

An Extended Control Info token is placed after the Packet Type token to indicate Bad CRC if the packet„s

payload is a part of a packet received somewhere along the network with a Bad CRC.

Ext.

1

Token Type

2

Packet Type Code

12


SID

Payload Length

3

Payload Token #1

IR Message [b7:b0]

b1b2b3b4 b0b5b6b7 b4b5b6b7 b0b1b2b3 b4b5b6b7 b0b1b2b3

b4b5b6b7 b0b1b2b3

Payload Token #2

IR Message [b15:b8]

b4b5b6b7 b0b1b2b3

Payload Token #3


b4b5b6b7 b0b1b2b3

b7

Ext.

0

b6

Extended

Info

0 0b1b2b3b4b5

Bad

CRC

1

Sync

End

0

Extended Control Info Token

b0

Nibbles

Pad Num

0 0

Sync

Start

0

Figure 243: Extended IR Downstream packet (CRC and IDLE tokens not shown)

10.3.5 IR Upstream Sub-packets

A basic IR Upstream sub-packet shall consist of a Sub-packet Header Token (Ext. 0, Type 12, and Length 2),

and a Session ID (SID) token, followed by three 8-bit-token payload. The payload tokens carry the 24-bit IR

message described above, first the 8 LSBs (bits 0 to 7), then bits 8-16 and finally the 8 MSBs (bits 16-23).

LengthType

b0b1b2b3b4b5b6b7

Ext.

0 1 1 0 0

Subpacket Header Token SID Token

SID

b4b5b6b7 b0b1b2b3

0 1 0

Payload Token #1

IR Message [b7:b0]

b4b5b6b7 b0b1b2b3

Payload Token #2

IR Message [b15:b8]

b4b5b6b7 b0b1b2b3

Payload Token #3


b4b5b6b7 b0b1b2b3

Figure 244: Basic IR Upstream Subpacket

An Extended Control Info token is placed after the Subpacket Header Token to indicate Bad CRC if the

packet„s payload is a part of a packet received somewhere along the network with a Bad CRC.


311

Confidential

LengthType

b0b1b2b3b4b5b6b7

Ext.

1 1 1 0 0


SID

b4b5b6b7 b0b1b2b3

0 1 0


Payload Token #1

IR Message [b7:b0]

b4b5b6b7 b0b1b2b3

Payload Token #2

IR Message [b15:b8]

b4b5b6b7 b0b1b2b3

Payload Token #3


b4b5b6b7 b0b1b2b3

b7

Ext.

0

b6

Extended

Info

0 0b1b2b3b4b5

Bad

CRC

1

Sync

End

0b0

Nibbles

Pad Num

0 0

Sync

Start

0

Figure 245: Extended IR Upstream Subpacket

10.4 UART over HDBaseT

10.4.1 General

UARTs transmit words of 5-8 data bits (LSB first), preceded by a “start” bit and followed by an optional “parity”

bit and then one, one and a half, or two “stop” bits. Transmitting and receiving UARTs must be set for the

same bit speed, character length, parity, and stop bits for proper operation. The receiving UART may detect

some mismatched settings and set a “framing error” flag bit for the host system.

Each UART port may be used for both receiving and transmitting (“Full Duplex” or “Half Duplex”). UART T-

adaptors likewise serve for both sending and receiving UART messages over the HDBaseT network. The

UART T-adaptor TX passes information from the UART receiver to the HDBaseT Link, and the UART T-

adaptor RX passes information from the HDBaseT Link to the UART transmitter.

In A UART over HDBaseT session only the data bits are transmitted. The HDBaseT Network shall allow

forming a session between two UART T-adaptors only if their character lengths (number of data-bits) are the

same. Bit speed, parity and stop bit durations may be different, causing different peak data rates at the two T

adaptors. Short-Term rate differences may be alleviated by using buffers at the UART Transmitters. Long-

Term rate differences may result in Overrun Error conditions in the slower T-adaptor.

The UART T-adaptor shall support data-rates of up to 1Mbps.

UART HDBase-T Packets are of Type 12, as are IR HDBase-T Packets. They are distinguished from CIR

packets by the fact that their payload length (the UART data-bits) is always a single token.

10.4.2 Error Handling

The UART T-adaptor TX shall propagate Parity Error conditions by use of an Extended Control Info Token

with Extended Info value 1. The UART-T adaptor TX shall propagate other error conditions (e.g. Overrun

Error, Framing Error) by use of an Extended Control Info Token with Extended Info value 2. If both error

conditions occur, the UART T-adaptor TX shall use an Extended Control Info Token with Extended Info value

3.

If The UART T-adaptor RX receives an Extended Info value of 1 or 3 or a BAD CRC indication and the UART

transmitter uses parity, it shall force the transmitter to send an inverted parity bit. If there is no use of a parity

bit it shall force the UART transmitter to produce a Framing Error (by inverting the Stop Bit). If the UART T-

adaptor RX receives an Extended Info value of 2 or 3 it shall force the UART transmitter to produce a

Framing Error.


312

Confidential

Table 59: UART T-adaptor Attributes


Type 12 Payload length is always 1 token

Priority 3 Payload is always PAM4 on DS, PAM8 on US

Quality 3

Use Retransmission No

Use NibbleStream No

Multi T-Stream No


Bad CRC handling Yes Parity Error or Framing Error – See above

Use clock service No


CPME



The Spec 2.0 UART T-adaptor Info consists of the Info Length (5) Byte, T-A Type 2-Byte Code (0x4000), The

UART Version Byte (0x02), the UART Baud Rate Byte and the UART Configuration Byte.

UART Configuration:UART Baud Rate:UART Version:

0x02

T-A Type Code:

0x4000

Info Length:

5

1 Byte 2 Bytes 1 Byte 1 Byte 1 Byte

Char LenParityStop BitReserved

b0b1b2b3b4b5b6b7

Figure 246: UART T-Adaptor Info Format

The UART Baud Rate Byte value shall be set according to Table 60, if the UART baud-rate is not listed the

value closest to it shall be chosen.


313

Confidential

Table 60: UART Baud Rate Fixed Predetermined Values

Value BaudRate

[bps]

Value BaudRate

[bps]

Value BaudRate

[bps]

Value BaudRate

[bps]

0x00 Unknown 0x10 75 0x20 125000 0x30 2048000

0x01-0x0F Reserved 0x11 110 0x21 128000 0x31-0xFF Reserved

0x12 134 0x22 230400

0x13 150 0x23 250000

0x14 300 0x24 256000

0x15 600 0x25 460800

0x16 1200 0x26 500000

0x17 1800 0x27 512000

0x18 2400 0x28 921600

0x19 4800 0x29 1000000

0x1A 7200 0x2A 1024000

0x1B 9600 0x2B 1382400

0x1C 19200 0x2C 1500000

0x1D 38400 0x2D 1536000

0x1E 57600 0x2E 1843200

0x1F 115200 0x2F 2000000

The UART configuration Byte consists of the Character Length, Parity and Stop bit fields which shall be set

according to Table 61.


314

Confidential

Table 61: UART T-adaptor Info UART Configuration byte format

Bits Field Name Values

b1:b0 Character Length 0 = 5 bits

1 = 6 bits

2 = 7 bits

3 = 8 bits

b2 Parity 0 = No Parity Bit

1 = Parity Bit

b4:b3 Stop Bit 0 = 1 Stop bit

1 = 1.5 Stop bit

2 = 2 Stop bits

b7:b5 Reserved N/A

10.4.4 UART Downstream Packets

A basic UART downstream packet consists of a Packet Type Token (Ext. 0, Token Type 2, Packet Type 12), a

Session ID (SID) token, a Payload Length Token with a value of 1, followed by a single 8-bit-token payload,

and ending with a CRC token and an IDLE token. The UART data (which is 5-8 bits long) is aligned to the LSB

of the payload token.

Ext.

0

Token Type

2

Packet Type Code

12

b1b2b3b4 b0b5b6b7


SID

b4b5b6b7 b0b1b2b3

Payload Length

1

b4b5b6b7 b0b1b2b3

UART Token

UART data

b4b5b6b7 b0b1b2b3

Figure 247: Basic UART Downstream packet (CRC and IDLE tokens not shown)

An Extended Control Info token is placed after the Packet Type token to propagate Parity Error or other error

conditions as stated above. The same token is used to indicate Bad CRC if the packet„s payload is a part of a

packet received somewhere along the network with a Bad CRC.

Ext.

1

Token Type

2

Packet Type Code

12

b1b2b3b4 b0b5b6b7


SID

b4b5b6b7 b0b1b2b3

Payload Length

1

b4b5b6b7 b0b1b2b3

UART Token

UART data

b4b5b6b7 b0b1b2b3


b7

Ext.

0

b6

Extended

Info

b1b2b3b4b5

Bad

CRC

1

Sync

End

0b0

Nibbles

Pad Num

0 0

Sync

Start

0

Figure 248: Extended UART Downstream packet (CRC and IDLE tokens not shown)

10.4.5 UART Upstream Sub-packets

A basic UART Upstream sub-packet consists of a Sub-packet Header Token (Ext. 0, Type 12, and Length 0),

and a Session ID (SID) token, followed by a single 8-bit-token payload. The UART data (which is 5-8 bits long)

is aligned to the LSB of the payload token.


315

Confidential

LengthType

b0b1b2b3b4b5b6b7

Ext.

0 1 1 0 0


SID

b4b5b6b7 b0b1b2b3

0 0 0

UART Token

UART data

b4b5b6b7 b0b1b2b3

Figure 249: Basic UART Upstream Subpacket

An Extended Control Info token is placed after the Sub-packet Header Token to propagate Parity Error or

other error conditions as stated above. The same token is used to indicate Bad CRC if the packet„s payload is

a part of a packet received somewhere along the network with a Bad CRC.

LengthType

b0b1b2b3b4b5b6b7

Ext.

1 1 1 0 0


SID

b4b5b6b7 b0b1b2b3

0 0 0

UART Token

UART data

b4b5b6b7 b0b1b2b3


b7

Ext.

0

b6

Extended

Info

b1b2b3b4b5

Bad

CRC

1

Sync

End

0b0

Nibbles

Pad Num

0 0

Sync

Start

0

Figure 250: Extended UART Upstream Subpacket

10.5 SPDIF over HDBaseT

10.5.1 General

The S/PDIF interface is detailed in the IEC-60958 standard. It is a serial, uni-directional, self-clocking

interface. The S/PDIF stream is divided into blocks, each consisting of 192 frames or 384 subframes.

Each subframe has a preamble, 24 audio bits (4 aux bits + 20 Audio sample Word), a validity bit (V), user data

bit (U), channel status bit (C), and a parity bit (P).

Figure 251: S/PDIF Subframe Format

S/PDIF subframes were originally intended to carry a single linear PCM encoded audio sample (up to 24 bits).

Non-linear PCM encoded audio bitstreams may also be transported over IEC60958 subframes, as described

in IEC61937, using only the 16 MSBs of the Audio sample word.

S/PDIF HDBase-T Packets are of Type 11. The S/PDIF data is carried over the HDBaseT link as a Nibble

Stream. The S/PDIF Nibble Stream mark the S/PDIF block beginnings as Sync Start points, it does not use

Sync End.

The S/PDIF T-Adaptor shall support frame rates up to 192 KHz. The S/PDIF T-Adaptor may optionally

support higher frame rates.


316

Confidential

10.5.2 S/PDIF Nibble Stream

Each full S/PDIF frame is translated into 15 or 11 nibbles as shown in Figure 252. The 11 nibble (short) format

can be used only when the 8 LSBs of the 24-bit Audio word of both subframes are zeros (as is the case in

IEC61937 streams).

Preamble

b0b1b2b3

Nibble #1

Sh

0

Nibble #8

Audio1[3:0]

b0b1b2b3

Nibble #2

Audio1[7:4]

b0b1b2b3

Nibble #3

Audio1[23:20]

b0b1b2b3

Nibble #7 Nibble #15

Audio2[3:0]

b0b1b2b3

Nibble #9

Audio2[7:4]

b0b1b2b3

Nibble #10

Audio2[23:20]

b0b1b2b3

Nibble #14

Preamble

b0b1b2b3

Nibble #1

Sh

1

Nibble #6

Audio1[11:8]

b0b1b2b3

Nibble #2

Audio1[15:12]

b0b1b2b3

Nibble #3

Audio1[23:20]

b0b1b2b3

Nibble #5 Nibble #11

Audio2[11:8]

b0b1b2b3

Nibble #7

Audio2[15:12]

b0b1b2b3

Nibble #8

Audio2[23:20]

b0b1b2b3

Nibble #10

b0

V1

b1

U1

b2

C1

b3

P1

b0

V2

b1

U2

b2

C2

b3

P2

b0

V1

b1

U1

b2

C1

b3

P1

b0

V2

b1

U2

b2

C2

b3

P2

Figure 252: HDBaseT S/PDIF NibbleStream

The Preamble is TBD and can be used to carry the preamble information of the packet (BW = 0, MW = 1) plus

additional information.

The Sh bit is asserted for short frames, where only the 16 MSB audio bits of both subframes are sent and the

8 LSBs which are zeros are not sent.

Audio1[23:0] is the 24-bit Audio-word of the first subframe, and Audio2[23:0] is the Audio-word of the second

subframe.

The V1, U1, C1 and P1 bits carry the validity, user data, channel status and parity bits of the first subframe

and V2, U2, C2 and P2 carry the corresponding bits of the second subframe.

A Nibble Stream Sync Start point is marked at the beginning of each S/PDIF block (preamble B),

The S/PDIF TX T-Adaptor shall also measure each S/PDIF block duration with accuracy better than +/-4ns,

and send the measurement over the HDBaseT Link using the T-Network clock service. The clock word is 24-

bit long and carries the block duration in nanoseconds.

10.5.3 Error Handling

If The SPDIF RX T-adaptor receives S/PDIF data with BAD CRC, it shall force the S/PDIF transmitter to

transmit an inverted parity bit in the relevant subframe(s), causing a parity error.


317

Confidential

Table 62: SPDIF T-adaptor Attributes


Type 11

Priority 2

Quality 2

Use Retransmission Yes

Use NibbleStream Yes

Multi T-Stream No


Bad CRC handling Yes Parity Error – See above

Use clock service Yes Using Network Clock Service – See Below


CPME



The Spec 2.0 SPDIF T-adaptor Info consists of the Info Length (4) Byte, T-A Type 2-Byte Code (0x0100 for

SPDIF Source, 0x0200 for SPDIF Sink), The SPDIF Version Byte (0x02), and the Maximal FrameRate Byte.

Max Frame Rate:SPDIF Version:

0x02

T-A Type Code:

0x0100/0x0200

Info Length:

4

1 Byte 2 Bytes 1 Byte 1 Byte

Figure 253: IR T-Adaptor Info Format

The Maximal Frame Rate Byte shall be set according to Table 63 which is consistent with IEC60958-3-amd1

(bits 24,25,26,27,30,31 of Mode 0 channel status with bit-order inverted).


318

Confidential

Table 63: SPDIF Maxmimal Frame Rate Byte Values

Value Max Frame Rate [kHz] Value Max Frame Rate [kHz]

0x08 22.05 0x28 384

0x00 44.1 0x2A 1536

0x04 88.2 0x2B 1024

0x0C 176.4 0x2C 352.8

0x18 24 0x2D 705.6

0x10 48 0x2E 1411.2

0x14 96 0x34 64

0x1C 192 0x35 128

0x30 32 0x36 256

0x20 Not Indicated 0x37 512

0x24 768 Other Reserved

10.5.5 SPDIF Downstream Packets

An SPDIF Downstream packet consists of a Packet Type Token (Packet Type 11), an optional Control Info

Token, a Session ID (SID) token, a Payload Length Token, followed by payload tokens, and ending with a

CRC token and an IDLE token. The S/PDIF nibbles are ordered from the low nibble of the first payload token

up to the high nibble of the last payload token, if there aren‟t enough nibbles to fill the last payload token its

MSBs are zero padded, and the Control Info Token Zero_Pad_Num field is used.

Figure 254 shows an example of an S/PDIF Downstream packet with a Nibble Stream Sync point, carrying 11

nibbles using 12-bit payload tokens.

Nibble #3 Nibble #2

Ext.

1

Token Type

1

Packet Type Code

11


SID

Payload Length

4


Payload Token #1

Nibble #1

b4b5b6b7 b0b1b2b3b8b9b10b11

Nibble #6 Nibble #5

Payload Token #2

Nibble #4


0 Nibble #11

Payload Token #4

Nibble #10



b7

Ext.

0

b6

Extended

Info

0 0b1b2b3b4b5

Bad

CRC

Sync

End

0b0

Nibbles

Pad Num

0 1

Sync

Start

Figure 254: SPDIF Downstream packet (CRC and IDLE tokens not shown)

The Control Info token is also used to indicate Bad CRC if the packet„s payload is a part of a packet received

somewhere along the network with a Bad CRC. If all values in the Control Info Token are zero it can be

omitted. If only Bad CRC is indicated an Extended Info Token may be used instead of the Control Info Token.

The clock information (block length measurement) is carried by a Clock Downstream Packet, consisting of a

Packet Type token (Ext. 1, Token Type 2, Packet Type 1), an Extended Info Token with Extended Info 2, a

SID token, a Payload Length token (3), and 3 8-bit payload tokens. Figure 255 shows an example of a S/PDIF

clock message with a block length of 1ms (frame rate of 192 kHz).


319

Confidential

Ext.

1

Token Type

2

Packet Type Code

1


SID

Payload Length

3

Payload Token #1

0 1 0 0 0 0 0 0


b4b5b6b7 b0b1b2b3

Payload Token #2

0 1 0 0 0 0 1 0

b4b5b6b7 b0b1b2b3

Payload Token #3

0 0 0 0 1 1 1 1

b4b5b6b7 b0b1b2b3


b7

Ext.

0

b6

Extended

Info

1 0b1b2b3b4b5

Bad

CRC

Sync

End

0b0

Nibbles

Pad Num

0 0

Sync

Start

0

Figure 255: SPDIF Clock Downstream packet (CRC and IDLE tokens not shown)

10.5.6 SPDIF Upstream Sub-packets

An SPDIF Upstream packet consists of a Sub-packet Header of 1 or 2 tokens depending on the payload

length, an optional Extended Control Info Token, and a Session ID (SID) token, followed by 12-bit payload

tokens. The S/PDIF nibbles are ordered from the low nibble of the first payload token up to the high nibble of

the last payload token, if there aren‟t enough nibbles to fill the last payload token its MSBs are zero padded,

and the Control Info Token Zero_Pad_Num field is used.

Figure 256 shows an example of an S/PDIF Upstream packet with a NibbleStream Sync point, carrying 26

nibbles.

Length

0 0 0

Datatype

b0b1b2b3b4b5b6b7

Ext.

1 1 0 1 1


SID

b4b5b6b7 b0b1b2b3

Ext_Length

0 0 1

Datatype

b0b1b2b3b4b5b6b7

Ext.

1 1 1 1 1

Extended Length Token

Nibble #3 Nibble #2

Payload Token #1

Nibble #1


Nibble #6 Nibble #5

Payload Token #2

Nibble #4


0 Nibble #26

Payload Token #9

Nibble #25



b7

Ext.

0

b6

Extended

Info

0 0b1b2b3b4b5

Bad

CRC

Sync

End

0b0

Nibbles

Pad Num

0 1

Sync

Start

1

Figure 256: SPDIF Upstream Sub-packet

The Extended Control Info token is also used to indicate Bad CRC if the packet„s payload is a part of a packet

received somewhere along the network with a Bad CRC.

The clock information (block length measurement) is carried by a Clock Downstream Packet, consisting of a

Packet Type token, an Extended Control Info Token with Extended Info 2, a SID token, and 3 8-bit payload

tokens. Figure 257 shows an example of a S/PDIF clock message with a block length of 1ms (frame rate of

192 kHz).

Length

0 1 0

Datatype

b0b1b2b3b4b5b6b7

Ext.

1 0 0 0 1

Subpacket Header Token Payload Token #1

0 1 0 0 0 0 0 0

b4b5b6b7 b0b1b2b3

Payload Token #2

0 1 0 0 0 0 1 0

b4b5b6b7 b0b1b2b3

Payload Token #3

0 0 0 0 1 1 1 1

b4b5b6b7 b0b1b2b3


b7

Ext.

0

b6

Extended

Info

1 0b1b2b3b4b5

Bad

CRC

Sync

End

0b0

Nibbles

Pad Num

0 0

Sync

Start

0

SID Token

SID

b4b5b6b7 b0b1b2b3

Figure 257: SPDIF Clock Upstream Sub-packet


320

Confidential

Appendix A – Use Cases

Revision History

Revision Date Author Description

0.8 July 20, 2009 Eyran Lida First version

0.9 Nov 10, 2009 Eyran Lida Modifications: Detailed CEC description,

Improve Ethernet description, Active Startup,

Electrical specifications, Network Objectives

Additions: Control and Management section,

PAM8 Video packets, HLIC Support on DS

US and HDSBI interfaces with comments

resolution

1.0 March 3, 2010 Eyran Lida Few added cross references for clarity

Version Number

1.4D October 20, 2010 Eyran Lida Base Draft for spec 2.0 – Add the

Terminology, downstream and upstream link

layer for Spec 2.0, networking part with

integration of LGE contribution, IR, UART,

S/PDIF support over HDBaseT, Terminology

and Draft Skeleton. Modified objectives,

move HDMI related definitions from Link

Layer to HDMI over HDBaseT section.


321

Confidential

1.45D November 12,

2010

Eyran Lida Various (untracked) editorial language

clarification changes.

The following changes are also marked in red

underlined text:

Ethernet – moved Ethernet related section to

new section ‎6. Ethernet over HDBaseT,

added sparse Ethernet packet format in ‎6.2,

‎6.3.

Extended Tokens – Modified format in

‎2.2.3.11, ‎2.4.3.

Nibble Stream – Added Sync End in ‎2.1.1.4

NPA – changed format, defined DS PSU, US

PSU in ‎5.2.4.2. Define NPA update in

‎5.2.5.1, modified PSU limits in ‎5.4.1.2.

Device & Topology Discovery – Started

adding device connectivity, link status and

CP registration messages in ‎5.3.8, ‎5.3.9,

‎5.3.10.

Session Routing – Added XPSU check with

the required changes in message formats

(Full_Path_NPA, Full_Path_PDS) in ‎5.4.2,

‎5.4.3.7; added Initiating Entity Reference and

Additional Info to messages.

Session Initiation – Simplified Session

Entities state diagrams in ‎5.4.3.1, ‎5.4.3.2,

‎5.4.3.3, ‎5.4.3.4.

Session Maintainance – Added Section

‎5.4.4, and SMU message in ‎5.4.4.1.

Session Descriptors – Added Section ‎5.4.6.

Contact Information

Valens Semiconductor Ltd.

8 Hanagar St. • POB 7152

Hod Hasharon 45240 • Israel

Tel: +972-9-762-6900 • Fax: +972-9-762-6901

[email protected] • www.valens-semi.com

mailto:[email protected]

http://www.valens-semi.com/

Documents

HDBaseT Specification · HDBaseT Specification Version 1.45D 1 Confidential HDBaseT™ Specification Draft Version 1.45D November 12, 2010