Welcome 

We are very excited to announce this release of the XRA-31!

This is the first release with official Python API/CLI support.
Moreover, the system now supports up to two OFDMA channels.
Faster and more scalable OFDMA locking (with up to hundreds of online CMs) is another notable enhancement.

Furthermore this release has several new enhancements and fixes.

Check out the details below.

New since 4.0!

• API

  • Control the XRA-31 via Python API or CLI commands.
  • Installation is as easy as running pip3 install excentis-xra31.
    
  • Check out https://api.xra31.com for more information.

• OFDMA

  • Up to 2 channels.
    
  • Faster and more scalable locking (with up to hundreds of online CMs).
    

Changelog 4.0-1608 (2020-03-09) 

Enhancements 

• [Firmware] Improved sensitivity of A-TDMA initial ranging burst detector.
• [System] Faster and more scalable (up to hundreds of online CMs) OFDMA locking.
• [System] Reported OFDM(A) channel spectral edges are now devoid of guard bands.
• [System] Support for mounting and accessing removable media via the local file manager.
• [System] Login screen and desktop now have custom XRA-31 background.
• [GUI] Added capabilities section to system page that includes the number of supported channels for each channel type.
• [GUI] Improved look-and-feel of notifications.
• [GUI] Clearer and more detailed channel status messages.
• [GUI] Improved responsivity of "select all" on capture page.
• [GUI] Improved layout of help page.
• [GUI] Improved error handling.
• [Wireshark] Added PLC frequency to all OFDM packet headers (including PLC/NCP).
• [Wireshark] Upgraded on-system version to Wireshark^® 3.0.3-excentis4.

Fixes

• [Firmware] Fixed bug that caused high internal packet loss of a reference SC-QAM channel under certain circumstances, leading to very poor upstream demodulation performance. 
• [Firmware] Fixed unstable automatic gain control for low PAPR (peak to average power ratio) downstream connector input signals (e.g. one single SC-QAM channel), hampering downstream channel locking steps. 
• [Firmware] Fixed bugs in OFDMA frame builder that caused data loss under rare circumstances. 
• [Firmware] Fixed bug where all shortened OFDMA codewords with number of info bits equal to a one plus a multiple of the check matrix lifting factor are dropped. 
• [Firmware] Fixed bugs in OFDMA LDPC decoder that led to decreased error correction performance.
• [System] Fixed bug where OFDMA channel fails to lock after changing upstream channel ID. 
• [System] Fixed incorrect reported time adjust of OFDMA intial and fine  ranging messages if exclusion bands are presents between minislots. 
• [System] Fixed bug in OFDMA initial ranging detector that caused data loss. 
• [System] Fixed initial packet loss on locked OFDMA and A-TDMA channels after a system restart. 
• [System] Fixed bug where timestamps of OFDMA packets are incorrect up to one OFDMA frame duration under certain circumstances. 
• [System] Fixed incorrect upstream packet timestamps around UCD changes under certain circumstances. 
• [System] The system no longer accepts file or directory names longer than 255 characters, which prevents failed captures. 
• [System] Fixed bug in Wicd Network Manager that caused static IP address connection failures.
• [GUI] Also show "folder-up" icon in empty directory. 
• [GUI] Fixed select all icon in case some items are selected (on capture page). 
• [GUI] Fixed several issues related to support archive creation.
• [GUI] Fixed issue with refresh button.

Features 

OFDM

• Real-time demodulation and decoding 
• Full line rate
• All FFT sizes, cyclic prefixes and roll-off periods defined by [CM-SP-PHYv3.1] 
• Data demodulation and decoding 
  • All interleaver settings defined by [CM-SP-PHYv3.1] 
  • All modulations from zero-bit-loading up to 4096-QAM defined by [CM-SP-PHYv3.1] 
  • All possible configurations of exclusion bands defined by [CM-SP-PHYv3.1] 
  • Multiple concurrent data profiles (from A up to P) 
  • Mixed-modulation profiles 
  • Dynamic data profile changes 
  • Timestamp precision of DOCSIS frames is equal to one OFDM symbol (between 21 and 45 microseconds depending on FFT size and cyclic prefix) 
• PLC and NCP demodulation and decoding 
  • Including MER statistics 
  • Timestamp precision is on the order of a few nanoseconds 

OFDMA

• Real-time demodulation and decoding 
• Full line rate
• All FFT sizes, cyclic prefixes and roll-off periods defined by [CM-SP-PHYv3.1] 
• Dynamic UCD changes (including data profile IUC changes) 
• Data demodulation and decoding 
  • All interleaver settings defined by [CM-SP-PHYv3.1] 
  • All modulations from zero-valued up to 4096-QAM defined by [CM-SP-PHYv3.1] 
  • All possible configurations of exclusion bands and unused sub-carriers defined by [CM-SP-PHYv3.1] 
  • All data profile IUCs defined by [CM-SP-MULPIv3.1] concurrently 
  • Supported pilot patterns: 1-4, 8-11 
  • Timestamp precision of DOCSIS frames is equal to one OFDMA frame (between 126 and 1665 microseconds depending on OFDMA frame size, cyclic prefix and FFT size) 
• Real-time full line rate bandwidth request (REQ) message demodulation and decoding 
  • Timestamp precision is on the order of a few nanoseconds 
• Initial Ranging and Fine Ranging demodulation and decoding 
  • Including MER statistics and time offset estimations 
  • Timestamp precision is on the order of a few nanoseconds

Downstream SC-QAM 

