Welcome
We are very excited to announce the second major release of the XRA-31 system!
The system can now capture downstream SC-QAM (annex A/B, 64/256-QAM are supported, full spectrum).
This means you can capture up to 1 OFDM channel, 1 OFDMA channel and 24 downstream SC-QAM channels simultaneously and synchronously with nanosecond resolution, as all packets are hardware timestamped using the same reference OFDM channel clock!
Furthermore this release has several new features, improvements and bug fixes.
Check out the details below.
Features
-
New since 2.0!
-
Downstream SC-QAM
-
OFDMA bandwidth requests
- The system can now capture OFDMA bandwidth request (REQ) messages.
-
Revised capture filtering
- Capture Filtering has been revised to incorporate SC-QAM support
-
WebAdmin (GUI) re-design
- Updated Channel Configuration
- All Downstream Channels are now edited at once.
- All Upstream Channels are now edited at once.
- Updated Capture Configuration
- New Status Panel
- Collapsible panel
- Status icon and detail message box show more extended information on the status including suggestions for changes on physical setup.
- Physical Connector status information is now separated from the DOCSIS Channel status information.
- Ease-of-use
- Add "copy-down" and "copy-down with value increment"
- Sorting in all relevant table columns
- Context help is now always available via the help button in the navigation panel
-
OFDM
- Real-time demodulation and decoding
- Full line rate (up to approx. 2 Gbps per channel)
- Hardware timestamping of packets using channel clock (nanosecond resolution)
- 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 (up to approx. 1 Gbps per channel)
- Hardware timestamping of packets using reference OFDM channel clock (nanosecond resolution)
- 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 945 microseconds depending on OFDMA frame size)
- Real-time full line rate bandwidth request (REQ) message demodulation - NEW since v2.0!
- 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
-
SC-QAM
- Real-time demodulation and decoding
- Full line rate (up to approx. 1.2 Gbps combined)
- 24 independent channels supported
- Hardware timestamping of packets using reference OFDM 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)
References
- [CM-SP-PHYv3.1] DOCSIS 3.1 Physical Layer Specification (version I13 or any later version; http://www.cablelabs.com/specs/)
- [CM-SP-MULPIv3.1] DOCSIS 3.1 MAC and Upper Layer Protocols Interface Specification (version I14 or any later version; 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
- Limited to one supported channel receiver
- No dynamic NCP profile changes
- No data MER statistics
-
OFDMA
- Limited to one supported channel receiver
- Unsupported pilot patterns: 5-7, 12-14
- No probing sequences
- No data MER statistics
-
SC-QAM
- Limited to 24 supported channel receivers
Environment and system tools
xra31-admin: It is not possible to follow the system/service logs
Analysis
- Captured packets are not ordered by timestamp
Changelog 2.0.2-442 (2018-02-27)
Improvements
-
Firmware
- Improved resilience to known issue (described hereafter) where serial links are stuck in a non-operational state after a system (re)boot.
-
System and services
- Hardware self-test failure information is now available through the Connectors status in the WebAdmin GUI.
-
Wireshark
Bugfixes
-
Firmware
- Fixed bug where an OFDM channel is stuck in "PLC-only lock" if extended headers are present in PLC MC MMMs.
- Fixed bug where messages of low-bandwidth streams (such as OFDMA REQ messages on low-load channels) are not visible in the capture file by upper bounding the latency of the internal FPGA streams to a fraction of a second.
-
System and services
- Fixed bug where an encrypted REG-REQ-MP is dropped and not saved to the capture file.
- Fixed bug where OFDMA REQ messages are dropped in some cases.
- Fixed bug where, in some cases, the Annex is not set correctly in the XRA header.
- Fixed possible out-of-bounds memory access in MER calculation.
- Fixed race condition.
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.
-
SC-QAM
- MER can be significantly lower on annex A channels with low traffic load on some CMTSs. This is due to poor symbol scrambling (needed to maintain proper lock) caused by sub-optimal low-entropy payload sequences of null packets. A workaround is to generate some (possibly artificial) traffic on the affected channels.
-
System and services
- During the OFDMA locking phase, the XRA-31 estimates the optimal time and power offset for demodulation (comparable to the ranging process of a cable modem). After RF network changes, primary OFDM or OFDMA channel configuration changes, or due to drift over long time periods, these estimations can deviate considerably from their initial value, leading to demodulation failures for data bursts. In a future release, the XRA-31 will continuously track and update time and power offset after locking.
In the meantime, as a workaround for the above described cases, please remove and re-add the OFDMA channel to force a new locking phase. Note that you can keep track of the XRA-31 internal time offset by inspecting the Wireshark XRA header of the fine ranging signals.
- The system accepts file names longer than 255 characters and starts capturing, but storing the file fails in this case.
-
WebAdmin (GUI)
- Multi-user access shows incomplete or invalid status information.
- This is seen when connecting with multiple users (or browser tabs) to the WebAdmin.
- Also unexpected error messages may be shown.
- The XRA-31 Control Daemon exits when the FPGA firmware is not supported. The GUI has no way to properly show this state to the user and the user is just prompted with an error that connection to the XRA-31 server failed. This can happen for example when an update of the firmware failed. The user can detect this state by verifying that the firmware versions on the System page do not match.
- Layout on small displays can be improved.
Changelog 2.0-138 (2018-11-12)
Improvements
-
General
- Add downstream SC-QAM support
- Physical Connector status information is now separated from the DOCSIS Channel status information.
-
Firmware
-
OFDM
- Improved channel locking (between 2 and 30 times faster)
- Improved automatic gain control
- Optimized digital dynamic range
- Improved anti-aliasing filter characteristics
-
OFDMA
- Added bandwidth request processor
- Improved initial ranging processor
- Optimized digital dynamic range
- Improved anti-aliasing filter characteristics
-
SC-QAM
- Added downstream SC-QAM support
-
System and services
- Slightly improved capture performance
- Performing CRC/HCS checks on incoming packets
- Improved RPC/user input validation and error handling
- Fixed some typos in error messages
- The system now supports multiple captures with their own channel selection, filter criteria and file output. The GUI allows to use a single capture with a single filter and file output configuration.
-
WebAdmin (GUI)
- General re-design and improvements in Channel Configuration, Capture Configuration and Status Panel.
- The Status Panel now also shows the capture duration.
- The system now also provides informational messages regarding the Physical Connector and Channel in the Status Panel.
- Context help
- All help is now in one page. The help button jumps to the right section based on the last context used in the GUI.
- Improved content and readability.
- Improved cross-browser compatibility.
- Capture configuration: Add .pcap extension to the file name when it was not given.
- Add "refresh" functionality on filesystem listings (captured files, support archives).
-
Wireshark
Bugfixes
-
Firmware
-
System and services
- Upstream synchronization no longer fails in certain downstream channel bonding configurations.
- Fixed possible segmentation faults due to incorrect incoming (packet) data.
- Fixed some multi-threaded access issues.
- Better handling of channel configuration versus status information.
- Fixed some occasional problems during firmware updates.
-
WebAdmin (GUI)
- Fixed issues with handling file and directories with special characters in their name.
- Several minor bug fixes
Known Issues
-
Firmware
-
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.
-
SC-QAM
- MER can be significantly lower on annex A channels with low traffic load on some CMTSs. This is due to poor symbol scrambling (needed to maintain proper lock) caused by sub-optimal low-entropy payload sequences of null packets. A workaround is to generate some (possibly artificial) traffic on the affected channels.
-
System and services
- During the OFDMA locking phase, the XRA-31 estimates the optimal time and power offset for demodulation (comparable to the ranging process of a cable modem). After RF network changes, primary OFDM or OFDMA channel configuration changes, or due to drift over long time periods, these estimations can deviate considerably from their initial value, leading to demodulation failures for data bursts. In a future release, the XRA-31 will continuously track and update time and power offset after locking.
In the meantime, as a workaround for the above described cases, please remove and re-add the OFDMA channel to force a new locking phase. Note that you can keep track of the XRA-31 internal time offset by inspecting the Wireshark XRA header of the fine ranging signals.
- The system accepts file names longer than 255 characters and starts capturing, but storing the file fails in this case.
-
WebAdmin (GUI)
- Multi-user access shows incomplete or invalid status information.
- This is seen when connecting with multiple users (or browser tabs) to the WebAdmin.
- Also unexpected error messages may be shown.
- The XRA-31 Control Daemon exits when the FPGA firmware is not supported. The GUI has no way to properly show this state to the user and the user is just prompted with an error that connection to the XRA-31 server failed. This can happen for example when an update of the firmware failed. The user can detect this state by verifying that the firmware versions on the System page do not match.
- Layout on small displays can be improved.
|
(0 vote(s))