Nokia DSLAMs are used by Covad and hence the Nokia flavor of SDSL is a very important one to support. Their proprietary ATM-based SDSL/2B1Q flavor has been shrouded in mystery for a very long time, but we have finally cracked it and implemented 100% open source connectivity to Nokia SDSL on our Hack-o-Rocket IP router.

Nokia's is a flavor of SDSL/ATM (i.e., ATM cells to the subscriber), but it is not Flavor A. Instead the cells are packed into a frame structure and frame delineation replaces cell delineation. Each Nokia frame is 432 octets long and can be viewed as consisting of 8 octets of frame header followed by 8 ATM cells (53*8 + 8 = 432). (Another view is that 8 extra octets are inserted after every 8 ATM cells.) Since each frame carries a whole number of ATM cells, no further effort is needed to delineate the cells within the frame. I.432.1 cell delineation is thus eliminated and the HEC octet needs to be checked only to decide whether or not to trust each given cell's header, but not for delineation.

Although the Nokia flavor effectively implements a framer, it is not a traditional framer like those used in ISDN and HDSL. The Nokia framer does not operate on a raw quat stream and take up responsibility for selectively scrambling it and turning it into a bit stream, instead it is implemented on the bit stream after it has already been made user-friendly by the bitpump's internal scrambler/descrambler and serial channel unit interface. Thus the way the bitpump is configured for the Nokia flavor is essentially the same as how it's configured for Flavors A and B, not the way it would be configured for HDSL with a traditional framer.

The Nokia flavor uses the bitpump's internal scrambler and the internal startup sequence source, tip/ring reversal is handled the same way as in Flavors A and B, and the activation state machine (ASM) is the same as in Flavor A except that Nokia frame delineation status replaces cell delineation status.

Nokia frame format

The most neutral view of the bit stream format on a Nokia SDSL line is that it consists of ATM cells like in Flavor A, but with an extra sequence of 8 octets interspersed after every 8 cells.

What are these 8 extra octets? For a few months in late 2007 we have held an incorrect view of their purpose based only on experiments with Nokia-flavored CPE (no real Covad line was available), but subsequent experience on real Covad lines has given us a better view. It now appears that the Nokia frame is best viewed as having the following format:

  1 octet:  constant value E4, apparently serves as the sync word
424 octets: 8 ATM cells
  1 octet:  appears to be unused, always seen as 00
  1 octet:  embedded operation channel (EOC)
  4 octets: appears to be unused, always seen as 00
  1 octet:  frame CRC-6 and flags of some kind
----------------------------------------------
432 octets total

The only non-constant octets that aren't part of the ATM cells are the EOC (described in its own section below) and the frame CRC-6.

The frame CRC-6 is analoguous to the corresponding feature in the HDSL frame structure. It is in fact CRC-6 just like in HDSL, using the same polynomial (000011 in practical implementation), and it's computed as follows. CRC-6 computation begins with the first cell header octet of the first ATM cell of the frame with the accumulator register initialized to all zeros and covers the subsequent 430 frame octets without regard as to whether they are cell headers, HEC, payload or Nokia frame trailer octets. The computed CRC-6 is then emitted in the final octet of the frame, MSB first. Thus the only octets in the entire Nokia frame which aren't covered by the CRC-6 are the E4 octet (presumed sync word) and the CRC-6 octet itself.

But wait, CRC-6 is 6 bits and the octet it goes into has 8 bits total. What about the remaining two bits? CRC-6 is placed in the 6 most significant bits and the 2 least significant bits appear to be flags of some kind. They've been observed to be almost always zero. The presumed flag bits are not covered by the frame CRC-6.

Note that this frame level CRC-6 is somewhat of a frill just like in HDSL: as in standard ATM each cell's header is still protected by the standard CRC-8 and AAL5 payload is protected by the standard CRC-32. Just like the similar feature in the traditional telecom frame structures, the frame level CRC-6 is primarily useful to those who want to assess the quality of the link without interpreting the payload data.

