How Wireless Communication Systems work…
- Mobile devices of all shapes and sizes may communicate with each other, with fixed infrastructure, with satellites etc
- Wireless communications is susceptible to noise, interference, poor signal strength, jamming etc
- Owing to these effects, the bits in the received message may differ to the bits in the transmitted message
- Before transmitting a message, transmitters will typically use a channel encoder to protect the communication from these transmission errors
- There are three main channel coding standards...Turbo (used in 3GPP rel 99 to rel14), LDPC (mainly used in wi-fi and 5G NR eMBB data channel) and polar, the newest standard, also to be used in 5G NR eMBB control channel
Using the hosepipe analogy from our video
- The receiver uses a Decoder to correct any erroneous bits in the received message
- The encoder and decoder must support the same channel coding standard and be designed to avoid imposing a bottleneck on…
- The system throughput (the diameter of the data pipe)
- The end-to-end latency (the length of the data pipe)
There are three major types of channel coding, as described with their relative benefits and challenges in the table below:
|Turbo code||LDPC code||Polar code|
|Maturity||Proven in 3G & 4G, will be used in 3GPP rel 14 & NB-IoT||Proven in IEEE standards, selected for data channel eMBB in 5G NR||Selected for 5G control channel in eMBB|
|Error correction capability||Similar||Similar||Similar|
|Flexibility||Very flexible frame length & coding rate||Relatively inflexible||Achievable with the AccelerComm approach|
|Computational complexity||Higher for most coding rates||Lower for most coding rates||Lower for most coding rates|
|Throughput latency||Proven by AccelerComm||Proven for fully-parallel||Proven for deep pipelining|
|Lower, particularly at low coding rates||Higher, particularly at low coding rates||Achievable with the AccelerComm approach|
|Synergy with 3G & 4G||Yes||No||No|
Turbo Code Design
A turbo code has two parts: the encoder used in the transmitter and the decoder used in the receiver. The design of the turbo encoder dictates the error correction capability of a compatible turbo decoder. However, rather than optimising the design to achieve the best error correction capability, the design of turbo encoders typically focusses on meeting the constraints that allow the conventional approach to turbo decoder design to support parallel processing. However, this approach does not achieve the high degrees of parallel processing that are required to meet the performance demands of next generation wireless communication systems.
The AccelerComm turbo decoder takes a different approach to supporting parallel processing. Our approach can support arbitrarily high degrees of parallel processing, no matter how the turbo encoder is designed. In addition to meeting the multi-Gbps throughputs and sub-microsecond latencies that are demanded by next generation wireless communication systems, this approach allows the turbo encoder to be designed to optimise error correction capability.
Polar Code Design
Compared with turbo and LDPC codes, polar codes are far less mature and a conventional approach to their implementation has not yet emerged. The encoder and decoder of a polar code have regular but intricate structures. During polar decoding, the information bits are decoded one at a time, with each successive bit informing the decoding of the next. However, the complexity associated with decoding each successive bit varies considerably, depending on its position in the block and the design of the corresponding polar encoder. This makes it difficult to implement flexible, high performance polar decoders.
Over the last seven years, AccelerComm has developed a sixth sense for the intricate structure of polar codes. By harnessing this intuition and expertise, AccelerComm is uniquely positioned to exploit the regularity of the polar code structure, in order to offer polar encoders and decoders with unmatched flexibility and performance.
AccelerComm will have polar encode and decode IP blocks available for FPGA implementation by summer 2017.