A trip around the HSPA world

I am writing this post to illustrate the path that a byte of data takes to go around the HSPA network. The details are conforming to Rel 6 of 3GPP specifications. This is just an overview, for details please refer the 3GPP specification.

The dialogue is started from the mobile device(it can be a HTTP req, email push etc), where a few bytes travel through the L3, L2 and PHY layers in the Uplink direction to reach the network nodes and routed to the application end point. There is a response from the application end point which consists of bytes destined to the Mobile(IP address).The bytes in the DL again have to go through the network nodes and the protocol layers before they reach the mobile.

Since Application end point can be any where in the internet, the start/end of the journey is from/to the GGSN on the network side.

The user starts a application such as Mobile Originated email(or HTTP req from a browsing session, ...) on the mobile, which triggers data in the Uplink. The application submits the data (as an IP packet in  most cases) to the mobile modem to be transmitted in Uplink. It is assumed here that the RRC Connection and the Radio Links are already in place and the UE is in DCH state. The data is submitted under a PDP Context. A PDP Context is assigned in the GGSN where in an IP address is assigned for the connection. This connection is associated to a Radio bearer which enables the data transfer between L3 end points between mobile and network. Radio Bearer is like a service provided by the L3 to transfer data across the Air interface up to the L3 on the other end.

The modem inputs this data to the string of Radio Interface Protocols(RIP) to be packaged suitably to be transmitted over the air. Each layer of the Radio Interface Protocol plays a role in efficient and reliable transfer of the data across the Air Interface. The unit of data entering a layer is called the Service Data Unit(SDU) and after processing the unit of data exiting the layer is the Packet Data Unit(PDU). So the PDU of a upper layer becomes the SDU of the lower layer as the data traverses the RIP. The figure below shows the architecture of the RIP.




The first station in this packaging is the PDPC layer. Packet Data Convergence Protocol(PDCP) compresses the IP header in the packet. This enables more efficient use of the radio resources by eliminating some of the redundant information in the IP header(20 bytes for IPv4). This is all the more effective in case of streaming or file transfer where the packets travel between two fixed end points(IP addresses). PDCP compresses the header, attaches a header of its own(containing information about the algorithm and a sequence number of the PDU). The PDCP PDU is sent to the RLC.

Radio Link Control(RLC) layer maps the data from the Radio bearers onto the Logical Channels. The RLC does the segmentation/concatenation of RLC SDUs, ciphers and deciphers the data on RLC AM and UM mode, and provides for re transmission of the PDUs which were NACKed. Depending upon the logical channel type required, a RLC entity is setup(TM, UM or AM). Bidirectional logical channels which require reliable transfer are setup with a AM RLC entity. TM is for real time applications (like voice call), which donot require re transmission and there is no overhead of RLC header(transparent). There are not many applications which utilise the UM mode. The IP packet could be segmented depending on the RLC PDU size configured for the RLC AM entity, in which case the IP packet will be carried in multiple RLC PDUs. These RLC PDU(s) are forwarded to the MAC layer on Logical Channels.

Medium Access Control(MAC) is the Link layer protocol. In Rel 6, the MAC layer is composed of MAC-e(on UE and NodeB), MAC-d(on UE and NodeB) and MAC-es(on RNC) in the Uplink direction(other MAC entities can also be present depending on configuration and transport channel to be used). The MAC plays many important roles in the reliable and efficient data transmission. It maps logical channels to transport channels, selects transport format for the transmission in each TTI, schedules the data according as the logical channel priority, among other functions.In this case the transport channel is the E-DCH Channel. The IP packet which started as part of an email from the mobile user, and has been delivered to MAC in form of RLC PDU(s) is now resting in MAC priority queues, waiting for Uplink resources (Scheduling Grants) to be scheduled for transfer on a transport block. When the moment arrives(the logical channel is scheduled), the RLC PDU(s) and formed into a MAC-e PDU to be delivered to the Physical Layer. Here again the RLC PDUs could be segmented to fit into a MAC-e PDU or several RLC PDUs could be concatenated to form a MAC-e PDU.

The UE side MAC architecture is illustrate in the figure below:



The Physical Layer(PHY) maps the transport channels onto Phycical channels. In this case the Physical channel is the E-DPDCH channel. The data received in a transport block from MAC is to be transmitted onto one radio frame(2ms or 10ms long, depending on configuration).

The radio transmissions are received at the NodeB and decoded. The successfully decoded transport blocks are forwarded to the MAC-e. MAC-e besides processing the MAC-e SDU does other important jobs like handles UE feedback of the channel quality and outstanding traffic, schedule UL resources among UEs participating in UL E-DCH transfer according as the UE priority. Here the RLC SDUs are extracted from the MAC-e PDU and are delivered to RLC (via MAC-es and MAC-d). MAC-d deciphers the PDUs MAC-es resides on the RNC and does macro-diversity combining (combining the data received from multiple Radio Links on separate NodeB in case of SHO) and seuencing of the RLC SDUs. The RLC SDUs are sent to RLC on the logical channel which they belong to.

