xDSL handshake

The ITU-T has standardized a handshake and activation method for xDSL modems, called the g994.1 aka G.Hs.  Its basic function to provide a consistent way of initiating the various types of xDSL modems available now and in the future.

Before g994.1 each of the various xDSL standards used different tones or signals at different frequencies in order to indicate to the opposite end that modem startup (activation) was desired. Additionally, various modem options were negotiated by using different combinations of tones.   This clearly became a problem as xDSL evolved, expanding the number of options and flooding the market with many types of xDSL modems, so that unused frequency spectrum became a valuable resource in order to identify initialization at each end of the line.

A similar situation happened in the early 1990's when voiceband modems were in use, and each often contained several different voiceband modulation Recommendations (V.22, V.32, V.34).  Instead of using different tones and frequencies, a protocol named V.8 was created, in which a simple digital communication path is created between the 2 end-points, followed by a process of messages transfer in order to identify and select both the appropriate modulation technique used, and the available options.

g994.1 borrows the basic idea behind V.8 and does basically the same for xDSL modems, only it uses somewhat a bit more complicated communication set-up and messaging mechanism due to the extensive nature of xDSL.

Spectrum Allocation
V.8 used two different frequency bands for the digital communication path. Data was transferred in one direction in a spectrum band centered around 1080 Hz and in the other direction in a spectrum band centered around 1750 Hz. It was rather easy to select those frequencies since all voiceband communications occurred in the spectrum from 300 to 3700 Hz.
In xDSL however, the spectrum is not limited, and indeed each region in the world chose to use a different spectrum.  Moreover, DSL lines are exposed to interferences on certain frequencies making them unusable.  As a result, several simultaneous upstream and several simultaneous downstream frequencies were needed in order to initialize communication.  Different carrier sets were designed for different regions in the world, each carrier set contains 3 frequencies. a handshake procedure may start off with as many nine simultaneous upstream tones and ten simultaneous downstream tones. This allows for the greatest possibility of detection at the opposite end of the cooper loop.
As for ADSL, the 4.3125 kHz signaling family has been chosen, meaning signals frequencies retain value of N * 4.3125 kHz, where N is a positive integer.  Carrier sets are designated for 3 different types of ADSL, each correspond to a different region in the world using ADSL.  Figures are described in table 1 below.

Carrier Set
Designation
ADSL type Primary Region Upstream (maximum
power level of -1.65dbm)
Downstream (maximum
power level of -3.65dbm
)

Frequency Indices (N)

Frequency Indices(N)

A43

G.992.1 - Annex A,
G.992.2 Annex A/B

North America

9      17    25

40    56    64

B43

G.992.1 - Annex B

Europe

37    45    53

72    88    96

C43

G.992.1 - Annex C
G.992.2 - Annex C

Japan

7       9

12    14    64

Table 1. carrier sets corresponding to ADSL type

 

Duplexing and Initial Signals
As mentioned before,  either end of the copper loop may send the first signal of initialization,  and can operate both in duplex and half duplex, depending on the xDSL Recommendation.  We will focus on the duplex system, which is used by ADSL.  In any case, the first signals in all fourth methods are identical allowing complete interoperability between all four cases.
When an xTU-R/C wishes to initiate G.994.1, it delivers a request from the HSTU-R/C which begins the initialization procedure by sending several signals and flags to the other side, as described in figure1.

 

   

Figure 1. Initialization handshake procedure for duplex transmission.  Maximum delay between detection of one frame to sending a response must not exceed 500ms, otherwise a timeout has occurred and error recovery procedure begins (might initiate another g994.1 procedure).

When the initialization sequence has ended, i.e. the HSTU-R has detected the final flag signals, various information is exchanged between the HSTU-R and HSTU-C in the form of transactions (see below).

 

Messages
Information  between the HSTU-R and HSTU-C post initialization and communication channel set-up is exchanged through different messages.  A summarized list includes:

  • Different kinds of ACKs and NAKs
  • Mode Select (MS) - request for initiation of a particular mode of operation)
  • Mode request (MR) - sent by an HSTU-R. It requests the transmission of an MS message by the HSTU-C
  • Capabilities List /Capabilities List + Request (CL/CLR) - messages to transfer and request possible modes of operation of the xTU-R (CLR) or xTU-C(CL).
  • REQ-MR, REQ-CLR - different request messages for MR and CLR from the other end.

A message consists of one or more segments. Each segment is encapsulated in a frame.  The message and frame structure is similar to V.8bis.
Each frame has a variable length of octets, and shall begin and end with standard HDLC flag octets (01111110) as defined in ISO/IEC3309.  It also contains a 16 bit check field as defined according to that standard.


Figure 2. Frame structure

 

Each message consists 3 primary parts:

  1. Identification field (I) -used to identify the message.  Consisted out of four fields:
    • message type (as described above)
    • revision number - the revision number of g994.1 used by the end point equipment
    • vendor ID
    • Parameters field - misc parameters independent of the mode to be selected and are typically either service or application related.
  2. Standard Information field(S) - represent modes of working or capabilities relating to end point transmitters.  Each capability is assigned a positional bit, and when set to one means the capability is active.
  3. Non-standard Information field (NS) - this part is optional, and is valid only for MS, CL, and CLR messages (otherwise its length is zero).  When relevant,  the "Non-standard field" parameter shall be set to binary ONE in the identification field.  It contains some additional non-standard information.  The first octet of the non-standard information field shall indicate the number of non-standard information blocks to follow.


Figure 3. Message structure

Transactions

A sequence of G.994.1 messages, ending with either a positive acknowledgement (ACK), a negative acknowledgement (NAK), or a time-out.
There are two categories of transactions:

  • 3 Basic transactions - which exchange and negotiate capabilities between the HSTU-C and HSTU-R, and transactions which selects modes of operation.  An example of a basic transaction: the HSTU-R selects a mode of operation and sends an MS message asking the HSTU-C to do the same.  The later accepts the request and answers with an ACK.
  • 4 Extended transactions - these are in fact a concatenation of 2 basic transactions.  These are used to  revert control to the other end, or to request a capabilities exchange when a mode select (MS) was proposed.

 

Timing and Error recovery
as shown before on figure 1, the maximum delay time between reception of the end of any frame and the start of transmission of the next frame must not exceed 500ms.  If timeout occurs on any station, it will abort and return to its initial g994.1 state (meaning being silent and await communication).  It will stay in this state for at least 500ms.  This is also the case when receiving NAK-EF message (see next line).

If an invalid frame is received in any state, it shall be ignored, and a NAK-EF is sent to the other end-point.

 

Next: Testing and Managing xDSL

Back to rad university

www.rad.com