An SDSL/ATM terminal which terminates AAL5 doesn't really need any additional integrity check beyond the standard cell header and AAL5 CRC, and indeed it would probably be better to heed the wise word of the ATM standards and rely solely on those standard checks. The Rx frame level CRC-6 can thus be ignored, conveniently saving the computational burden.

The Tx direction is more of a concern though: we could in theory put a dummy value in the CRC-6 field of our outgoing frames to save ourselves the computational burden, but how will the DSLAM react? Will it tear the link down on the assumption that it's completely no good, or will it just flag the condition somewhere to the bewilderment of Covad's NOC people but allow cells to pass between the line and the backhaul? Anyone who is curious is welcome to test it by taking our Hack-o-Rocket which now works with Nokia/Covad SDSL and making it transmit deliberately wrong CRC-6.

It's probably better to compute the correct CRC-6 in any case though.

Quat orientation and alignment

The quat orientation in the Nokia flavor is sign bit first.

Given that each Nokia frame consists of a whole number of octets and hence a whole number of quats, it would be neater for frames to have natural quat alignment. But is it required?

In one of our experiments on a real Covad line we have deliberately transmitted both naturally aligned and misaligned frames, and in both cases the DSLAM seemed satisfied with what we were sending as it didn't seem to tear the link down as it does when the bitpump activation is successful, but no Nokia frames are coming. Thus it appears that the DSLAM doesn't care about quat alignment in the bit stream transmitted by the CPE. However, Netopia's implementation appears to always transmit naturally aligned frames, and doing so is probably better for purely aesthetic purposes.

What about the bit stream from the DSLAM to the CPE? Interestingly enough, the one time we did an EXSYN capture in that last experiment on a real Covad line, the bit stream we've captured showed misaligned frames, i.e., the frame boundary fell in the middle of a quat! Tsk tsk tsk. In any case the frame receiver should acquire frame sync bit by bit and not care about QCLK.

Nokia EOC

EOC stands for embedded operation channel, a feature commonly provided by telecom framers. It's a very narrowband channel which carries segment-level operation & maintenance messages between Layer 1 terminals and which is embedded into the frame structure along with the payload data. Nokia EOC is alluded to in the CPE configuration menus and our recent experiments have finally revealed its exact location in the Nokia SDSL frame structure.

The first thing which needs to be noted is that the EOC setting in the mainstream CPE configuration menus does not necessarily indicate whether or not EOC is actually present in the bit stream on the line. For example, the Nokia model of the Inefficient Networks 5851 router has a Nokia EOC setting which can be enabled or disabled. Covad-configured units have it set to disabled; turning it on causes the line to stop working. This observation has led us to believe earlier that Covad lines have no EOC. However, when we have finally connected our Hack-o-Rocket to a working Covad line, we have observed that the frames transmitted by Covad's DSLAM do carry some EOC messages.

It is thus best to interpret the Nokia EOC setting in the mainstream CPE configuration menus as really selecting a subflavor of Nokia; see the subflavors section below. Flavor N2 appears to have EOC as one of its essential features, but in Flavor N1 (the simpler one served by Covad) it appears that it would be acceptable to ignore incoming EOC messages and to transmit constant FF in the EOC octet in the outgoing frames. This is what both Netopia and EN routers appear to do when configured for Flavor N1; this is also what our Hack-o-Rocket IP router does currently and it works fine for us.

What do the EOC messages look like? It appears that they are transmitted in a form of octet-oriented HDLC (see RFC 1662). I say so because they are carried in a single octet in the Nokia frame, and this octet is set to 7E when the EOC is idle. Here are a couple of EOC messages (strings of non-7E octets) we have captured with our Hack-o-Rocket on two different Covad lines:

FF 03 AA AA 03 00 60 F9 00 01 0C 00 01 03 03 D3 02 00 FF FF 00 02 90 68