At RLC, the SDUs meet the RLC entity which is corresponding to its counterpart on the mobile. The IP packet is still hidden in the RLC SDUs. Here RLC SDUs are deciphered and then concatenated if required to retrieve the PDCP SDU, which is sent to the PDCP.

The PDCP decompresses the IP header and sends of the IP packet to the NAS(Non Access Stratum) nodes for routing to the destination. The IP packet is sent over the IuPS interface on a GTP (GPRS Tunneling Protocol) tunnel. The packet reached GGSN after going through SGSN. Direct Tunneling provides to bypass the SGSN and deliver the IP packet directly to GGSN.

At GGSN the IP packet is associated to a PDP context. Here the IP header is modified such that the outside world can send back the response to the correct place. After this modification, it is routed to its destination(the mail server). The response from the server comes back to GGSN where it is tagged to a PDP context, and sent off onto the GTP tunnel to the RNC.

From here starts the journey of the IP packet in the downlink towards its destination on the Mobile which started the dialogue by triggering the Mobile Originated email.

The processing in the downlink is spread over RNC and NodeB, with RLC and some functions of MAC(MAC-d) on RNC and MAC-hs and PHY on the NodeB.

The PDCP gets the IP packet for transmission in Downlink. The role of PDCP is same as in UL; compressing the IP header and attaching another header. Next is RLC, where a RLC AM entity has been instantiated to handle the logical channel for the DL data. It makes the RLC PDUs and sends them off to MAC-d.

MAC-d does ciphering and flow control towards MAC-c(if there is any) or FP(Framing Protocol). Framing protocol is required to synchronise RNC with multiple NodeBs. There is time alignment and Transport Channel synchronisation between the FP on RNC and NodeB. Time synchronisation makes adjustments for the difference in clock. Transport Channel sync corrects the timing of the arrival of data from RNC to NodeB(done on a Transport Channel basis). This is required to ensure availability of data at the instance it has to be transmitted(CFN) and to limit the buffering of data on NodeB. Next stop is the MAC-hs.

MAC-hs (high speed) is the MAC entity handling the HS-DSCH transport channel in DL. It has many improvements over its predecessor. Adaptive Modulation and coding allows for adaption to the channel conditions, Hybrid ARQ(HARQ) provides for fast retransmission and soft combining with incremental redundancy. Another function is fast scheduling, where in the MAC-hs allocates the available WCDMA codes among the competing UEs, based on the channel quality feedback from the UE, UE priority, pending data, and other factors. The IP packet that has hit this acceleration station, finds itself becoming a part of thebig, roomy MAC-hs PDU which is assigned one HARQ process for transmission to the Mobile.

The MAC architecture from the UTRAN side is shown below in the figure.






After reaching the Mobile, the MAC-hs PDU traverses through MAC, RLC and PDCP, finding its familiar form of the IP packet. Once fully formed, the IP packet is delivered to the Application depending on the destination IP address or Transport port number. In this case this is the response from the mail server. It will take many such IP packets to successfully transmit the email from the Mobile. All of those will have to wade through the intricate layers of the Radio Interface Protocols in order to reach their destinations.

Link Layer and App Layer Speeds


The throughput experienced at the application layer is always lower than the Link layer speed (which is in most cases advertised). The speeds published by the Network Service Providers is reduced because of number of factors.

For definition:

Link Layer Speed: is the throughput at the Link Layer. This is the rate with which a L2 packet is transferred between the corresponding L2 entities.
Application Layer Speed: is the speed experienced by the user. The rate at which the data useful to the application is transferred between the Application End points.

The extent of reduction in the Application layer speed depends upon:

  • IP and transport protocol overhead
  • UMTS Layer 2, Layer 3 Header overheads
  • Segmentation/Concatenation
  • Amount of Padding

The IP carries almost all of the data traffic and adds a IP header. The transport protocol adds another header and extra bytes to the data to be transmitted.

The UMTS architecture has multiple entities on the UE and network side interacting with each other. These require some control information in order to transfer data among each other.

The L2 (MAC) and L3(RLC) headers add to the over head. Next is the efficiency of the algorithm at MAC which packs the data in MAC PDUs. This algorithm should be smart enough to keep the amount of padding to a minimum.



The figure above shows the overhead added at each layer. Though not to scale, it highlights all the extra bytes that the MAC PDU is carrying for the Application data bytes that it is carrying.
Also, here it is assumed that the IP packet is transmitted as a whole, which is seldom the case. At most of the time, the IP packet might be segmented into RLC PDUs and then one RLC PDU segmented into MAC PDUs, depending on the TB size selected by MAC.

This overhead is even more pronounced when the MAC PDU size is small. Therefore it is important that RLC PDU size and the MAC PDU sizes be chosen in a way that the segmentation is minimized.

Lets take an example to see the magnitude of this overhead:
For a application using 384 kbps PS RAB


