HDBaseT Specification · HDBaseT Specification Version 1.45D 1 Confidential HDBaseT™...
Transcript of HDBaseT Specification · HDBaseT Specification Version 1.45D 1 Confidential HDBaseT™...
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
HDBaseT Specification Version 1.45D
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
HDBaseT Specification Draft Version 1.45D
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
HDBaseT Specification Version 1.45D
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
HDBaseT Specification Draft Version 1.45D
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
HDBaseT Specification Version 1.45D
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
HDBaseT Specification Draft Version 1.45D
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
HDBaseT Specification Version 1.45D
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
HDBaseT Specification Draft Version 1.45D
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
HDBaseT Specification Version 1.45D
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
HDBaseT Specification Draft Version 1.45D
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
HDBaseT Specification Version 1.45D
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
HDBaseT Specification Draft Version 1.45D
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
HDBaseT Specification Version 1.45D
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
HDBaseT Specification Draft Version 1.45D
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
HDBaseT Specification Version 1.45D
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
HDBaseT Specification Draft Version 1.45D
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
HDBaseT Specification Version 1.45D
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
HDBaseT Specification Draft Version 1.45D
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.
HDBaseT Specification Version 1.45D
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
HDBaseT Specification Draft Version 1.45D
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.
HDBaseT Specification Version 1.45D
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
HDBaseT Specification Draft Version 1.45D
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)
HDBaseT Specification Version 1.45D
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
HDBaseT Specification Draft Version 1.45D
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
HDBaseT Specification Version 1.45D
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
HDBaseT Specification Draft Version 1.45D
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
HDBaseT Specification Version 1.45D
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
HDBaseT Specification Draft Version 1.45D
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
HDBaseT Specification Version 1.45D
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
HDBaseT Specification Draft Version 1.45D
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.
HDBaseT Specification Version 1.45D
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.
HDBaseT Specification Draft Version 1.45D
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
HDBaseT Specification Version 1.45D
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
HDBaseT Specification Draft Version 1.45D
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
HDBaseT Specification Version 1.45D
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
transfer with at least 1e-12 (PER)
1e-122 (10)
Normal Quality – Data transfer using this quality code shall be
transfer with at least 1e-9 (PER)
1e-91 (01)
RemarkMax Allowed Packet
Error Rate
Quality Code
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
transfer with at least 1e-12 (PER)
1e-122 (10)
Normal Quality – Data transfer using this quality code shall be
transfer with at least 1e-9 (PER)
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:
HDBaseT Specification Draft Version 1.45D
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).
HDBaseT Specification Version 1.45D
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).
HDBaseT Specification Draft Version 1.45D
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
HDBaseT Specification Version 1.45D
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:
HDBaseT Specification Draft Version 1.45D
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
PID: 2 PID: 4 Packets not protected
by retransmission
PhyDS
Scheduler
234
Retrns
Module Phy DS
Dispatcher
1234Source Sink
Retrns
Module
PID: 5 PID: 2 Packets not protected
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.
HDBaseT Specification Version 1.45D
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:
HDBaseT Specification Draft Version 1.45D
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]
[TokD8 with RTS, TokD8]
[TokD16 with RTS, TokD12]
[TokD16 with RTS, TokD12]
[TokD16, TokD16]
Packet Types with Quality
Code 2 will be transmitted at
with max TokDx of:
[RTS able, No RTS]
[TokD12 with RTS, TokD8]000
[TokD16 with RTS, TokD12]101
[TokD16, TokD16] 110
[TokD16, TokD16]111
Packet Types with Quality
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
[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]
[TokD8 with RTS, TokD8]
[TokD16 with RTS, TokD12]
[TokD16 with RTS, TokD12]
[TokD16, TokD16]
Packet Types with Quality
Code 2 will be transmitted at
with max TokDx of:
[RTS able, No RTS]
[TokD12 with RTS, TokD8]000
[TokD16 with RTS, TokD12]101
[TokD16, TokD16] 110
[TokD16, TokD16]111
Packet Types with Quality
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:
HDBaseT Specification Version 1.45D
45
Confidential
Tok1 Tok2
First TokD16 Second TokD16
b15 b0 b0b15
Tok1[11:0] [ Tok2[7:0], Tok1[15:12] ]
First TokD12 Second TokD12
b11 b0 b0b11
[ [0,0,0,0],Tok2[15:8] ]
Third TokD12
b11 b0
Tok1[7:0] Tok1[15:8]
First TokD8 Second TokD8
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] ]
First TokD16 Second TokD16
b15 b0 b0b15
Tok1 Tok2
First TokD12 Second TokD12
b11 b0 b0b11
Tok3
Third TokD12
b11 b0
Tok1[7:0] [ Tok2[3:0], Tok1[11:8] ]
First TokD8 Second TokD8
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
Figure 20: Converting TokD12 to TokD16 and TokD8 - example
HDBaseT Specification Draft Version 1.45D
46
Confidential
[ Tok2, Tok1 ] [ [0,0,0,0], [0,0,0,0], Tok3 ]
First TokD16 Second TokD16
b15 b0 b0b15
[ Tok2[3:0], Tok1] [ Tok3, Tok2[7:4] ]
First TokD12 Second TokD12
b11 b0 b0b11
Tok1 Tok2
First TokD8 Second TokD8
b7 b0 b0b7
Tok3
Third TokD8
b7 b0
Two Nibbles
Padding
Figure 21: Converting TokD8 to TokD12 and TokD16 - example
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.
HDBaseT Specification Version 1.45D
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
HDBaseT Specification Draft Version 1.45D
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:
HDBaseT Specification Version 1.45D
49
Confidential
Table 7: Packet Type Codes with Their Associated Properties
Reserved packet type, define in Spec 2.0 1115Reserved
Reserved packet type, define in Spec 2.0 1314Reserved
Reserved packet type, define in Spec 2.0 2213Reserved
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
Reserved packet type, define in Spec 2.0 1115Reserved
Reserved packet type, define in Spec 2.0 1314Reserved
Reserved packet type, define in Spec 2.0 2213Reserved
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
HDBaseT Specification Draft Version 1.45D
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).
HDBaseT Specification Version 1.45D
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.
HDBaseT Specification Draft Version 1.45D
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:
HDBaseT Specification Version 1.45D
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
HDBaseT Specification Draft Version 1.45D
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.
HDBaseT Specification Version 1.45D
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
Generic Extended Info
1 Extended Info
Generic Extended Info
1 Extended Info
Generic 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
Generic Extended Info
1 Extended Info
Generic Extended Info
00 Nibbles
Pad Num
Ext
Info
Sync
End
Sync
Start
Extended
Info1
Extended Control Info
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
HDBaseT Specification Draft Version 1.45D
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
HDBaseT Specification Version 1.45D
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
HDBaseT Specification Draft Version 1.45D
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
HDBaseT Specification Version 1.45D
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
0000Byte-4 Byte-5 Byte-6 Byte-7Word-1
0000Byte-24 Byte-25 Byte-26 Byte-27Word-7
.
.
.
Frame-0
0000Byte-52 Byte-53 Byte-54 Byte-55Word-14
.
.
.
HDBaseT Specification Draft Version 1.45D
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-4 Byte-5 Byte-6 Byte-7
Byte-24
Byte-30 Byte-31
.
.
.
Bulk-0
Byte-52 Byte-53 Byte-54 Byte-55
.
.
.
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).
HDBaseT Specification Version 1.45D
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.
HDBaseT Specification Draft Version 1.45D
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:
HDBaseT Specification Version 1.45D
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:
HDBaseT Specification Draft Version 1.45D
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
Reserved 13-14 Reserved
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):
HDBaseT Specification Version 1.45D
65
Confidential
Ether 65 Block (64B/65B) 3
Ether-1Ether-2Ether-3Ether-4Ether-5
Ether 65 Block (64B/65B) 2
Ether-6Ether-7Ether-8Ether-9Ether-10Ether-11Ether-17
LSB
LSBIgnored
Reserved
Ether 65 Block (64B/65B) 1
Ether-12Ether-13Ether-14Ether-15Ether-16
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 65 Block (64B/65B) 2
Ether-1Ether-2Ether-3Ether-4Ether-5
Ether 65 Block (64B/65B) 1
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.
HDBaseT Specification Draft Version 1.45D
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
HDBaseT Specification Version 1.45D
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
HDBaseT Specification Draft Version 1.45D
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:
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:
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
HDBaseT Specification Version 1.45D
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:
HDBaseT Specification Draft Version 1.45D
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
HDBaseT Specification Version 1.45D
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
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
0000Byte-4 Byte-5 Byte-6 Byte-7Word-1
0000Byte-24 Byte-25 Byte-26 Byte-27Word-7
.
.
.
Frame-0
0000Byte-52 Byte-53 Byte-54 Byte-55Word-14
.
.
.
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.
HDBaseT Specification Draft Version 1.45D
72
Confidential
Byte-0 Byte-1 Byte-2 Byte-3
Byte-4 Byte-5 Byte-6 Byte-7
Byte-24
Byte-30 Byte-31
.
.
.
Bulk-0
Byte-52 Byte-53 Byte-54 Byte-55
.
.
.
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).
HDBaseT Specification Version 1.45D
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-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.
2.3.5 Upstream 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).
HDBaseT Specification Draft Version 1.45D
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.
HDBaseT Specification Version 1.45D
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:
HDBaseT Specification Draft Version 1.45D
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
Reserved 4-8 Reserved
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
Reserved 12-14 Reserved
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.
HDBaseT Specification Version 1.45D
77
Confidential
Ether 65 Block (64B/65B) 1
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
Ether 65 Block (64B/65B) 2
LSB MSB
Ether 65 Block (64B/65B) 3
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.
Ether 65 Block (64B/65B) 1
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
Ether 65 Block (64B/65B) 2
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.
HDBaseT Specification Draft Version 1.45D
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,
using 11 additional TokD12
tokens
Block 1 is present, using 6
additional TokD12 tokens
0011 First and second
blocks skipped
Blocks 3 is present, using 6
additional TokD12 tokens
No blocks sent, no
additional tokens used
0100 Third block skipped Blocks 1 and 2 are present,
using 11 additional TokD12
tokens
A Non-Valid value
0101 First and third blocks
skipped
Block 2 is present, using 6
additional TokD12 tokens
A Non-Valid value
0110 Second and third
blocks skipped
Block 2 is present, using 6
additional TokD12 tokens
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
HDBaseT Specification Version 1.45D
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.
HDBaseT Specification Draft Version 1.45D
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.
HDBaseT Specification Version 1.45D
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.
HDBaseT Specification Draft Version 1.45D
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 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). The calculation method is as in Ver 1.
HDBaseT Specification Version 1.45D
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
HDBaseT Specification Draft Version 1.45D
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.
HDBaseT Specification Version 1.45D
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
HDBaseT Specification Draft Version 1.45D
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:
HDBaseT Specification Version 1.45D
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
HDBaseT Specification Draft Version 1.45D
88
Confidential
5V/HPD information (line status)
Reserved 3-8 Reserved
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
Reserved 13-14 Reserved
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
4-bits 4-bits 4-bits
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
HDBaseT Specification Version 1.45D
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
4-bits 4-bits 4-bits
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.
HDBaseT Specification Draft Version 1.45D
90
Confidential
1001Start
Delimiter
Stream ID
Low
4-bits
End
Delimiter
4-bits 4-bits 4-bits
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
4-bits 4-bits 4-bits
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
4-bits 4-bits 4-bits
Target ModeAck.
Nack.
Req.
Resp.
Figure 60: HDSBI Mode Change Packet Structure
Table 25: HDSBI Mode Change Payload
Next
Mode
Description Value
HDBaseT Specification Version 1.45D
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
4-bits 4-bits 4-bits
0Silent
Act.
Ack.
Nack.
Req.
Resp.
Figure 61: HDSBI Active/Silent Change Packet Structure
HDBaseT Specification Draft Version 1.45D
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
4-bits 4-bits 4-bits
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.
HDBaseT Specification Version 1.45D
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
4-bits 4-bits 4-bits
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
4-bits 4-bits 4-bits
0Src
Snk
Req.
Resp.Ver.
HDBaseT Specification Draft Version 1.45D
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:
The “Bulk” – A “Bulk” is constructed from 2-16 “Long Packets”.
The “Frame” – A “Frame” is constructed from 1-256 “Bulks”.
2.5.5.1 Long Packets Format
Packet
Type
Start
DelimiterPacket Payload
4-bits
End
Delimiter
4-bits 24-bits 4-bits
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.
HDBaseT Specification Version 1.45D
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
4-bits 8-bits 4-bits
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”
HDBaseT Specification Draft Version 1.45D
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
4-bits 8-bits 4-bits
1:15
4-bits 8-bits 8-bits
Data Byte 1 Data Byte 2 Data Byte 3
Figure 67: Bulk Data Payload
2.5.5.3 Long Packet Example
Consider a data structure of 20 words, each word is 32-bits (total 80 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
0000Byte-4 Byte-5 Byte-6 Byte-7Word-1
0000Byte-44 Byte-45 Byte-46 Byte-47Word-20
.
.
.
Frame-0
0000Byte-76 Byte-77 Byte-78 Byte-79Word-20
.
.
.
HDBaseT Specification Version 1.45D
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-0 Byte-1 Byte-2 Byte-3
Byte-4 Byte-5 Byte-6 Byte-7
Byte-44
Byte-46 Byte-47
.
.
.
Bulk-0
Byte-76 Byte-77 Byte-78 Byte-79
.
.
.
Bulk-1
Byte-45
“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 44 which
represent 45 Data Bytes).
HDBaseT Specification Draft Version 1.45D
98
Confidential
Bulk Head0000Start
Delimiter
End
Delimiter0000 0x00 0x2C0x00
Bulk Data0000Start
Delimiter
End
Delimiter0001 Byte-1 Byte-2Byte-0
Bulk Data0000Start
Delimiter
End
Delimiter0010 Byte-4 Byte-5Byte-3
.
.
.Bulk Data0000
Start
Delimiter
End
Delimiter1111 Byte-43 Byte-44Byte-42
Bulk-0
“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 43 represents
4 Data Bytes).
Bulk Head0000Start
Delimiter
End
Delimiter0000 0x01 0x2B0x02
Bulk Data0000Start
Delimiter
End
Delimiter0001 Byte-46 Byte-47Byte-45
Bulk Data0000Start
Delimiter
End
Delimiter0010 Byte-49 Byte-50Byte-48
.
.
.Bulk Data0000
Start
Delimiter
End
Delimiter1111 Byte-79Byte-78
Bulk-1
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 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.
HDBaseT Specification Version 1.45D
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.
HDBaseT Specification Draft Version 1.45D
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.
HDBaseT Specification Version 1.45D
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.33.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
HDBaseT Specification Draft Version 1.45D
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:
HDBaseT Specification Version 1.45D
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:
HDBaseT Specification Draft Version 1.45D
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:
SD[2:0] are encoded over Channel A.
SD[5:3] are encoded over Channel B.
SD[8:6] are encoded over Channel C.
SD[11:9] are encoded over Channel D.
Per channel, each 3 bits word is being mapped to one symbol using gray code:
000 : 15
001 : 11
011 : 7
010 : 3
110 : -3
111 : -7
101 : -11
100 : -15Lsb
Figure 71: Downstream - per channel, mapping bits to s4dP8 symbol
HDBaseT Specification Version 1.45D
105
Confidential
S4dP4 – Carries 8 bits of scrambled data SD[7:0], 2 bits per channel:
SD[1:0] are encoded over Channel A.
SD[3:2] are encoded over Channel B.
SD[5:4] are encoded over Channel C.
SD[7:6] are encoded over Channel D.
Per channel, each 2 bits word is being mapped to one symbol using gray code:
00 : 15
01 : 7
11 : -7
10 : -15Lsb
Figure 72: Downstream - per channel, mapping bits to s4dP4 symbol
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.
HDBaseT Specification Draft Version 1.45D
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.
HDBaseT Specification Version 1.45D
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:
HDBaseT Specification Draft Version 1.45D
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:
HDBaseT Specification Version 1.45D
109
Confidential
SD[1:0] are encoded over Channel A.
SD[3:2] are encoded over Channel B.
SD[5:4] are encoded over Channel C.
SD[7:6] are encoded over Channel D.
Per channel, each 2 bits word is being mapped to one symbol using gray code:
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
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:
HDBaseT Specification Draft Version 1.45D
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
Figure 77: Downstream - per channel, mapping bits to s4dP16 symbol
S4dP8 – Carries 12 bits of scrambled data SD[11:0], 3 bits per channel:
SD[2:0] are encoded over Channel A.
SD[5:3] are encoded over Channel B.
SD[8:6] are encoded over Channel C.
SD[11:9] are encoded over Channel D.
Per channel, each 3 bits word is being mapped to one symbol using gray code:
000 : 15
001 : 11
011 : 7
010 : 3
110 : -3
111 : -7
101 : -11
100 : -15Lsb
Figure 78: Downstream - per channel, mapping bits to s4dP8 symbol
HDBaseT Specification Version 1.45D
111
Confidential
S4dP4 – Carries 8 bits of scrambled data SD[7:0], 2 bits per channel:
SD[1:0] are encoded over Channel A.
SD[3:2] are encoded over Channel B.
SD[5:4] are encoded over Channel C.
SD[7:6] are encoded over Channel D.
Per channel, each 2 bits word is being mapped to one symbol using gray code:
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
HDBaseT Specification Draft Version 1.45D
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
HDBaseT Specification Version 1.45D
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.
An Example of transmitter test mode 2 waveform is shown in Error! Reference source not found..
Figure 81: Example of transmitter test mode 2 waveform
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.
An Example of transmitter test mode 3 waveform is shown in Error! Reference source not found..
HDBaseT Specification Draft Version 1.45D
114
Confidential
Figure 82: Example of transmitter test mode 3 waveform
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)
HDBaseT Specification Version 1.45D
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
Figure 85: Transmitter test fixture 2
HDBaseT Specification Draft Version 1.45D
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
HDBaseT Specification Version 1.45D
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
HDBaseT Specification Draft Version 1.45D
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
HDBaseT Specification Version 1.45D
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:
HDBaseT Specification Draft Version 1.45D
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.
HDBaseT Specification Version 1.45D
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
HDBaseT Specification Draft Version 1.45D
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
HDBaseT Specification Version 1.45D
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)
HDBaseT Specification Draft Version 1.45D
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:
HDBaseT Specification Version 1.45D
125
Confidential
xxxxxxxx
Lane
DLane
C
Lane
B
Lane
A
MSB LSB
Figure 97: Upstream - 8-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 98: Upstream - per channel, mapping bits to s4dP8B symbol
4-bit Tokens
4-bit tokens are divided to one-bit per lane data:
xxxx
AMSB LSB
DCB
Figure 99: Upstream - 4-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:
HDBaseT Specification Draft Version 1.45D
126
Confidential
Figure 100: Upstream - per channel, mapping bits to s4dPIB symbol
Figure 101: Upstream - per channel, mapping bits to s4dP4B 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:
HDBaseT Specification Version 1.45D
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.
HDBaseT Specification Draft Version 1.45D
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:
HDBaseT Specification Version 1.45D
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
Error! Reference source not found..
HDBaseT Specification Draft Version 1.45D
130
Confidential
Transmitter
Under
Test
50Ω
50Ω
Vd
VA
Digital
Oscilloscope
Post-
ProcessingTX_TCLK
Figure 105: Transmitter test fixture 1
Transmitter
Under
Test
100Ω
VA
Jitter
AnalyzerTX_TCLK
Figure 106: Transmitter test fixture 2
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.
HDBaseT Specification Version 1.45D
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 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
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.
HDBaseT Specification Draft Version 1.45D
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
The receiver shall provide the Receive function in accordance with the electrical specifications of this clause.
3.3.4.1 Upstream Receiver differential input signals
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
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
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
HDBaseT Specification Version 1.45D
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.
HDBaseT Specification Draft Version 1.45D
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.
HDBaseT Specification Version 1.45D
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
HDBaseT Specification Draft Version 1.45D
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
Error! Reference source not found..
snk0_timer_done – indicates that at least snk0_timer_val msecs have passed since entering state SNK0.
snk1_timer_done – indicates that at least snk1_timer_val msecs have passed since entering state SNK1.
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.
snk5_timer_done – indicates that at least snk5_timer_val msecs have passed since entering state SNK5.
snk6_timer_done – indicates that at least snk6_timer_val msecs have passed since entering state SNK6.
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.
HDBaseT Specification Version 1.45D
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.
HDBaseT Specification Draft Version 1.45D
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.
During this state the upstream TX shall be silent.
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).
During this state the upstream TX shall be silent.
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.
HDBaseT Specification Version 1.45D
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
shall restart the startup procedure.
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.
src1_timer_done – indicates that at least src1_timer_val msecs have passed since entering state SRC1.
src3_timer_done – indicates that at least src3_timer_val msecs have passed since entering state SRC3.
src4_timer_done – indicates that at least src4_timer_val msecs have passed since entering state SRC4.
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.
src6_timer_done – indicates that at least src6_timer_val msecs have passed since entering state SRC6.
Activity Indications
HDBaseT Specification Draft Version 1.45D
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).
During this state the upstream TX shall be silent.
HDBaseT Specification Version 1.45D
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
shall restart the startup procedure.
SRC7. DATA
Upon entering this state the downstream TX shall transit to data mode (normal operation).
HDBaseT Specification Draft Version 1.45D
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
HDBaseT Specification Version 1.45D
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
HDBaseT Specification Draft Version 1.45D
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.
HDBaseT Specification Version 1.45D
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
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.
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..
HDBaseT Specification Draft Version 1.45D
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
The receiver shall provide the Receive function in accordance with the electrical specifications of this clause.
3.5.5.1 HDSBI Receiver Symbol Error Rate
Differential signals received at the MDI that were transmitted from a remote transmitter within the
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)
HDBaseT Specification Version 1.45D
147
Confidential
3.5.5.3 HDSBI 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
5 MHz can be used to simulate an external electromagnetic field
HDBaseT Specification Draft Version 1.45D
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:
HDBaseT Specification Version 1.45D
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
HDBaseT Specification Draft Version 1.45D
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
HDBaseT Specification Version 1.45D
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
HDBaseT Specification Draft Version 1.45D
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.
HDBaseT Specification Version 1.45D
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:
HDBaseT Specification Draft Version 1.45D
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
HDBaseT Specification Version 1.45D
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.74.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:
HDBaseT Specification Draft Version 1.45D
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
HDBaseT Specification Version 1.45D
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:
HDBaseT Specification Draft Version 1.45D
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)
HDBaseT Specification Version 1.45D
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.24.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:
HDBaseT Specification Draft Version 1.45D
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.
HDBaseT Specification Version 1.45D
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
HDBaseT Specification Draft Version 1.45D
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
HDBaseT Specification Version 1.45D
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.
HDBaseT Specification Draft Version 1.45D
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
HDBaseT Specification Version 1.45D
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
HDBaseT Specification Draft Version 1.45D
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:
HDBaseT Specification Version 1.45D
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)
HDBaseT Specification Draft Version 1.45D
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.
HDBaseT Specification Version 1.45D
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.
HDBaseT Specification Draft Version 1.45D
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.
HDBaseT Specification Version 1.45D
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
HDBaseT Specification Draft Version 1.45D
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
HDBaseT Specification Version 1.45D
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
Op CodeHD-CMP Payload
2 Bytes Variable Length
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.
HDBaseT Specification Draft Version 1.45D
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
Op CodeHD-CMP Payload
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:
HDBaseT Specification Version 1.45D
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
Op CodeHD-CMP Payload
2 Bytes
CRC-32
4 BytesVariable Length
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
HDBaseT Specification Draft Version 1.45D
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:
HDBaseT Specification Version 1.45D
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
HDBaseT Specification Draft Version 1.45D
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:
HDBaseT Specification Version 1.45D
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 in5.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
streams number in PSU (see 5.2.4.3) which exist/are-required along the path. When
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
streams number in PSU (see 5.2.4.3) which exist/are-required along the path. When
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.
HDBaseT Specification Draft Version 1.45D
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
Max payload of 121 symbols + 9 symbols framing
overhead + max of 4 optional extended info symbols
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
Payload of 3 symbols + 5 symbols framing overhead + 1
optional extended info symbol
19Micro Size
RemarkPSU
Weight
Max Total Packet Size
(including the trailing Idle
symbol) in Symbols
Max Packet Size
Class Name
Max payload of 255 symbols + 9 symbols framing
overhead + max of 4 optional extended info symbols
16268Full Size
Max payload of 121 symbols + 9 symbols framing
overhead + max of 4 optional extended info symbols
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
Payload of 3 symbols + 5 symbols framing overhead + 1
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.
HDBaseT Specification Version 1.45D
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
HDBaseT Specification Draft Version 1.45D
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
HDBaseT Specification Version 1.45D
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
HDBaseT Specification Draft Version 1.45D
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
HDBaseT Specification Version 1.45D
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:
HDBaseT Specification Draft Version 1.45D
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
HDBaseT Specification Version 1.45D
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.
HDBaseT Specification Draft Version 1.45D
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:
Path Description Section (PDS)
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
generator entity of the message shall allocate/initialize the proper section size and each
intermediate device shall update the NPA properly before propagating it.
Type Specific Payload – This section format is defined per message type.
HDBaseT Specification Version 1.45D
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.
HDBaseT Specification Draft Version 1.45D
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:
Path Description Section (PDS)
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
HDBaseT Specification Version 1.45D
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.
HDBaseT Specification Draft Version 1.45D
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
E1 End Node device without
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.
HDBaseT Specification Version 1.45D
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
E1 End Node device without
Ethernet Termination4
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.
HDBaseT Specification Draft Version 1.45D
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
E1 End Node device without
Ethernet Termination4
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
E1 End Node device without
Ethernet Termination4
DSPM: E3, E4
DSPM: E3, E4
MXPM: E3, E4
Figure 147: Propagating Periodic Intra SNPMs – Example - Step 2
S2 propagates the incoming DSPM to its downstream outputs (1 and 3) and as a MXPM to its other
downstream input.
HDBaseT Specification Version 1.45D
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
E1 End Node device without
Ethernet Termination4
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
Figure 148: Propagating Periodic Intra SNPMs – Example - Step 3
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).
HDBaseT Specification Draft Version 1.45D
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
E1 End Node device without
Ethernet Termination4
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
Figure 149: Propagating Periodic Intra SNPMs – Example - Step 4
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.
HDBaseT Specification Version 1.45D
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
E1 End Node device without
Ethernet Termination4
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.
HDBaseT Specification Draft Version 1.45D
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
E1 End Node device without
Ethernet Termination4
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
E1 End Node device without
Ethernet Termination4
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
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
Max Count: 7 Occ Count: 2
E3
Figure 152: PDS Usage in Periodic DSPM – Example – Step 2
HDBaseT Specification Version 1.45D
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
E1 End Node device without
Ethernet Termination4
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
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
Max Count: 7 Occ Count: 3
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
Max Count: 7 Occ Count: 2
MXPM: E3, E4
PDSE3
S3 will drop this
message since its device
ID already appears in
the PDS
Figure 153: PDS Usage in Periodic DSPM – Example – Step 3
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.
HDBaseT Specification Draft Version 1.45D
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:
HDBaseT Specification Version 1.45D
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
generator entity of the message shall allocate/initialize the proper section size and each
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.
HDBaseT Specification Draft Version 1.45D
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.
HDBaseT Specification Version 1.45D
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.
HDBaseT Specification Draft Version 1.45D
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
E1 End Node device without
Ethernet Termination4
000
000
000
000
000
000
10E3
Output
Port
Input
Port
Device
000
000
000
000
000
000
10E3
Output
Port
Input
Port
Device
Max Count: 7 Occ Count: 1
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
“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
E1 End Node device without
Ethernet Termination4
000
000
000
000
000
12S3
10E3
Output
Port
Input
Port
Device
000
000
000
000
000
12S3
10E3
Output
Port
Input
Port
Device
Max Count: 7 Occ Count: 2
E3
PDS
“With Path” U_DSPM:
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
Max Count: 7 Occ Count: 2
PDS
Figure 157: ‘With Path’ U_DSPM Propagation – Example – Step 2 - First Propagation
HDBaseT Specification Version 1.45D
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
“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
E1 End Node device without
Ethernet Termination4
000
000
000
000
34S2
12S3
10E3
Output
Port
Input
Port
Device
000
000
000
000
34S2
12S3
10E3
Output
Port
Input
Port
Device
Max Count: 7 Occ Count: 3
E3
PDS
“With Path” U_DSPM:
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
Max Count: 7 Occ Count: 3
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.
HDBaseT Specification Draft Version 1.45D
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
“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
E1 End Node device without
Ethernet Termination4
000
000
000
32S4
34S2
12S3
10E3
Output
Port
Input
Port
Device
000
000
000
32S4
34S2
12S3
10E3
Output
Port
Input
Port
Device
Max Count: 7 Occ Count: 4
E3
PDS
“With Path” U_DSPM:
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
Max Count: 7 Occ Count: 4
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.
HDBaseT Specification Version 1.45D
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
“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
E1 End Node device without
Ethernet Termination4
000
000
31S5
32S4
34S2
12S3
10E3
Output
Port
Input
Port
Device
000
000
31S5
32S4
34S2
12S3
10E3
Output
Port
Input
Port
Device
Max Count: 7 Occ Count: 5
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.
HDBaseT Specification Draft Version 1.45D
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
E1 End Node device without
Ethernet Termination4
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
Max Count: 4 Occ Count: -4
Figure 162: Backward ‘By PDS’ U_USPM Propagation – Example – Step 1 - Message Format
HDBaseT Specification Version 1.45D
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
E1 End Node device without
Ethernet Termination4
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: -3
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
Max Count: 4 Occ Count: -3
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
HDBaseT Specification Draft Version 1.45D
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
E1 End Node device without
Ethernet Termination4
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: -2
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
E1 End Node device without
Ethernet Termination4
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: -1
PDS
Message
reached E3
Figure 166: Backward ‘By PDS’ U_USPM Propagation – Example – Step 4 – Third Propagation
HDBaseT Specification Version 1.45D
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.
HDBaseT Specification Draft Version 1.45D
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:
HDBaseT Specification Version 1.45D
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
DownstreamS5E7 PDME reference: E7:1
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
DownstreamS5E6 PDME reference: E6:1
UpstreamS4E5 reference: S4:4
UpstreamS3E4 PDME reference: S3:3
DownstreamS5E7 PDME reference: E7:1
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.
HDBaseT Specification Draft Version 1.45D
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.
HDBaseT Specification Version 1.45D
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.
HDBaseT Specification Draft Version 1.45D
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
PDME: By Periodic SNPM
SDME: Device Status Broadcast
CPME: Device Status Broadcast
RPE: Device Status Broadcast
“Many” CPs &
“Many” RPEs
PDME: By Unicast SNPM / f rom RPE
SDME: By Unicast SNPM / f rom RPE
CPME: From RPE
RPE: Link Status Unicast
PDME: By Periodic SNPM
SDME: By Periodic SNPM
CPME: Directional Connectivity Broadcast
RPE: Directional Connectivity Broadcast
PDME: By Periodic SNPM
SDME: Device Status Broadcast
CPME: Device Status Broadcast
RPE: Device Status Broadcast
“Many” CPs &
“Few” RPEs
PDME: By Unicast SNPM / f rom RPE
SDME: By Unicast SNPM / f rom RPE
CPME: From RPE
RPE: Link Status Unicast
PDME: By Periodic SNPM
SDME: By Periodic SNPM
CPME: Directional Connectivity Unicast
RPE: Directional Connectivity Unicast
PDME: By Periodic SNPM
SDME: By Periodic SNPM
CPME: Device Status Unicast
RPE: Device Status Unicast
“Few” CPs &
“Few” RPEs
PDME: By Unicast SNPM
SDME: By Unicast SNPM
CPME: By Unicast SNPM
PDME: By Periodic SNPM
SDME: By Periodic SNPM
CPME: Directional Connectivity Broadcast
PDME: By Periodic SNPM
SDME: Device Status Broadcast
CPME: Device Status Broadcast
“Many” CPs &
No RPEs
PDME: By Unicast SNPM
SDME: By Unicast SNPM
CPME: By Unicast SNPM
PDME: By Periodic SNPM
SDME: By Periodic SNPM
CPME: Directional Connectivity Unicast
PDME: By Periodic SNPM
SDME: By Periodic SNPM
CPME: Device Status Unicast
“Few” CPs &
No RPEs
PDME: By Unicast SNPM
SDME: By Unicast SNPM
PDME: By Periodic SNPM
SDME: By Periodic SNPM
PDME: By Periodic SNPM
SDME: By Periodic SNPM
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.
HDBaseT Specification Version 1.45D
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.
HDBaseT Specification Draft Version 1.45D
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
HDBaseT Specification Version 1.45D
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).
HDBaseT Specification Draft Version 1.45D
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.
HDBaseT Specification Version 1.45D
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”.
HDBaseT Specification Draft Version 1.45D
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 section5.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.
HDBaseT Specification Version 1.45D
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
HDBaseT Control Point
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
“Best Path” U_DSPM
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.
HDBaseT Specification Draft Version 1.45D
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
“Best Path” U_DSPM
BDP Living Room TV Control Point
Session Creation Completed
Session EstablishedHDBaseT Control Point
DV
HDBaseT Control Point
DV
Session Initiation Request (Send SRQ)
Session Initiation Response (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
HDBaseT Control Point
DV
HDBaseT Control Point
DV
Switch S1 Switch S2
Session Route Query
“Best Path” U_DSPM
Figure 170: DRS Session Creation Process – Example 2 – TV Initiating
HDBaseT Specification Version 1.45D
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
“Best Path” U_DSPM
BDP Legacy HDMI-CEC TV Control Point
Session Creation Completed
Session EstablishedHDBaseT Control Point
DV
HDBaseT Control Point
DV
Session Initiation Request (First)
Session Initiation Response (Ack)
Session
Initiation
Session
Route Query
Session
Route Select
S2 Selects The
Best Route
Session Route Set
“By PDS” Backward
U_USPM
Session
Route Set
Session
Creation
Completed
“Initiating Entity”
&
“Second Partner”
&
“Selecting Entity”
“First Partner”
Direct Broadcast
HDBaseT Control Point
DV
HDBaseT Control Point
DV
Switch S1 Switch S2
Session Route Query
“Best Path” U_DSPM
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:
HDBaseT Specification Draft Version 1.45D
226
Confidential
Session Route Query
“Best Path” U_DSPM
BDP Living Room TV Control Point
Session Creation Completed
Session Established
HDBaseT Control Point
DV
HDBaseT Control Point
DV
Session Initiation Response (Ack)Session
Initiation
Session
Route Query
Session
Route Select
Session Route Set
“By PDS” Backward
U_USPMSession
Route Set
Session
Creation
Completed
“Initiating Entity”
&
“Selecting Entity”
“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 Request (Send SRQ)
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:
HDBaseT Specification Version 1.45D
227
Confidential
Session Initiation Request (Second)
BDP Living Room TV Control Point / RPE
Session Creation Completed
Session Established
HDBaseT Control Point
DV
HDBaseT Control Point
DV
HDBaseT Control Point
DV
HDBaseT Control Point
DV
Session Initiation Response (Ack)
Session Initiation Request (First)
Session Initiation Response (Ack)
Session
Initiation
Session
Route Query
Session
Route Select
Session Route Set
“By PDS” Backward
U_USPMSession
Route Set
Session
Creation
Completed
“Initiating Entity”
&
“Computing Entity”
“Second Partner”“First Partner”
Direct Broadcast
Route Select Response
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:
HDBaseT Specification Draft Version 1.45D
228
Confidential
Control Point / RPE
Session Creation Completed
Session Established
HDBaseT Control Point
DV
HDBaseT Control Point
DV
HDBaseT Control Point
DV
HDBaseT Control Point
DV
Session
Initiation
Session
Route Query
Session
Route Select
Session Route Set
“By PDS” Backward
U_USPMSession
Route Set
Session
Creation
Completed
“Initiating Entity”
&
“Computing Entity”
Direct Broadcast
Route Select Response
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.
HDBaseT Specification Version 1.45D
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.
HDBaseT Specification Draft Version 1.45D
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).
HDBaseT Specification Version 1.45D
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).
HDBaseT Specification Draft Version 1.45D
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.
HDBaseT Specification Version 1.45D
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.
HDBaseT Specification Draft Version 1.45D
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.
HDBaseT Specification Version 1.45D
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
Op CodeHD-CMP Payload
2 Bytes Variable Length
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
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
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”.
HDBaseT Specification Draft Version 1.45D
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.
HDBaseT Specification Version 1.45D
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.
HDBaseT Specification Draft Version 1.45D
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
message (the first 7 bits are not all zero)
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”.
HDBaseT Specification Version 1.45D
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
Op CodeHD-CMP Payload
2 Bytes
CRC-32
4 BytesVariable Length
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
Reference2+ Bytes 2+ Bytes 12 Bytes 1 Byte 8 Bytes
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
Reference10+ Bytes 10+ Bytes 12 Bytes 1 Byte 8 Bytes
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
HDBaseT Specification Draft Version 1.45D
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.25.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.
HDBaseT Specification Version 1.45D
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.
Additional_P3_PSU = TSR_P3_PSU : For a victim P3 packet, This Session P3 streams may interfere
only once in the path.
HDBaseT Specification Draft Version 1.45D
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.
Additional_P3_PSU = TSR_P3_PSU : For a victim P3 packet, This Session P3 streams may interfere
only once in the path.
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:
HDBaseT Specification Version 1.45D
243
Confidential
HD-CMP
Op CodeHD-CMP Payload
2 Bytes Variable Length
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
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
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
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
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 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
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.
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.
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:
HDBaseT Specification Draft Version 1.45D
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
Op CodeHD-CMP Payload
2 Bytes Variable Length
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
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
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:
HDBaseT Specification Version 1.45D
245
Confidential
o Prefix - The 12 most significant bits shall be set to 0x024. 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 set to one to
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 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
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.
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. 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.
HDBaseT Specification Draft Version 1.45D
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
Op CodeHD-CMP Payload
2 Bytes
CRC-32
4 BytesVariable Length
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 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 „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
NPA (see section 5.2.4.2).
HDBaseT Specification Version 1.45D
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.
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 FDER:FPTM shall be the full reference for
the “First Partner” T-Adaptors entities participating in this session.
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 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
HDBaseT Specification Draft Version 1.45D
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
Op CodeHD-CMP Payload
2 Bytes Variable Length
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
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
message (the first 7 bits are not all zero)
o Request/Response Bit Flag – b3 is marking request/response and shall be set to one to
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.
HDBaseT Specification Version 1.45D
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.
HDBaseT Specification Draft Version 1.45D
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:
HDBaseT Specification Version 1.45D
251
Confidential
Length HLIC
Short Form1 0 0 0 0 0 0
HD-CMP
Op CodeHD-CMP Payload
2 Bytes
CRC-32
4 BytesVariable Length
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 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 represent the value „0010‟ marking the
SMU type.
o U_SNPM Mod – Shall be set to „By PDS‟.
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
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
NPA (see section 5.2.4.2).
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.
HDBaseT Specification Draft Version 1.45D
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.
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 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.
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: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:
HDBaseT Specification Version 1.45D
253
Confidential
ER
Length HLIC
Short Form1 0 0 0 0 0 0
HD-CMP
Op CodeHD-CMP Payload
2 Bytes
CRC-32
4 BytesVariable Length
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 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 represent the value „0010‟ marking the
STU type.
o U_SNPM Mod – Shall be set to „By PDS‟.
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
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
NPA (see section 5.2.4.2).
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).
HDBaseT Specification Draft Version 1.45D
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.
First Partner T-Adaptors Reference (FPTR) - A 10+ byte reference (Device ID : TPG : T-Adaptors
Type Mask - see section 5.1.4) to the session‟s First Partner device.
HDBaseT Specification Version 1.45D
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.
HDBaseT Specification Draft Version 1.45D
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.
HDBaseT Specification Version 1.45D
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.
HDBaseT Specification Draft Version 1.45D
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.
HDBaseT Specification Version 1.45D
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
HDBaseT Specification Draft Version 1.45D
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
HDBaseT Specification Version 1.45D
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…)
HDBaseT Specification Draft Version 1.45D
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
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
HDBaseT Specification Version 1.45D
263
Confidential
RX Port ID RX Port ID of Immediate (directly connected) Neighbor‟s Device‟s Device ID
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
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
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
HDBaseT Specification Draft Version 1.45D
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
TX Port ID TX Port ID of Sender‟s 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
HDBaseT Specification Version 1.45D
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:
HDBaseT Specification Draft Version 1.45D
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).
HDBaseT Specification Version 1.45D
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
HDBaseT Specification Draft Version 1.45D
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.
•
HDBaseT Specification Version 1.45D
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.
HDBaseT Specification Draft Version 1.45D
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.
HDBaseT Specification Version 1.45D
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.
HDBaseT Specification Draft Version 1.45D
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.
HDBaseT Specification Version 1.45D
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
HDBaseT Specification Draft Version 1.45D
274
Confidential
Figure 203: An example of Routing Tables for Link State Routing Using Dijkstra’s algorithm
HDBaseT Specification Version 1.45D
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:
HDBaseT Specification Draft Version 1.45D
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.
HDBaseT Specification Version 1.45D
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.
HDBaseT Specification Draft Version 1.45D
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
HDBaseT Specification Version 1.45D
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:
Ether 65 Block (64B/65B) 12
Ether-1Ether-2Ether-3Ether-4Ether-5
Ether 65 Block (64B/65B) 2
Ether-6Ether-7Ether-8Ether-9Ether-10Ether-11Ether-65
LSB
LSB
Ether 65 Block (64B/65B) 1
Ether-60Ether-61Ether-62Ether-63Ether-64
. . .
. . .
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
Generic Extended Info
1 Extended Info
Generic Extended Info
011
1Nibbles
Pad Num
Bad
CRC0 0 01
Extended Control Info
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.
HDBaseT Specification Draft Version 1.45D
280
Confidential
Ether 65 Block (64B/65B) 12
Ether-1Ether-2Ether-3Ether-4Ether-5
Ether 65 Block (64B/65B) 3
Ether-6Ether-7Ether-8Ether-9Ether-10Ether-11Ether-60
LSB
LSB
Ether 65 Block (64B/65B) 1
Ether-55Ether-56Ether-57Ether-58Ether-59
. . .
. . .
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.
HDBaseT Specification Version 1.45D
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
HDBaseT Specification Draft Version 1.45D
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.
HDBaseT Specification Version 1.45D
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:
HDBaseT Specification Draft Version 1.45D
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.
HDBaseT Specification Version 1.45D
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.
HDBaseT Specification Draft Version 1.45D
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
HDBaseT Specification Version 1.45D
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
HDBaseT Specification Draft Version 1.45D
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
HDBaseT Specification Version 1.45D
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
HDBaseT Specification Draft Version 1.45D
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:
HDBaseT Specification Version 1.45D
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
HDBaseT Specification Draft Version 1.45D
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
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 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).
HDBaseT at Initiator side
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
HDBaseT Specification Version 1.45D
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.
HDBaseT Specification Draft Version 1.45D
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.
HDBaseT Specification Version 1.45D
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:
HDBaseT Specification Draft Version 1.45D
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:
HDBaseT Specification Version 1.45D
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:
HDBaseT Specification Draft Version 1.45D
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]]
First TokD16 Second TokD16
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
Packet Type Code = 8
HDBaseT Specification Version 1.45D
299
Confidential
Token Type = 1 .. which means: use TokD12 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) 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]]
First TokD12 Second TokD12
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:
HDBaseT Specification Draft Version 1.45D
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
Packet Type Code = 9
Token Type = 1 .. which means: use TokD12 to encode data
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:
HDBaseT Specification Version 1.45D
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
HDBaseT Specification Draft Version 1.45D
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)
HDBaseT Specification Version 1.45D
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
1 TokD12 Link TokenMsb Lsb
TMDS Clk
1
TMDS Clk
2
[ 000000000000 ]
Video Active Pixels
Leading
Guard Band
1 TokD12 Link TokenMsb Lsb
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).
HDBaseT Specification Draft Version 1.45D
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
1 TokD12 Link TokenMsb Lsb
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
HDBaseT Specification Version 1.45D
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
Type Stream ID Length
TokD8 TokD8
Clk Cnt
HighCRC-8 Idle
TokD8 TokCrc TokIdlTokD8
Clk Cnt
Low
Header Clock Count Payload Tail
HDBaseT Specification Draft Version 1.45D
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
Type Stream ID Length
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
HDBaseT Specification Version 1.45D
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)
HDBaseT Specification Draft Version 1.45D
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%.
HDBaseT Specification Version 1.45D
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
HDBaseT Specification Draft Version 1.45D
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
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
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
IR Message [b23:b16]
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.
HDBaseT Specification Version 1.45D
311
Confidential
LengthType
b0b1b2b3b4b5b6b7
Ext.
1 1 1 0 0
Subpacket Header Token SID Token
SID
b4b5b6b7 b0b1b2b3
0 1 0
Extended Control Info Token
Payload Token #1
IR Message [b7:b0]
b4b5b6b7 b0b1b2b3
Payload Token #2
IR Message [b15:b8]
b4b5b6b7 b0b1b2b3
Payload Token #3
IR Message [b23:b16]
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.
HDBaseT Specification Draft Version 1.45D
312
Confidential
Table 59: UART T-adaptor Attributes
Attribute Value Remarks
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
Path Type Mixed Path
Bad CRC handling Yes Parity Error or Framing Error – See above
Use clock service No
Session Initiation Association /
CPME
Cannot self initiate session
10.4.3 T-Adaptor Info Format
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.
HDBaseT Specification Version 1.45D
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.
HDBaseT Specification Draft Version 1.45D
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
Packet Type SID Token
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
Packet Type SID Token
SID
b4b5b6b7 b0b1b2b3
Payload Length
1
b4b5b6b7 b0b1b2b3
UART Token
UART data
b4b5b6b7 b0b1b2b3
Extended Control Info Token
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.
HDBaseT Specification Version 1.45D
315
Confidential
LengthType
b0b1b2b3b4b5b6b7
Ext.
0 1 1 0 0
Subpacket Header Token SID Token
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
Subpacket Header Token SID Token
SID
b4b5b6b7 b0b1b2b3
0 0 0
UART Token
UART data
b4b5b6b7 b0b1b2b3
Extended Control Info Token
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.
HDBaseT Specification Draft Version 1.45D
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.
HDBaseT Specification Version 1.45D
317
Confidential
Table 62: SPDIF T-adaptor Attributes
Attribute Value Remarks
Type 11
Priority 2
Quality 2
Use Retransmission Yes
Use NibbleStream Yes
Multi T-Stream No
Path Type Mixed Path
Bad CRC handling Yes Parity Error – See above
Use clock service Yes Using Network Clock Service – See Below
Session Initiation Association /
CPME
Cannot self initiate session
10.5.4 T-Adaptor Info Format
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).
HDBaseT Specification Draft Version 1.45D
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
Packet Type SID Token
SID
Payload Length
4
b1b2b3b4 b0b5b6b7 b4b5b6b7 b0b1b2b3 b4b5b6b7 b0b1b2b3
Payload Token #1
Nibble #1
b4b5b6b7 b0b1b2b3b8b9b10b11
Nibble #6 Nibble #5
Payload Token #2
Nibble #4
b4b5b6b7 b0b1b2b3b8b9b10b11
0 Nibble #11
Payload Token #4
Nibble #10
b4b5b6b7 b0b1b2b3b8b9b10b11
Extended Control Info Token
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).
HDBaseT Specification Version 1.45D
319
Confidential
Ext.
1
Token Type
2
Packet Type Code
1
Packet Type SID Token
SID
Payload Length
3
Payload Token #1
0 1 0 0 0 0 0 0
b1b2b3b4 b0b5b6b7 b4b5b6b7 b0b1b2b3 b4b5b6b7 b0b1b2b3
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
Extended Control Info Token
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
Subpacket Header Token SID Token
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
b4b5b6b7 b0b1b2b3b8b9b10b11
Nibble #6 Nibble #5
Payload Token #2
Nibble #4
b4b5b6b7 b0b1b2b3b8b9b10b11
0 Nibble #26
Payload Token #9
Nibble #25
b4b5b6b7 b0b1b2b3b8b9b10b11
Extended Control Info Token
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
Extended Control Info Token
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
HDBaseT Specification Draft Version 1.45D
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.
HDBaseT Specification Version 1.45D
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