HDBaseT Contribution: Link Specification 2.0 Company Name: Valens Semiconductor Contribution Title: HDBaseT Link Specification 2.0 Date Submitted: 28/4/2010 Source: Eyran Lida Company: Valens Semiconductor Abstract: Technical proposal for HDBaseT link specification 2.0 is described. Purpose: Provide ground base for Spec 2.0 development Release: Valens Confidential, Contributed Pursuant to Section 3.1 of the HDBaseT Alliance Bylaws. HDBaseT Contribution
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Abstract: Technical proposal for HDBaseT link specification 2.0 is
described.
Purpose: Provide ground base for Spec 2.0 development Release:
Valens Confidential, Contributed Pursuant to Section 3.1 of the
HDBaseT Alliance Bylaws.
HDBaseT Contribution
• Network Objectives
– Downstream sub link
– Upstream sub link
HDBaseT Contribution: Link Specification 2.0 Company Name: Valens
Semiconductor
• Support in parallel, over the same, home span cabling
infrastructure, high quality networking of:
– Time sensitive data streams such as
• HDMI 1.4 streams with their associated controls
• S/PDIF streams
• USB streams
– Ethernet data
• Provides transparent network attachment for legacy
devices/interfaces – HDMI, Ethernet, USB and S/PDIF
• Provides 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 a HDBaseT Network
Control Points
• Enable low cost solutions for the CE price points
3
• Downstream sub link:
– Local Retransmission - new mechanism for per hop retransmission
to improve robustness and performance margin
• 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 fallback to 100BaseTX as in Spec 1.0
• Support backward compatibility with Spec 1.0 devices
Proposed Link Spec 2.0 Features (1)
HDBaseT Contribution: Link Specification 2.0 Company Name: Valens
Semiconductor 5
• Multi Stream support: At the same time, over a single link,
support of up to:
– 8 HDMI 1.4 down streams
– 12 USB or S/PDIF bi directional streams
– 8 IR and 8 UART bi-directional streams
• Support for general framing to enable future protocols/interfaces
clients for the HDBaseT network (see the rest of the presentation
for more explanations about the concept)
• Support for T-Network services (see the rest of the presentation
for more explanations about the concept)
• Support LPPF #1 as in Spec 1.0 and add support for IR and UART
during LPPF #1
• Support the option for LPPF #2 as in Spec 1.0
• Support Wake UP / stand By HLIC commands for device power
management
• Support link management HLIC commands
Proposed Link Spec 2.0 Features (2)
HDBaseT Contribution: Link Specification 2.0 Company Name: Valens
Semiconductor 6
• A local, single, packet retransmission mechanism comprises the
following steps:
– Each protected packet contains additional Packet ID (PID) as part
of its header, PIDs are transmitted in sequential order
– The receiver detects a CRC error in a received packet with an
expected PID or the receiver receives a good packet with gap in its
PID
– The receiver sends a proper retransmission request to the
sender
– The sender retransmit the packet back to the receiver
• In order to implement such mechanism without violating the
packets sequential order (of the video data for instance) it is
clear that the receiver must use packets buffer that will introduce
latency on all protected packets good or bad
• When ever a retransmitted packet is received it will be inserted
into its original location in the receiver packets buffer keeping
the packets order
• The sender must also use a packets buffer to be able to save
transmitted packets in case it will need to retransmit them
Local Retransmission Mechanism
Retransmission Conceptual Drawing – Bad CRC case
PhyDS Scheduler
Retrns Module
Retrns Module
PhyDS Scheduler
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
Retransmission Conceptual Drawing – Packet Loss/Corrupt Case
PhyDS Scheduler
Retrns Module
Retrns Module
PhyDS Scheduler
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
HDBaseT Contribution: Link Specification 2.0 Company Name: Valens
Semiconductor 9
• If a downstream packet was transmitted as participating in the
retransmission mechanism, it will travel the rest of its downstream
network path (per each network hop) as part of the retransmission
mechanism
• Per session the T-Adaptor, may pre select to use retransmission
protection for all packets, with certain packet types, or not to
use it for all packets of these types (it shall not flip its
selection during that session)
• Usage of retransmission introduces additional fix latency (of
7uS) per hop but shall not introduce more latency variation
• PAM16 packets will be protected using, per hop, single
retransmission of equivalent PAM8 packets carrying the same data
(the max payload length for retransmission protected, PAM16
packets, will be limited to 190 tokens)
• PAM8 and PAM4 packets will be protected using, per hop, single
retransmission of the same packet
– Reception of a protected PAM4 packet, with bad CRC, will not
cause retransmission since packet’s header modulation is the same
as the payload therefore have equivalent probability to be
erroneous
– Only gap detection will cause PAM4 retransmission
Packet Retransmission and Payload Modulation Relations
HDBaseT Contribution: Link Specification 2.0 Company Name: Valens
Semiconductor 10
• An 8 bits retransmission header token will be added to such
packets header, before the Length token
• For such packets, the CRC field is extended to 32 bits
• b4 at the Packet Type token will represent the presence of a
retransmission header token (RTS Head) and a trailing CRC-32
• Total packet overhead increased by 4 TokD8 tokens
Packet Retransmission Changes to the Packet Format
Stream ID CRC-8 Idle… Payload
TokD8 TokDxx
Stream ID Idle… Payload
Payload Length TokD8 TokCrcTokCrcTokCrc
Packet Type and RTS Header Tokens
b7
b3:b0 -Packet type code is a 4 bits value which contains the packet
type 0 to 15
b4 – when set to 1, is marking that this packet is part of the
retransmission mechanism
b6:b5 - S4d Type is a two bits field marking the Payload’s s4d
symbols type:
00 – s4dP16
01- s4dP8
10 – s4dP4
b7 - when set to 1 is marking that the extended header option is
used and the next symbol is an extended info symbol
b6
b7
b6:b0 - Packet ID is a 7 bits sequential cyclic value continuously
attach to each transmitted packet which is part of the
retransmission mechanism (shared among all packet types)
b7 – RTSEnable
when set to 1, upon reception, this packet can cause a
retransmission request and is inserted to the fix latency packets
buffer
when set to 0 this packet is a retransmitted packet and therefore
shall not cause a retransmission request
b6
Payload Length TokD8 TokCrcTokCrcTokCrc
HDBaseT Contribution: Link Specification 2.0 Company Name: Valens
Semiconductor 12
• The HDBaseT network core provides general, packet based,
T-Network services for the different clients attach 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 client to measure the
frequency offset between the originating client clock and the
target client clock to enable proper clock regeneration for
mesochronous applications such as video
– Bad CRC notification, propagation to the End Node, enabling the
end node to treat this packet according to its special
application
– Nibble Stream service supporting split and merge of packets going
in and out of the upstream links on their network path
HDBaseT T-Network Services
Quality and Priority
• For each HDBaseT packet type there are Transfer-Quality and
Scheduling-Priority properties associated with it according to the
requirement of the data type being carried by this packet
• Current packet types (Link Specification ver 1.0 and ver 2.0)
will have, pre define, Quality and Priority association
• Future packet types/protocols (Link Specification ver 3.0 and
higher) will carry their Quality and Priority in the extended type
token, within each packet header
• Packet type’s, Quality and Priority properties, will be use, by
the switches, along the network path to insure the proper service
is provided, for this packet type
HDBaseT Contribution: Link Specification 2.0 Company Name: Valens
Semiconductor 14
Transfer-Quality Codes
• The per packet type, Transfer-Quality property, creates
differentiation in the service provided by the network, for
different data types, in terms of target max Packet Error Rate
(PER)
• For packets with higher Transfer-Quality, their payload will be
transmitted using lower order modulation utilizing more channel
bandwidth per info unit
• The HDBaseT Link will set the actual payload modulation order
according to the channel condition and the required
Transfer-Quality
Quality Code Max Allowed Packet Error Rate
Remark
1 (01) 1e-9 Normal Quality – Data transfer using this quality code
shall be transfer with at least 1e-9 (PER)
2 (10) 1e-12 High Quality – Data transfer using this quality code
shall be transfer with at least 1e-12 (PER)
3 (11) 1e-16 Very High Quality – Data transfer using this quality
code shall be transfer with at least 1e-16 (PER)
HDBaseT Contribution: Link Specification 2.0 Company Name: Valens
Semiconductor 15
Scheduling-Priority Codes • The per packet type,
Scheduling-Priority property, creates differentiation in the
service provided by the network, for different data types, in terms
of target max latency and max latency variation over the full
network path
• Packets with higher Priority will be schedule, for transmission
over the HDBaseT network hops, 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
Priority Code
Target Max Latency Variation [DS, US]
Max BW per stream
1 (01) [100uS, 50uS] [10uS, 40uS] Large (DS BW)
Normal Priority – provides low latency variation for large BW Down
streams such as video
2 (10) [100uS, 30uS] [10uS, 20uS] Medium (US BW)
High Priority – provides lower latency variation for mid BW Up
streams such as S/PDIF
3 (11) [10uS, 20uS] [5uS, 10uS] Small Very High Priority – provides
low latency for small BW, latency sensitive, data types such as
DDC
HDBaseT Contribution: Link Specification 2.0 Company Name: Valens
Semiconductor 16
Current Packet Types (Spec 1.0 and Spec 2.0) Pre Defined Quality
and Priority Codes
Packet Type Packet Type Code
Quality Code Priority Code
Remarks
General Status 0 3 3 Non AV stream related status and control
see
Ethernet data 1 2 2
Clock Info 2 3 2 Original Packet is generalized in Spec 2.0 to
provide clock measurement service
Stream Control 3 3 3 DDC, CEC, HPD, 5V indication
HDMI-AV Control Data (CC) 4 3 1 Control period, no guard band
HDMI-AV Control Data (CG) 5 3 1 Control Period, ends with guard
band
HDMI-AV Control Data (GC) 6 3 1 Control Period, starts with guard
band
HDMI-AV Control Data (GCG) 7 3 1 Control Period, starts and ends
with guard
HDMI-AV Active Pixels Data 8 1 1 Active Pixels Data
HDMI-AV Data Island Data 9 3 1 Data Island
USB Data 10 2 1 USB Data, new packet type, define in Spec 2.0
S/PDIF Data 11 2 2 S/PDIF Audio Data, new packet type, define in
Spec 2.0
CIR / UART Data 12 3 3 Consumer IR and UART Data, new packet type,
define in Spec 2.0
Reserved 13 2 2 Reserved packet type, define in Spec 2.0
Reserved 14 3 1 Reserved packet type, define in Spec 2.0
Reserved 15 1 1 Reserved packet type, define in Spec 2.0
HDBaseT Contribution: Link Specification 2.0 Company Name: Valens
Semiconductor 17
Quality and Priority Data Types Plain
Priority Quality
Normal 1
High 2
High 2 USB
General Status Stream Control
HDBaseT Contribution: Link Specification 2.0 Company Name: Valens
Semiconductor 18
Future Packet Types (Spec 3.0 and on) Will Use the Optional
Extended Type Token
Bad CRC
Quality Priority
b7 b0
b3:b0 – New Packet type code is a 4 bits value which contains the
packet type 0 to 15 there are 16 types per Quality and
Priority
b4 – when set to 1, is marking that this packet should be protected
by the retransmission mechanism
b6:b5 – are set to 11 which is not valid S4d Type
b7 - set to 1 is marking that the extended type symbol is
following
b6
b7 b0b6
Extended Type
b1:b0 – S4d type same as the token Type field in the non extended
packet type
b3:b2 – Priority Code of this type
b5:b4 – Quality Code of this type
b6 – Bad CRC propagation bit marking that this packet suffers a bad
CRC in at least one of the network hops
b7 - when set to 1 is marking the presence of an additional
Extended Info Symbol
b3b4b5
• Future packet types will carry the Transfer-Quality and
Scheduling-Priority, properties in their extended type token:
HDBaseT Contribution: Link Specification 2.0 Company Name: Valens
Semiconductor 19
Spec 2.0 Dynamic S4D Modulation per Transfer- Quality and HDBaseT
Link Quality
• Per packet type, Per network hop, an HDBaseT downstream
transmitter will determine, the proper s4d modulation to be use
according to the quality of this next HDBaseT hop and the
Transfer-Quality associated with this packet type
• Downstream receivers will periodically report (to the downstream
transmitters) the quality of the HDBaseT link, using the Idle
subtype tokens, transferred through the upstream link
• The downstream transmitter will use these reports to assign the
proper s4d modulation according to the required
Transfer-Quality
• Usage of retransmission, in conjunction with s4d modulation, is
also a key factor for achieving the proper Transfer-Quality in the
downstream link
• At the upstream link the s4d modulation is according to the
Transfer-Quality:
– Sub packet types with Transfer-Quality Codes 1 and 2 uses s4dP16B
symbols for their payloads
– Sub packet types with Transfer-Quality Code 3 uses s4dP8B symbols
for their payloads
HDBaseT Contribution: Link Specification 2.0 Company Name: Valens
Semiconductor Valens Confidential
20
Usage of The Extended Control Info Token • While mapping a given
set of information bits into different s4d symbols with different
number of bits, represented per symbol (quantization per s4d
symbol), there may be a need to use MSB zero padding in order to
fit, the reminder of the information bits, into the last payload
token
• When a payload of a packet may dynamically change its modulation
it is important to mark, those MSB zero padding bits, to be able to
reconstruct correctly the information
• The Extended Control Info token mark these cases:
• Extended Info is marked, as Extended Control Info, by Info Code
(b5) equal 1
• b3:b2 are marking the number of MSB zero padding nibbles conveyed
in the last payload token. If Control Info token do not exists, no
padding is assumed
• Sync bit (b4), if set, is marking that the beginning of this
frame is a sync point for an HDBaseT NibbleStream
Sync Bad CRC
Upstream Fixed Packet FormatUpstream Fixed Packet Format
• Upstream packet composed of 46 tokens (@ 25Mtokens/sec):
– Header (TokHdB)
– CRC (TokCrcB)
– IDLE (TokIdlB)
– Other Subpackets:
• Subheader : 5 bit type, 3 bit length (can be extended) modulated
using PAM8B
• Payload: 8 or 12 bit tokens according to type modulated using
PAM8B or PAM16B
– IDLE Subheader tokens are fillers
– Example:
21
Upstream Packet HeaderUpstream Packet Header
Field Value
Description Remarks
0 Training The rest of the Tokens are Idle tokens (TokIdlB)
containing the scrambler's content
1 Ethernet Full 3x65 bits over 17 tokens, followed by extra
payload
2 Ethernet Partial 2x65 bits over 11 tokens, followed by extra
payload
3 No Ethernet First token will be a sub packet header
4-13 TBD
14 P2P Proprietary Vendor specific for point to point
applications
15 IDLE The rest of the Tokens are Idle tokens (TokIdlB) containing
the scrambler's content
22
Upstream Sub Packet HeaderUpstream Sub Packet Header
23
Sub header divided into: • Extension bit – Used to extend the sub
header • Subtype – specifies sub packet type
– Subtype codes are the same as the downstream packet type codes –
Some, downstream only, packet type codes, are used for special
purposes over
the upstream sub link
• Length+1 = #payload tokens (not including Sub header and SID
where applicable)
HDBaseT Contribution: Link Specification 2.0 Company Name: Valens
Semiconductor
Spec 2.0 Upstream SubtypesSpec 2.0 Upstream Subtypes
Subtype Description Priority Upstream Modulation
Remarks
0 HLIC 2.5 PAM8B Followed by message (8 bit tokens)
1 Ethernet N/A PAM16B Followed by Ethernet Data (12 bit
tokens)
2 Clock 2.5 PAM8B Followed by SID, clock type (1 token), clock
(8bit tokens)
3 HDMI Controls 3 PAM8B Followed by SID, message
(8-bit-tokens)
4 Extended ID 00 Ext = 1 (Ext = 0 Undefined)
5 Extended ID 01 Ext = 1 (Ext = 0 Undefined)
6 Extended ID 10 Ext = 1 (Ext = 0 Undefined)
7 Extended ID 11 Ext = 1 (Ext = 0 Undefined)
8 Retransmission 2.5 PAM8B Followed by retransmission PIDs
9 Reserved 3 PAM8B for future US only subtypes
10 USB 1 PAM16B Followed by SID, message (12 bit-tokens)
11 S/PDIF 2 PAM16B Followed by SID, message (12 bit tokens)
12 CIR/UART 3 PAM8B Followed by SID, message (8-bit-tokens)
13 Reserved 2 PAM16B for future US/DS subtypes
14 Reserved for DS for future DS only types
15 IDLE (Ext=0) Ext. Length (Ext=1)
Length field indicates DS link quality
24
HDBaseT Contribution: Link Specification 2.0 Company Name: Valens
Semiconductor
Future Upstream Subtypes (Spec 3.0 and on) will Future Upstream
Subtypes (Spec 3.0 and on) will use the Optional Extended Subtype
Tokenuse the Optional Extended Subtype Token
25
Asserting the extension bit together with subtype value of 4-7,
Followed by an extended subtype token, is the method used to
transmit future subtypes:
The extended subtype token defines subtype behavior on both US and
DS link hops:
•Extension bit – can be used for additional subtype information
•Bad CRC – Asserted if subpacket was subjected to CRC error
somewhere along the network same as DS and also propagated to/from
DS links
•Quality – same codes as DS Transfer-Quality defines subpacket
payload modulation: – 1,2 – PAM16B – 3 – PAM8B
•Priority – same codes as DS Scheduling-Priority defines the sub
packet priority
•{ID3,ID2,ID1,ID0} – provides up to 16 future types for each
quality and priority combination same codes as for DS
HDBaseT Contribution: Link Specification 2.0 Company Name: Valens
Semiconductor 26
Clock Measurement Service
• In mesochronous applications such as video the target T-Client is
require to regenerate the App Clock as was present in the source
T-Client
• The source T-Client measures the App Clock with its own reference
clock and send 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 and the
downstream receiver (and the upstream transmitter) “lock” on their
“master” clock
• When a packet propagate to the next hop on its network path its
transmitting symbol rate is retimed according to the master clock
of this next hop
• On this special packet type the T-Switch “correct” 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-Client if the packet reaches its target)
HDBaseT Contribution: Link Specification 2.0 Company Name: Valens
Semiconductor Valens Confidential
27
Propagation of Bad CRC Notification
• T-Packets 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 theses 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-Client 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 important such
as the amount of data transferred or extended info within the
header carrying sync points or other controls and for other
applications, such as video, even the payload data is useful
(assuming only few payload symbols are erroneous)
HDBaseT Contribution: Link Specification 2.0 Company Name: Valens
Semiconductor 28
Downstream Bad CRC Indication Bit
• The Bad CRC indication bit is located at the first extended token
within the packet header. The lack of extended token is also
marking “good” packet
• For Spec 1.0 and Spec 2.0 packet types:
• For future packet types:
Upstream Extended Subtype InfoUpstream Extended Subtype Info
29
Asserting the extension bit with subtype other than 4-7 (or in an
extended subtype token), followed by an extended subtype info
token, is used to provide additional info to the subtype, format is
the same as in DS:
•Extension bit – can be used for additional subtype information
•Bad CRC - Asserted if subpacket was subjected to CRC error
somewhere along the network •Info Code –
– 0 – Specific use per type. Meaning is according to the packet
type, switching devices just pass through
– 1 – Control info
HDBaseT Contribution: Link Specification 2.0 Company Name: Valens
Semiconductor 30
HDBaseT Nibble Streams • In order to facilitate packet
synchronization and to reduce framing overhead, the HDBaseT
upstream link operates using fix size packets which carries 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 its unused symbols slots
• An upstream transmitter should be able to split and merge sub
packets, of the same sub type and stream ID, according to the
upstream packet utilization
• HDBaseT NibbleStream is a general service which the T-Network
provides enabling a T-Client 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 packets payloads, carrying
NibbleStrems data, going into or out from the upstream links on
their network path
• The T-Network commits to reconstruct the original sequence of
nibbles, including its sync points, in their exact location, at the
target T-Client
HDBaseT Contribution: Link Specification 2.0 Company Name: Valens
Semiconductor 31
NibbleStreams Sync Points • All upstreams with data types of
priority codes 1 and 2 should support HDBaseT NibbleStream and
assumes that, along the upstream path to their destination, their
original sub packets payload may be split and/or merge
• Streams which allows mix 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 uses NibbleStream shall use the Extended Control
Info token in some DS packets / US sub packet headers, to mark Sync
Points
• The frequency of transmitting Sync Points, is data type depended,
preferably scarce, and their location is preserve across all splits
and merges
• If a packet / sub packet is marked as a Sync Point its payload
can not be merged with a previous packet’s payload and the Sync
Point is at the beginning of the data conveyed in this packet’s
payload
Sync Bad CRC
HDBaseT Contribution: Link Specification 2.0 Company Name: Valens
Semiconductor 32
NibbleStreams Users • For HDBaseT Ver 2.0 the only NibbleStream
users are USB and S/PDIF
• They will use NibbleStreams on all kinds of network paths: pure
DS, pure US and mix path
• NibbleStream payload split and merge is not supported over pure
DS paths such packets will travel intact all the way to their
destination end node
• Future data types may use NibbleStreams using the same
mechanism
HDBaseT Contribution: Link Specification 2.0 Company Name: Valens
Semiconductor 33
• HDBaseT Port Device may be of the following types:
– Fixed A-Symmetric : port device is a downstream input or
downstream output
– Bi-Functional A-Symmetric: same port device 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 configure and/or
resolved according to the link partner
– Symmetric: same port device can function as a downstream (high
throughput) input and as a downstream (high throughput) output at
the same time
• Bi-Functional ports must interoperate with Fixed A-Symmetric
ports and Symmetric ports must interoperate with Bi-Functional and
Fixed A-Symmetric ports
• All port devices must interoperate with Spec 1.0 Fixed
A-Symmetric port devices
HDBaseT Port Device Directionality
HDBaseT Contribution: Link Specification 2.0 Company Name: Valens
Semiconductor 34
• Each HDBaseT port shall first create a connection with its link
partner using HDSBI Info frames as part of LPPF #1 or #2 operation
modes
• Then the port exchanges more HLIC transactions to understand the
abilities of its link partner and to report its own
capabilities
• The port now can set its active functional mode and reports its
capabilities and current active mode to the Control Point
– Fixed AS to Fixed AS will be resolve to Fixed AS
– Bi-Func/Symm to Fixed AS will be resolve to Fixed AS
– Symm to Symm will be resolve to Symm
– Bi-Func/Symm to Bi-Func is the only non-trivial scenario and will
be resolve according to switch/devices preferences. The control
Point / switch may dynamically change the directionality of the
port if require and possible
Resolving Port Device Directionality
Local Retransmission Mechanism
Packet Retransmission Changes to the Packet Format
Packet Type and RTS Header Tokens
HDBaseT T-Network Services
Quality and Priority
Transfer-Quality Codes
Scheduling-Priority Codes
Current Packet Types (Spec 1.0 and Spec 2.0) Pre Defined Quality
and Priority Codes
Quality and Priority Data Types Plain
Future Packet Types (Spec 3.0 and on) Will Use the Optional
Extended Type Token
Spec 2.0 Dynamic S4D Modulation per Transfer-Quality and HDBaseT
Link Quality
Usage of The Extended Control Info Token
Upstream Fixed Packet Format
Upstream Sub Packet Header
Spec 2.0 Upstream Subtypes
Future Upstream Subtypes (Spec 3.0 and on) will use the Optional
Extended Subtype Token
Clock Measurement Service
Upstream Extended Subtype Info