Higher layer
RAB/Signalling RB
RAB
RLC
Logical channel type
DTCH
RLC mode
AM
Payload sizes, bit
320
Max data rate, bps
384 000
AMD PDU header, bit
16
MAC
MAC header, bit
0
MAC multiplexing
N/A
Layer 1
TrCH type
DCH
TB sizes, bit
336
TFS
TF0, bits
0x336
TF1, bits
1x336
TF2, bits
2x336
TF3, bits
4x336
TF4, bits
8x336
TF5, bits
12x336
TF6, bits
N/A (alt. 16x336)
TF7, bits
N/A (alt. 20x336)
TF8, bits
N/A (alt. 24x336)
TTI, ms
10 (alt. 20)
Coding type
TC
CRC, bit
16
Max number of bits/TTI after channel coding
12 684 (alt. 25 368)
RM attribute
110 to 150


Lets assume for simplicity a 5 byte ping. Each ping packet will be carried in a IP packet with ICMP header and will be fit inside one Transport Block for carrying over the air. The application data transferred in each 336 bit of Transport Block is:

ping size = 5 * 8 = 40 bits

The header sizes are:

336 - 20*8(IP header) - 8*8(ICMP header) - 16 (MAC-header) - 16 (RLC AM header) - 40 (padding) = 40 bits.





Optimizing Modulation for MIMO Operation

MIMO Operation s marred by Inter Channel Interference and Inter Antenna Synchronisation, because it involves simultaneous transmission/reception on Multiple Antennas. The transmission is pre-coded according to the PMI (Precoding Matrix Indicator) which is used at the receiver to identify the transmission from each of the antennas.

The ICI mitigation and synchronisation requirement make the receptor design too complicated and also limit the gain to 1.5X rather than the theoretical 2X for a 2X2 MIMO.

An improvisation in the Modulation used for MIMO operation is proposed in a IEEE paper which will not require simultaneous transmission/reception. Only one antenna will transmit and one antenna will receive the signal. This will remove the ICI and the requirement for antenna synchronisation, while still giving increased throughput with the use of MIMO (the increase will be less than the theoretical conventional MIMO, but will match the practical gain).

The new modulation technique uses the antenna as a modulation unit (called Space Modulation).
The Space Modulated Symbol is formed by the combination of the conventional modulation symbol (QPSK or 16-QAM) and the index of the antenna used for transmission.

Example for No of Tx Antenna = 4

With 4 antennas the transmission can be from antenna 1,2,3 or 4. The symbols therefore are:


With QPSK used for Modulating the bit stream, the no of bits in the Space Modulated Symbol = 2(QPSK)X2=4. This is same as 16-QAM. Therefore using Space Modulation on top of QPSK will result in 2X data speed, same as in 16-QAM.

(QPSK Symbol)

4 Tx Antenna adding 2 bits to the Space Modulated Symbol


The increase in the data rate is logarithmic with the number of Tx Antennas in use.As compared to MIMO, where the increase in data rate is linear with no of antennas.

MIMO

New Data Rate = (No of Antenna)x(Original Data Rate)


MIMO with Space Modulation

New Data Rate = log2(No of Antenna)x(Original Data Rate)



For DL only MIMO operation, the design of the UE receiver can be greatly simplified. Multiple Rx antennas will provide diversity gain, and a single Rx antenna will also work.


Multiple Operator Core Network



This is a way to share the network resources among multiple operators. The same network infrastructure is used to transmit/receive for different operators.
The MIB contains a list of multiple PLMN Identities. The UE reads the MIB and selects a PLMN to register to, based on its subscription.



MIB Contents:

.........
Common PLMN
..........

mibPLMN-Identity BOOLEAN,
multiplePLMNs SEQUENCE (SIZE(1..5))

  • PLMN1 
  • PLMN2

PLMN1, PLMN2, etc are the multiple PLMNs in the cell. If mibPLMN-Identity is st to TRUE, the supporting UE can include the common PLMN identity also in the list of PLMNs to choose from. If it is FALSE, the supporting UE does not attempt to register on the common PLMN.




The terms associated with MOCN and their definitions are:


Conventional network: A PLMN consisting of radio access network and core network, by which only one serving operator provides services to its subscriber. Subscribers of other operators may receive services by national or international roaming.
Common PLMN: The PLMN-id indicated in the system broadcast information as defined for conventional networks, which non-supporting UEs understand as the serving operator.
Core network operator: An operator that provides services to subscribers as one of multiple serving operators that share at least a radio access network. Each core network operator may provide services to subscriber of other operators by national or international roaming.
Gateway Core Network: A network sharing configuration in which parts of the core network (MSC/SGSNs) are also shared.
Multi-Operator Core Network: A network-sharing configuration in which only the RAN is shared.
Non-supporting UE: A UE that does not support network sharing in the sense that it ignores the additional broadcast system information that is specific for network sharing. In other specifications, the term "network sharing non-supporting UE" may be used.
Supporting UE: A UE that supports network sharing in the sense that it is able to select a core network operator as the serving operator within a shared network. In other specifications, the term "network sharing supporting UE" may be used.




Further Reading:      23.251