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 had been shrouded in mystery for a while, but we have successfully cracked it and implemented 100% open source connectivity to Nokia SDSL on our Hack-o-Rocket and OSDCU platforms.

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 analogous 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 still 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 experiments in 2007/2008 have 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 had 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 and OSDCU implementations do currently and it works fine for us.

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

Nokia SDSL data rates

The standard data rates for the Nokia flavor are 192, 384, 768, 1152 and 1536 kbps; 2320 kbps may be considered to have joined the ranks as well, see below. These are the data rates presented to the user in CPE configuration menus and are also the actual bitpump data rates.

More precisely, there are two different SDSL line cards that may be installed in a Nokia D50 system: the older Bt8970-based SDSL8 and the newer RS8973-based SDSL8+. The older Bt8970 bitpump uses external data rate switching circuitry, hence the selection of available data rates is fixed in hardware. On the SDSL8 card this set consists of the 5 classic Nokia speeds: 192, 384, 768, 1152 and 1536 kbps. With the newer RS8973 bitpump the hardware is capable of putting out any data rate from 144 to 2320 kbps in 8 kbps increments. What is less clear is how well this flexibility is handled in the DSLAM software/firmware: it is certain that the cool 2320 kbps data rate had full official blessing and support, but what about the intermediate speeds? This last question ties in with the subflavors: see below.

Subflavors and DSLAM versions

There exist 3 different subflavors of Nokia SDSL to our knowledge, depending on the software version installed on the serving D50 system; we have codenamed them N1, N2 and N3. The differences have to do with how the data rate in effect on a given line is to be communicated to the CPE.

Implementation

The most conceptually-straightforward way to implement Nokia SDSL/ATM in a CPE device would probably be to implement a framer in an FPGA that turns the Nokia-formatted bit stream into UTOPIA, then use an off-the-shelf ATM SAR device, either the stand-alone variety (PCI or somesuch) or a PowerQUICC processor with an ATM SAR block. However, although this approach is indeed the most conceptually straightforward, it does not necessarily follow that it is the most efficient, most economical or most convenient: it may or may not be.

One alternative approach with which we have had mixed success is to use an SCC core in a Motorola/Freescale telecom processor in the transparent mode to receive and transmit Nokia's 432-octet frames, and then have software do the rest of the work. (This approach is viable because there is no cell payload scrambling or other bit-level processing, and everything falls on octet boundaries.) We currently do this with MC68x302 processors on our Hack-o-Rocket and OSDCU platforms, and in the case of the OSDCU running at 25 MHz we can keep up with 384 kbps in both directions.

This all-software approach seems to be a dead end with MC68x302 processors: our experiments suggest that it wouldn't be able to handle 1536 kbps even using the fastest 33 MHz speed grade parts. However, it is entirely possible that this approach would become quite viable on a much faster PowerQUICC processor like MPC866: it is something that would be worth trying in the HECGW project.

In the meantime, given our natural desire to squeeze the most out of our already-built OSDCU platform, we are experimenting with a hybrid approach in which the SDSL Rx direction would still be handled by the MC68302's SCC1 core, but the Altera EPF10K30ATC144 FPGA on the OSDCU board would handle the Tx direction instead. The overall approach is still ad hoc software-dominant, but the FPGA-based Nokia frame transmitter computes all CRCs in real time, relieving the CPU of that burden, and we are hoping to have a more favorable interrupt priority nesting structure. It is currently in the process of being implemented, and will be tested soon.

For what it's worth, the implementation on the DSLAM side is strictly FPGA-based, but so is that DSLAM's entire ATM data path, not just the SDSL part, so it doesn't say much.