FF 03 AA AA 03 00 60 F9 00 01 0C 00 01 03 02 CF 02 00 FF FF 00 02 7C ED

The initial FF 03 octets are just like in PPP, AA AA 03 is an LLC header, and 00 60 F9 is the OUI assigned to none other than Diamond Lane, the original creators of the D50 DSLAM which has later become Nokia. The last two octets of each of the two messages above form a correct 16-bit FCS for the message, computed exactly like in RFC 1662.

We thus know the format of the Nokia EOC messages, but not their meaning. Once again, we currently ignore all incoming ones and transmit a constant FF in the EOC octet of our outgoing frames, and it works for us.

Nokia Fixed vs. Nokia EOC

There actually are two different flavors of Nokia SDSL/2B1Q which we have codenamed Flavor N1 and Flavor N2. Netopia calls them Nokia Fixed and Nokia EOC Fast, respectively; the Nokia model of Inefficient Networks 5851 calls them EOC disabled and EOC enabled, respectively.

Flavor N1

In Flavor N1 the data rate is fixed and there is no pre-activation signaling on the line. The framing format is thus the only special quirk we need to be concerned with in this flavor. The classic Flavor N1 data rates are 192, 384, 768, 1152 and 1536 kbps; 2320 kbps may have later joined the ranks as well. (These are the data rates presented to the user in CPE configuration menus and are also the actual bitpump data rates.) Standard Flavor N1 CPE supports speed autodetection by trying all data rates in this restricted set by brute force.

Flavor N1 is the one we are most familiar and concerned with. Covad SDSL circuits in our little town are Flavor N1 and we assume that all Covad lines are probably the same.

Flavor N2

We can't tell much about Flavor N2 because we've never had a Flavor N2 line anywhere and have never seen any equipment that can act as a Flavor N2 HTU-C. Thus all we know about Flavor N2 is how Netopia R7200 and Inefficient Networks 5851 act when configured for this flavor.

On both CPE devices whenever the Nokia EOC mode is selected, no speed selection is presented to the user whatsoever, just like Copper Mountain. We can thus conclude that a key feature of Flavor N2 is some mechanism for automatic data rate configuration. But how does it work?

In physical terms, when the Nokia EOC mode is selected, both CPE devices initiate HTU-R startup at 192 kbps (96 kbaud symbol rate). This fact has been confirmed by observing a 96 kHz clock on the QCLK pin of the RS8973 chip with an oscilloscope, and one can even see messages on the console to that effect. It needs to be noted though that this experiment which observes only an HTU-R device, without a Flavor N2 HTU-C, is seriously incomplete. We don't know if it would really start up at 192 kbps when connected to a real Nokia DSLAM serving Flavor N2 — perhaps the real Flavor N2 HTU-C sends Autobaud or other pre-activation signals on the line and perhaps the 192 kbps HTU-R startup is only the fallback for when no such pre-activation signals are heard.

Yet they call Flavor N2 Nokia EOC, not Nokia Autobaud. Perhaps they don't use Autobaud after all. Perhaps they always do a startup at 192 kbps first, then use the EOC to communicate the real data rate, then tear the 192 kbps link down and re-establish it at the new data rate.

We have performed an experiment in which we've made our Hack-o-Rocket run as an HTU-C at 192 kbps, and we've connected it to our Netopia R7200 configured for Flavor N2. A successful startup was achieved, and familiar Nokia frames started pouring out of the bitpump. The only difference between these frames and those transmitted by the same unit in Flavor N1 is that the EOC octet was set to 7E in Flavor N2 and to FF in Flavor N1. We've made the Bt8970 on our Hack-o-Rocket loop the received and descrambled symbols back to the transmit scrambler, and the R7200 has declared the link up at 192 kbps — evidently getting its own frames back made it happy enough.

We can't find out anything more substantial about Flavor N2 without a Flavor N2 line, but then if Covad only serves Flavor N1, why care about Flavor N2 at all?