Self Organizing Network helps in reducing the system overload in an automated way. This new video from Ericsson describes what is SON and how Self Organizing Network will help not only LTE but also in older technologies like 3G and 2G. Automation creates value within the network and self organizing networks are increasingly important not only to lower costs of deployment and operations, but also to offer a better user experience.
Author Archives: Prashant Panigrahi
Voice Over LTE – VoLTE Signalling Call Flow
Voice over LTE – VoLTE is the technology to provide voice and video services over LTE all PS network. As LTE is a complete PS network VoLTE need to use IMS in EPS core to handle voice and video related services. Apart from IMS, VoLTE enabled UE (User Equipment) use MME (Mobility Management Entity) to authenticate a UE prior to entering the EPC. MME need to communicate with HSS which in turn communicate with AAA server for authentication, authorization and accounting purposes.
After authentication procedure is over a control signalling is used to create a default bearer to internet. MME then select the appropriate SGW (Serving Gateway) to connect to eNodeB.
SIP is the most important protocol in VoLTE communication. It is in charge of all signalling required to setup, manage and terminate the session. UDP (User Datagram Protocol ) protocol is used for transmission of actual VoLTE user data packets.
This LTE video tutorial describes:
- Authentication of UE in VoLTE call
- How control signalling is used to create default bearer in VoLTE
- How default internet bearer is established
- Control signalling to create default IMS bearer.
- Default IMS bearer establishment.
- IMS registration via SIP
- Notify change of state
- Actual VoLTE call data packet transmission on UDP
VoLTE Signalling Call Flow – Video Tutorial
VoLTE Battery Issue and Solution from ST Ericsson
VoLTE was in bad limelight because of it’s battery performance issues. I wrote an article how VoLTE will consume twice battery than traditional voice calls. The study was done by Metrico Wireless using LG Connect 4G on MetroPCS network.
ST Ericsson provided a new white paper which clarifies all doubts around VoLTE. Without VoLTE CDMA/LTE systems suffer a severe penalty in that they use a concept called Simultaneous Voice and LTE – SVLTE. This means that during a voice call, both the CDMA radio and the LTE radio are in full operation. The consequence of this is clearly visible in the Metrico data, which also shows the obvious fact that VoLTE+LTE consume less power than CDMA+LTE.
But LTE Networks with 3GPP based legacy systems like UMTS and GSM does not suffer from these issue. Also CDMA + LTE solutions based on fall-back schemes do not have this problem.
ST Ericsson provided many way to tackle this issue using better software architecture, optimizing radio hardware and transmission protocols.
What do you think about these solutions? Will these really help in solving battery issue in VoLTE?
Here is the the ST Ericsson white paper on VoLTE battery problem and solution for the problem.
Carrier Aggregation in LTE Advanced
What is carrier aggregation and how this will help in improving bandwidth and throughput?
ITU set specific requirements for IMT Advanced compliant technology should fulfill. Some of these requirements include at least 40 MHz bandwidth, peak spectral efficiency of 15 bit/s/Hz in downlink and 6.75 bit/s/Hz in uplink and control plane and user plane latency of less than 100 and 10 ms respectively. Carrier aggregation is supported for both FDD and TDD.
Carrier aggregation is a LTE Advanced feature to increase aggregate bandwidth in order to improve data throughput in 4G mobile communication systems. Carrier aggregation in LTE was first introduced in 3GPP release 10 and further improvements are ongoing in Release 11 and onward. To make carrier aggregation backward compatible carriers used in this new feature are R8/R9 carriers.
- A Rel-10 UE with reception and/or transmission capabilities for CA can simultaneously receive and/or transmit on multiple Component Carriers (CCs) corresponding to multiple serving cells.
- A Rel-8/9 UE can receive on a single Component Carrier and transmit on a single Component Carrier corresponding to one serving cell only.
Carrier Aggregation is supported for both contiguous and non-contiguous Component Carriers with each Component Carrier limited to a maximum of 110 Resource Blocks in the frequency domain using the Rel-8/9 numerology.
- The number of DL Component Carriers that can be configured depends on the DL aggregation capability of the UE.
- The number of UL Component Carriers that can be configured depends on the UL aggregation capability of the UE.
- It is not possible to configure a UE with more UL Component Carriers than DL Component Carriers.
- In typical TDD deployments, the number of Component Carriers and the bandwidth of each Component Carrier in UL and DL is the same.
The spacing between centre frequencies of contiguously aggregated CCs shall be a multiple of 300 kHz. This is in order to be compatible with the 100 kHz frequency raster of Rel-8/9 and at the same time preserve orthogonality of the subcarriers with 15 kHz spacing.
Carrier Aggregation in Layer 2
In case of Carrier Aggregation the multi-carrier nature of the physical layer is only exposed to the MAC layer for which one HARQ entity is required per serving cell.
In both uplink and downlink, there is one independent hybrid-ARQ entity per serving cell and one transport block is generated per TTI per serving cell in the absence of spatial multiplexing. Each transport block and its potential HARQ retransmissions are mapped to a single serving cell.
The reception timing difference at the physical layer of DL assignments and UL grants for the same TTI but from different serving cells (e.g. depending on number of control symbols, propagation and deployment scenario) does not affect MAC operation. A UE should cope with a relative propagation delay difference up to 30 microseconds among the component carriers to be aggregated in inter-band non-contiguous CA. This implies that a UE should cope with a delay spread of up to 31.3 micro seconds among the component carriers monitored at the receiver, since the BS time alignment is specified to be up to 1.3 microseconds.
Layer 2 Structure for downlink with CA configured
Layer 2 Structure for uplink with CA configured
RRC Carrier Aggregation
When CA is configured, the UE only has one RRC connection with the network. At RRC connection establishment/reestablishment/handover, one serving cell provides the NAS mobility information (e.g. TAI), and at RRC connection reestablishment/handover, one serving cell provides the security input. This cell is referred to as the Primary Cell (PCell).
In the downlink, the carrier corresponding to the PCell is the Downlink Primary Component Carrier (DL PCC) while in the uplink it is the Uplink Primary Component Carrier (UL PCC).
Depending on UE capabilities, Secondary Cells (SCells) can be configured to form together with the PCell a set of serving cells. In the downlink, the carrier corresponding to an SCell is a Downlink Secondary Component Carrier (DL SCC) while in the uplink it is an Uplink Secondary Component Carrier (UL SCC).
LTE Logical Channels
LTE logical channels structure and mapping between logical channels and transport channels.
Logical channels reside between RLC sublayer and MAC sublayer which are layer 2 protocols in LTE protocol stack. Logical channels tells what kind of information is transferred. Logical channels can be broadly divided into two types:
- Control Channels (for the transfer of control plane information)
- Traffic Channels (for the transfer of user plane information)
Control Channels
Control channels are use for transferring control plane information. The different control channels in LTE are:
Broadcast Control Channel (BCCH)
BCCH channel is used for transferring system control information. Broadcast Control Channel (BCCH) is a downlink channel.
Paging Control Channel (PCCH)
PCCH is a downlink channel which carries paging information and system information change.
Common Control Channel (CCCH)
Channel for transmitting control information between UEs and network. This channel is used for UEs having no RRC connection with the network.
Multicast Control Channel (MCCH)
A point-to-multipoint downlink channel used for transmitting MBMS control information from the network to the UE, for one or several MTCHs. This channel is only used by UEs that receive or are interested to receive MBMS.
Dedicated Control Channel (DCCH)
DCCH is used when there is RRC Connection. DCCH transfers dedicated control information between UE and network. Dedicated Control Channel (DCCH) is a bidirectional channel.
Traffic Channels
Traffic channels are used to carry user plane information. There are two types of logical traffic channels available in LTE
Dedicated Traffic Channel (DTCH)
DTCH is a bi-directional channel used to transfer user plane information between UE and network.
Multicast Traffic Channel (MTCH)
A point-to-multipoint downlink channel for transmitting traffic data from the network to the UE. This channel is only used by UEs that receive MBMS.
Mapping between logical channels and transport channels
Mapping in uplink
Mapping in downlink
Qualcomm Snapdragon 600 and 800 Processors Specifications
Qualcomm unveiled two new application processors to power future mobile hardware. Like their predecessors Snapdragon 600 and Snapdragon 800 come with power packed features for fast performance and better battery life.
Qualcomm Snapdragon 600 Features
- Quad Core Krait 300 CPU running up to 1.7 GHz
- Adreno 320 GPU – offering over 3x the performance of A225 &, as the first GPU in the Adreno 300 series and introduces support for new mobile and GPGPU compute APIs such as OpenGL ES 3.0 , OpenCL and Renderscript Compute.
-
LPDDR3 RAM— (Low Power Double Data Rate 3)- LPDDR3 RAM will help in increasing the data transmission between different components. With this performance in increased in the processor.
- Performance Boost—we expect the Snapdragon 600 processor to deliver up to 40% better performance than the Snapdragon S4 Pro processor.
Snapdragon 800 Processors Features
- Quad Core Krait 400 CPU—speeds up to 2.3 GHz, per core
- Adreno 330 GPU—featuring patented Flex Render Technology and leading edge API’s that are designed to expand the use of GPU processing for general computing and other SoC tasks, the Adreno 330 GPU offers a 2 times better compute performance than Adreno 320
- 2x32bit LPDDR3 RAM at 800MHz – with industry-leading memory bandwidth of 12.8GBps.
- 4G LTE Cat 4 and 802.11ac—these connectivity options offer blazing fast, seamless connectivity with cellular modem boasting data rates up to 150 Mbps and 802.11ac at speeds up to 1 Gbps.
- UltraHD—video can be captured, played back and displayed in UltraHD (previously called “4K.”) The resolution has four times as many pixels as 1080p. (1920x 1080 versus 4096 × 2304)
- HD Audio—support for DTS-HD, Dolby Digital Plus and 7.1 surround sound.
- Dual Image Signal Processors (ISPs) up to 55MP – with support for up to four cameras and allows for 3D captures, photo merging into a master 55MPixel image, separate autofocus and captures, 1080p30 video captures.
- Overall Performance Boost—the Snapdragon 800 processor is expected to deliver up to 75% better performance than the Snapdragon S4 Pro.
LTE RLC – Radio Link Control Protocol
RLC is a layer 2 protocol in LTE UE and NodeB. RLC – Radio Link Control protocol is a data link layer protocol. RRC (Radio Resource Control) is generally controls RLC configuration via RRC-RLC SAP. A RLC entity receives/delivers RLC SDUs from/to upper layer and ends/receives RLC PDUs to/from its peer RLC entity via lower layers.
If RLC entity configured at the eNB, there is a peer RLC entity configured at the UE and vice versa.
An RLC entity can be configured to perform data transfer in one of the following three modes:
Transparent Mode (TM)
A RLC TM entity is with can be transmitter or receiver. That means when acting as a transmitter the transparent mode RLC entity receives SDUs from upper layer and transmit those to it’s peer RLC TM entity via lower layer.
Similarly the receiving RLC TM entity receives RLC PDUs via lower layer and then pass those to upper layer.
When RLC TM entity acts as a transmitter
- It should not segment or concatenate the RLC SDUs
- No header will be included in TMD PDUs
Unacknowledged Mode (UM)
Similar to RLC TM entity RLC UM entity also acts either as a transmitter or receiver. The transmitting RLC UM entity receives SDPs from upper layer and send RLC PDUs to its peer receiving entity via lower layers. Similarly the receiving RLC entity receives RLC PDUs from lower layer and delivers RLC SDUs to upper layer.
Acknowledged Mode (AM)
AM RLC entity can be configured to deliver/receive RLC PDUs through DL/UL DCCH and DL/UL DTCH logical channels.
When the transmitting side of an AM RLC entity forms AMD PDUs from RLC SDUs, it shall:
- segment and/or concatenate the RLC SDUs so that the AMD PDUs fit within the total size of RLC PDU(s) indicated by lower layer at the particular transmission opportunity notified by lower layer.
The transmitting side of an AM RLC entity supports retransmission of RLC data PDUs (ARQ):
- if the RLC data PDU to be retransmitted does not fit within the total size of RLC PDU(s) indicated by lower layer at the particular transmission opportunity notified by lower layer, the AM RLC entity can re-segment the RLC data PDU into AMD PDU segments;
- the number of re-segmentation is not limited.
When the transmitting side of an AM RLC entity forms AMD PDUs from RLC SDUs received from upper layer or AMD PDU segments from RLC data PDUs to be retransmitted, it shall:
- include relevant RLC headers in the RLC data PDU.
When the receiving side of an AM RLC entity receives RLC data PDUs, it shall:
- detect whether or not the RLC data PDUs have been received in duplication, and discard duplicated RLC data PDUs;
- reorder the RLC data PDUs if they are received out of sequence;
- detect the loss of RLC data PDUs at lower layers and request retransmissions to its peer AM RLC entity;
- reassemble RLC SDUs from the reordered RLC data PDUs and deliver the RLC SDUs to upper layer in sequence.
At the time of RLC re-establishment, the receiving side of an AM RLC entity shall:
- if possible, reassemble RLC SDUs from the RLC data PDUs that are received out of sequence and deliver them to upper layer;
- discard any remaining RLC data PDUs that could not be reassembled into RLC SDUs;
- initialize relevant state variables and stop relevant timers.
RLC Functions
- transfer of upper layer PDUs;
- error correction through ARQ (only for AM data transfer);
- concatenation, segmentation and reassembly of RLC SDUs (only for UM and AM data transfer);
- re-segmentation of RLC data PDUs (only for AM data transfer);
- reordering of RLC data PDUs (only for UM and AM data transfer);
- duplicate detection (only for UM and AM data transfer);
- RLC SDU discard (only for UM and AM data transfer);
- RLC re-establishment;
- Protocol error detection (only for AM data transfer).
RLC PDU (Protocol Data Unit)
RLC PDUs can be categorized into RLC data PDUs and RLC control PDUs.
- RLC data PDUs are used by TM, UM and AM RLC entities to transfer upper layer PDUs (i.e. RLC SDUs).
- RLC control PDUs are used by AM RLC entity to perform ARQ procedures.
I added tutorials on encoding and decoding of RLC TM and UM PDUs in earlier tutorials.