• Real-time demodulation and decoding 
• Full line rate
• Hardware timestamping of packets using reference channel clock (nanosecond resolution) 
• 64/256-QAM, independently configurable per channel 
• Dynamically configurable annex 
  • Annex A (EuroDOCSIS)  
  • Annex B (US DOCSIS)  
    • All interleaving parameters (control words) defined in [ITU-T Rec. J.83] supported 
    • Viterbi decoding for increased reliability. 
• Extended downstream frequency range support 
  • Channel frequencies can be any multiple of 62.5 kHz between 108 and 1006 MHz, complying with all CM requirements in [CM-SP-PHYv3.1]. 
• Two independent 248 MHz wide receive modules 
  • All channel frequency configurations that can be grouped into the two receive module bands are valid, e.g. a channel configuration consisting of three channels at 200 MHz, 440 MHz and 1000 MHz is valid, but a configuration with frequencies 200 MHz, 600 MHz and 1000 MHz is not. 
• Data MER and Reed-Solomon decoder statistics 
• Timestamp precision of DOCSIS frames is equal to one MPEG frame (between 29 and 56 microseconds depending on annex and modulation)

A-TDMA 

• Real-time demodulation and decoding 
• Full line rate
• Full A-TDMA UCD type 29 and 35 support (with the sole exceptions of differential encoding, zero-length preambles and IUC 2 Request_2 demodulation). 
  • All channel bandwidths (from 200 kHz to 6.4 MHz) defined in [CM-SP-PHYv3.0] 
  • All upstream center frequencies allowed by [CM-SP-PHYv3.0] 
  • All modulation types (from QPSK to 64-QAM) defined in [CM-SP-PHYv3.0] 
  • All preamble patterns, types (QPSK0/QSPK1) and lengths from 2 to 1536 bits defined in [CM-SP-PHYv3.0] (Hence, the minimum allowed preamble length is one QPSK symbol) 
  • Scrambler on/off 
  • Fixed/shortened last codeword 
  • All interleaving parameters allowed by [CM-SP-PHYv3.0] 
  • All Reed-Solomon FEC parameters allowed by [CM-SP-PHYv3.0] 
  • Supported IUCs: 1 (Request), 3 (Initial Maintenance), 4 (Station Maintenance), 5 (Short Data Grant), 6 (Long Data Grant), 9 (Advanced PHY Short Data Grant), 10 (Long PHY Short Data Grant), 11 (Advanced PHY Unsollicited Grant) 
  • Dynamic UCD changes 
• Detailed statistics per demodulated burst 
  • Data MER 
  • Time offset 
  • Reed-Solomon decoder statistics 
  • Start minislot ID
    

References 

• [CM-SP-PHYv3.0] DOCSIS^® 3.0 Physical Layer Specification (December 2017, http://www.cablelabs.com/specs/) 
• [CM-SP-PHYv3.1] DOCSIS^® 3.1 Physical Layer Specification (September 2019, http://www.cablelabs.com/specs/) 
• [CM-SP-MULPIv3.1] DOCSIS^® 3.1 MAC and Upper Layer Protocols Interface Specification (September 2019, http://www.cablelabs.com/specs/) 
• [ITU-T Rec J.83] ITU-T J.83: Digital multi-programme systems for television, sound and data services for cable distribution  (December 2007, Telecommunication Standardization Sector of ITU)
  

Known limitations

Firmware

• OFDM

  • Possible temporary data loss during dynamic NCP updates
  • Zero-bit-loading of NCP subcarriers not supported
  • No data MER statistics

• OFDMA

  • Unsupported pilot patterns: 5-7, 12-14
  • No probing sequences
  • No data MER statistics

• A-TDMA

  • UCD type 2 (DOCSIS 1.x PHY channel and mixed DOCSIS 1.x/2.0 TDMA PHY channel) channels not supported
  • Differential encoding not supported
  • Zero preamble length not supported
  • IUC 2 (Request_2) not supported

Environment and system tools

• xra31-admin: It is not possible to follow the system/service logs

Analysis

• Captured packets are not ordered by timestamp

Known Issues

Firmware

• General

  • After a system (re)boot, e.g. as part of a system update, it's possible that the inter-FPGA serial links are stuck in a non-operational state. This is signaled in the GUI by error messages on connector US-1. We have taken several measures to improve resilience against this behavior, but are still working on a more pertinent solution. In the meantime, please reset the system via the GUI system page until the serial links are fully operational.

• OFDM

  • The first channel locking step after a system reset or a CMTS change can take considerably longer than subsequent locking steps. This is because internal frequency offset has to be reliably estimated (after which it is cached).
    
    This effect is considerable on small-bandwidth OFDM channels. Depending on PLC frequency and FFT size, initial locking of a 24 MHz channel (the minimum allowed per [CM-SP-PHYv3.1]) can take up to 10 minutes. Subsequent re-locking steps, even on different channels, should be on the order of seconds. A workaround is to first 'pre-lock' the XRA-31 on a dummy 192 MHz channel (which should take no longer than 1 minute), remove this channel and re-add the 24 MHz channel.

System and services

• The reported upstream channel MER is the average over all fine ranging requests (for OFDMA) or all data bursts excluding initial ranging requests and bandwidth requests (for A-TDMA) over an elapsed interval of at most 30s. As such, it is possible that N/A (not available) is shown on low-load channels with T4 timeout multiplier higher than 1.
• Captured Wireshark traces might contain invalid (malformed) packets corresponding to collisions (or possible RF interference) on A-TDMA IUC 1 (bandwidth request) grants. In a future release we plan to filter out these spurious bursts.
• Inverse upstream Concatenation and Fragmentation (ICCF) of "segment header on" service flows is now performed for each channel independently. Hence, for CMs in MTCM (multi transmit channel mode), MAC frames that are fragmented over multiple upstream channels are not detected and consequently absent in the Wireshark trace. A future release will support ICCF over multiple channels.