ARP in LTE is not the Ethernet standard for address resolution, but rather the Allocation and Retention Policy.
A scenario may arise where on a congested cell another bearer is requested to be setup.
The P-GW, S-GW or eNB have to make a decision to either drop an existing bearer, or to refuse the request to setup a new bearer.
The ARP value is used to determine the priority of the bearer to be established compared to others,
For example a call to an emergency services number on a congested cell should drop any other bearers so the call can be made, thus the request for bearer for the VoLTE call would have a higher ARP value than the other bearers and the P-GW, S-GW or eNB would drop an existing bearer with a lower ARP value to accommodate the new bearer with a higher ARP value.
ARP is only used when setting up a new bearer, not to determine how much priority is given to that bearer once it’s established (that’s defined by the QCI).
MBR stands for Maximum Bit Rate, and it defines the maximum rate traffic can flow between a UE and the network.
It can be defined on several levels:
MBR per Bearer
This is the maximum bit rate per bearer, this rate can be exceeded but if it is exceeded it’s QoS (QCI) values for the traffic peaking higher than the MBR is back to best-effort.
AMBR
Aggregate Maximum Bit Rate – Maximum bit rate of all Service Data Flows / Bearers to and from the network from a single UE.
APN-MBR
The APN-MBR allows the operator to set a maximum bit rate per APN, for example an operator may choose to limit the MBR for subscriber on an APN for a MVNO to give it’s direct customers a higher speed.
The QCI (Quality Class Indicator) is a value of 0-9 to denote the service type and the maximum delays, packet loss and throughput the service requires.
Different data flows have different service requirements, let’s look at some examples:
A VoLTE call requires low latency and low packet loss, without low latency it’ll be impossible to hold a conversation with long delays, and with high packet loss you won’t be able to hear each other.
On the other hand a HTTP (Web) browsing session will be impervious to high latency or packet loss – the only perceived change would be slightly longer page load times as lost packets are resent and added delay on load of a few hundred ms.
So now we understand the different requirements of data flows, let’s look at the columns in the table above so we can understand what they actually signify:
GBR
Guaranteed Bit Rate bearers means our eNB will reserve resource blocks to carry this data no matter what, it’ll have those resource blocks ready to transport this data.
Even if the data’s not flowing a GBR means the resources are reserved even if nothing is going through them.
This means those resource blocks can’t be shared by other users on the network. The Uu interface in the E-UTRAN is shared between UEs in time and frequency, but with GBR bearers parts of this can be reserved exclusively for use by that traffic.
Non-GBR
With a Non-GBR bearer this means there is no guaranteed bit rate, and it’s just best effort.
Non-GBR traffic is scheduled onto resource blocks when they’re not in use by other non-GBR traffic or by GBR traffic.
Priority
The priory value is used for preemption by the PCRF.
The lower the value the more quickly it’ll be processed and scheduled onto the Uu interface.
Packet Delay Budget
Maximum allowable packet delay as measured from P-GW to UE.
Most of the budget relates to the over-the-air scheduling delays.
The eNB uses the QCI information to make its scheduling decisions and packet prioritisation to ensure that the QoS requirements are met on a per-EPS-bearer basis.
(20ms is typically subtracted from this value to account for the radio propagation delay on the Uu interface)
Packet Error Loss Rate (PELR)
This is packets lost on the Uu interface, that have been sent but not confirmed received.
The PELR is an upper boundary for how high this can go, based on the SDUs (IP Packets) that have been processed by the sender on RLC but not delivered up to the next layers (PDCP) by the receiver.
(Any traffic bursting above the GBR is not counted toward the PELR)
GBR is a confusing concept at the start when looking at LTE but it’s actually kind of simple when we break it down.
GBR stands for Guaranteed Bit Rate, meaning the UE is guaranteed a set bit rate for the bearer.
The default bearer is always a non-GBR bearer, with best effort data rates.
Let’s look at non-GBR bearers to understand the need for GBR bearers:
As the Uu (Air) interface is shared between many UEs, each is able to transfer data. Let’s take an example of a cell with two UEs in it and not much bandwidth available.
If UE1 and UE2 are both sending the same amount of data it’ll be evenly split between the two.
But if UE1 starts sending a huge amount of data (high bit rate) this will impact on the other UEs in the cells ability to send data over the air as it’s a shared resource.
So if UE2 needs to send a stream of small but important data over the air interface, while UE2 is sending huge amounts of data, we’d have a problem.
To address this we introduce the concept of a Guaranteed Bit Rate. We tell the eNB that the bearer carrying UE2’s small but important data needs a Guaranteed Bit Rate and it reserves blocks on the air interface for UE2’s data.
So now we’ve seen the need for GBR there’s the counter point – the cost.
While UE1 can still continue sending but the eNB will schedule fewer resource blocks to it as it’s reserved some for UE2’s data flow.
If we introduced more and more UEs each requiring GBR bearers, eventually our non-GBR traffic would simply not get through, so GBR bearers have to be used sparingly.
Note: IP data isn’t like frame relay or circuit switched data that’s consistent, bit rate can spike and drop away all the time. GBR guarantees a minimum bit rate, which is generally tuned to the requirements of the data flow. For example a GBR for a Voice over IP call would reserve enough for the media (RTP stream) but no more, so as not to use up resources it doesn’t need.
We’ve already touched on how subscribers are authenticated to the network, how the network is authenticated to subscribers and how the key hierarchy works for encryption of user data and control plane data.
If the IMSI was broadcast in the clear over the air, anyone listening would have the unique identifier of the subscriber nearby and be able to track their movements.
We want to limit the use of the IMSI over the air to a minimum.
During the first exchange the terminal is forced to send it’s IMSI, it’s the only way we can go about authenticating to the network, but once the terminal is authenticated and encryption of the radio link has been established, the network allocates a temporary identifier to the terminal, called the Temporary Mobile Subscriber Identity (TMSI) by the serving MME.
The TMSI is given to the terminal once encryption is setup, so only the network and the terminal know the mapping between IMSI and TMSI.
The TMSI is used for all future communication between the Network and the Terminal, hiding the IMSI.
The TMSI can be updated / changed at regular intervals to ensure the IMSI-TMSI mapping cannot be ascertained by a process of elimination.
The TMSI is short – only 4 bytes long – and this only has significance for the serving MME.
For the network to ascertain what MME is serving what TMSI the terminal is also assigned a Globally Unique Temporary (UE) Identity (GUTI), to identify the MME that knows the TMSI to IMSI mapping.
The GUTI is made up of the MNC/MCC combination, then an MME group ID to identify the MME group the serving MME is in, a MME code to identify the MME that allocated the TMSI and finally the TMSI itself.
The decision to use the TMSI or GUTI in a dialog is dependant on the needs of the dialog and what information both sides have. For example in an MME change the GUTI is needed so the original IMSI can be determined by the new MME, while in a normal handover the TMSI is enough.
We’ve talked a bit in the past few posts about keys, K and all it’s derivatives, such as Kenc, Kint, etc.
Each of these is derived from our single secret key K, known only to the HSS and the USIM.
To minimise the load on the HSS, the HSS transfers some of the key management roles to the MME, without ever actually revealing what the secret key K actually is to the MME.
This means the HSS is only consulted by the MME when a UE/Terminal attaches to the network, and not each time it attaches to different cell etc.
When the UE/Terminal first attaches to the network, as outlined in my previous post, the HSS also generates an additional key it sends to the MME, called K-ASME.
K-ASME is the K key derived value generated by the HSS and sent to the MME. It sands for “Access Security Management Entity” key.
When the MME has the K-ASME it’s then able to generate the other keys for use within the network, for example the Kenb key, used by the eNodeB to generate the keys required for communications.
The USIM generates the K-ASME itself, and as it’s got the same input parameters, the K-ASME generated by the USIM is the same as that generated by the HSS.
The USIM can then give the terminal the K-ASME key, so it can generate the same Kenb key required to generate keys for complete communications.
We’ve already touched on how subscribers are authenticated to the network, how the network is authenticated to subscribers.
Those functions are done “in the clear” meaning anyone listening can get a copy of the data transmitted, and responses could be spoofed or faked.
To prevent this, we want to ensure the data is ciphered (encrypted) and the integrity of the data is ensured (no one has messed with our packets in transmission or is sending fake packets).
Ciphering of Messages
Before being transmitted over the Air interface (Uu) each packet is encrypted to prevent eavesdropping.
This is done by taking the plain text data and a ciphering sequence for that data of the same length as the packet and XORing two.
The terminal and the eNodeB both generate the same ciphering sequence for that data.
This means to get the ciphered version of the packet you simply XOR the Ciphering Sequence and the Plain text data.
To get the plain text from the ciphered packet you simply XOR the ciphered packet and ciphering sequence.
The Ciphering Sequence is made up of parts known only to the Terminal and the Network (eNB), meaning anyone listening can’t deduce the same ciphering sequence.
The Ciphering Sequence is derived from the following input parameters:
Key Kenc
Packet Number
Bearer Number
Direction (UL/DL)
Packet Size
Is is then ciphered using a ciphering algorithm, 3GPP define two options – AES or SNOW 3G. There is an option to not generate a ciphering sequence at all, but it’s not designed for use in production environments for obvious reasons.
Ciphering Sequences are never reused, the packet number increments with each packet sent, and therefore a new Cipher Sequence is generated for each.
Someone listening to the air interface (Uu) may be able to deduce packet size, direction and even bearer, but without the packet number and secret key Kenc, the data won’t be readable.
Data Integrity
By using the same ciphering sequence & XOR process outlined above, we also ensure that data has not been manipulated or changed in transmission, or that it’s not a fake message spoofing the terminal or the eNB.
Each frame contains the packet and also a “Message Authentication Code” or “MAC” (Not to be confused with media access control), a 32 bit long cryptographic hash of the contents of the packet.
The sender generates the MAC for each packet and appends it in the frame,
The receiver looks at the contents of the packet and generates it’s own MAC using the same input parameters, if the two MACs (Generated and received) do not match, the packet is discarded.
This allows the receiver to detect corrupted packets, but does not prevent a malicious person from sending their own fake packets,
To prevent this the MAC hash function requires other input parameter as well as the packet itself, such as the secret key Kint, packet number, direction and bearer.
By adding this we ensure that the packet was sourced from a sender with access to all this data – either the terminal or the eNB.
As we just saw when a terminal moves to ECC-Idle while in EMM-Registered state, it releases it’s radio resources, so what happens when the UE needs to send / receive data again?
UE is disconnected from Radio Resources (ECM-Idle & EMM Registered)
While one option could have been to go through the full attach procedure again when the UE is triggered, the 3GPP team wanted the re-connection process to be as fast as possible.
As we saw in the last post we don’t drop the S-GW <-> P-GW tunnel, which saves time on re-establishing a connection. The S1 tunnel is also not completely released; the TEID value from the S-GW end of the tunnel is saved by the MME so it can be reused by the new tunnel when the UE reconnects, without needing to inform the S-GW.
One of the common themes we cover over and over in the 4G discussion is the desire to preserve energy on the UE RF side of things, to extend battery life as much as possible.
The 3GPPs requirements for LTE also included the smallest round trip times, defining less than 5 ms in unload condition, so traffic to the UE must be routed as quickly as possible.
Mobiles are by their very nature, mobile.
This requires UEs to constantly monitor the RF conditions and the signal measurements from different base stations so the UE can determine if it’s time to handoff to another cell due to going further from one eNB and closer to another, or another eNB offering better RF conditions (Strong signal etc).
This requires regular exchanges of messages and checks, but this would take a lot of energy and eat up battery usage.
Instead we avoid maintaining the radio connection all the time with the aid of an inactivity timer on the eNB.
For as long as user data is flowing over the air interface the connection is maintained, for example web browsing, the inactivity timer is constantly reset as traffic flows.
However when the eNB detects no packets sent or received by the UE the timer starts counting down from it’s set value.
When the inactivity timer reaches 0 the RRC Connection is released and the UE no longer has an RNTI.
The UE is still listening to an eNB, it’s just not sending data to it it and visa-versa.
As the radio bearer has been removed the UE the S1-AP and S1-UP bearers between the eNB and the MME and the eNB and the S-GW respectively, can be torn down.
This means the MME is no long sure of exactly which eNB the UE is listening on.
This is referred to as ECM_IDLE state as there is no radio connection, and the network is unaware of the precise location of the UE.
An ECM_ACTIVE state is the state when the UE is connected to an eNB with an RNTI and it’s inactivity timer has not reached 0.
The dotted line bearers shown in the image above frequently change between active and inactive based on the ECM_ACTIVE / ECM_INACTIVE state of the bearers.
EPS Mobility Management (EMM) has two states – EMM-Registered (UE reachable) and EMM-Deregistered (UE not reachable).
A UE is in the deregistered state when it is not rechable, for example not currently powered up or in flight mode.
The MME memorizes the state of each UE and it’s context elements such as it’s most recent GUTI, IMSI, security parameters etc.
Attach Procedure
To attach to the network a UE sends an EMM Attach Request with it’s most recent GUTI to the MME.
In the same request the UE also includes an ESM PDN Connectivity Request to gain access to the external networks.
The Authentication & Key Agreement procedure is followed between the UE and the MME/HSS to authenticate the network and the subscriber.
One this is done the MME looks at the connectivity requested and the APN of the subscriber, the MME then selects a Serving-Gateway and Packet-Gateway based on the APN.
The MME then sends a GTP-C Create Session Request along with the connectivity requested (IPv4/6), APN and IMSI of the subscriber and it’s allocated TEID for this tunnel to the S-GW.
The S-GW also sends a GTP-C Create Session Request along with the connectivity requested (IPv4/6), APN and IMSI of the subscriber to the P-GW, along with the S-GW’s allocated TEID for this tunnel too.
The P-GW then sends a GTP-C Create Session back to the S-GW containing it’s TEID and it also includes the IP Address to be allocated to the UE.
A GTP session is now setup between the P-GW and the S-GW for this bearer, with the TEID values added to the TEID management tables on both devices. This GTP tunnel is referred to an S5 (home) or an S8 (roaming) Bearer in 3GPP parlance.
Another GTP-C Create Session message with it’s own TEID is also sent from the S-GW to the MME.
The MME, S-GW and P-GW now each know TEID for each of the 2 tunnels setup (MME<->S-GW, S-GW<->P-GW) so have what they need to fill their TEID management tables.
When the MME recieves the GTP-C Create Session with the IP Address for the UE it sends an EMM Attach Accept and a EPS Bearer Context Setup Request containing the IP Address the P-GW allocated to the UE to the UE itself.
The UE stores the allocated IP and sends an acknowledgement to the MME in the form of an EMM Attach Complete message back to the MME.
The MME sends a GTP-C Modify Bearer Request which transfers the bearer setup between MME and SGW and modifies it to be between the SGW and the eNB.
The S-GW sends back a GTP-C Modify Bearer Complete message and modifies the GTP tunnel to be between the SGW and the eNB. A S1 bearer is now established for carrying user data from the eNB to the SGW.
Once this procedure is complete the UE is now in the EMM Registered State meaning it is known to the MME, it has a security association and has an IP Address.
The S-GW and the P-GW also stores the TEIDs for the UE.
Detach Procedure
When a UE detaches from the network (for example it powers down), the network must release all the tunnels for that UE, the MME state must be updated to EMM Deregistered and the MME must also keep a record for the last GUTI and security keys,
To detach from the network the UE sends a RLC UL Information Transfer message containing an EMM Detach Request which includes it’s current GUTI.
As soon as the UE recivers confirmation from the eNB the UE can power down, but the eNB must inform the network of the disconnection so the resources can be released.
The eNB sends a S1Ap Uplink NAS Transport message containing a EMM Detach Request with the UE’s GUTI to the MME.
The MME can then release the security context,
The MME then sends a GTP-C Delete Session Request to the S-GW.
Upon recipt of this request the S-GW requests the P-GW tears down it’s tunnel between the P-GW and S-GW (aka the S5/S8 Bearer) by sending it’s own GTP-C Delete Session Request to the P-GW.
Once the S-GW has confirmation the tunnel has been taken down (In the form of a GTP-C Delete Session Response) the S-GW sends a GTP-C Delete Session Response to the MME.
The MME must signal to the eNB it can release the RNTI and the radio resources. To do this it sends a S1-AP UE Context Release Command which releases the radio bearers and tears down the S1-UP bearer between the eNB and the S-GW.
The eNB then sends a S1-AP UE Context Release Completeto the MME.
Finally the MME sends a Diameter Notification Request (PGW and APN Removed) to the HSS to update the HSS of the user’s status, the HSS signals back with a Diameter Notification Answer and the HSS knows the user is no longer reachable.
In a fixed network, if I were to connect my laptop to my network at home, I’d get a different address to if I plug it in at work.
In a mobile network UEs are often moving, but we can’t keep changing the IP address – that would lead to all sorts of issues.
The UE must maintain the same IP address, at least for the duration of their session.
Instead the IP address of a UE is allocated by the P-Gateway (P-GW) when the UE attaches.
The IP the P-GW allocates to the UE is in a subnet managed by the P-GW – that IP prefix is associated with the P-GW, so traffic is sent to the P-GW to get to the UE.
Therefore all traffic destined for the UE from external networks will be sent to the P-GW first.
Because the UE is mobile and changing places inside the network, we need a way to keep the UE’s IP even though it’s moving around, something that by default TCP/IP networks don’t cater for very well.
To achieve this we use a technique known as encapsulation where we take the complete IP packet for the UE, and instead of forwarding it on to the UE on a Layer 3 or Layer 2 level, we bundle the whole packet up and put it inside a new IP packet we can forward on anywhere regardless of what’s insude, until it gets to the eNB the UE is on when it can be unpacked and sent to the UE, which is unaware of all the steps / hops it went through.
The concept is very similar to GRE to a VPN (PPTP, IPsec, L2TP, etc) where the user’s IP packets are encapsulated inside another IP packet.
We encapsulate the data using GTP – GPRS Tunneling Protocol.
From a Layer 3 perspective the fact the contents of the GTP packet (another IP packet) is irrelevant, and it’s just handled like any other IP packet being sent from the P-GW to the S-GW.
Getting traffic to the UE
When a packet is sent to the UE’s IP Address from an external destination, it’s first sent to the P-GW, as the P-GW manages that IP prefix.
The P-GW identifies the packet as being destined for a UE, so it encapsulates the entire packet for the UE, by wrapping it up inside a GTP packet.
UE’s IP Packet encapsulated by the P-GW and sent to the IP of the S-Gw
The P-GW then forwards the GTP packet to the serving Serving-Gateway (S-GW)’s IP Address, so the S-GW can forward it to the eNB to get to the UE.
(The P-GW forwards the traffic to the S-GW so the S-GW can get it to the correct eNB for the UE, the reason for having two nodes to manage this is so it can scale better)
Once the traffic gets to the the eNB serving the UE, the eNB de-encapsulates the data, so it’s now got an IP packet with the destination IP of the UE.
It takes the data and puts it onto a transport block sent to the specific RNTI of the UE.
The hops between the UE and the P-GW are transparent to the UE – it doesn’t see the IP Address of the eNB or the S-GW, or any of the routers in between.
The problem is when it comes time to add a new UE to an eNB, the UE needs to be allocated a resources to be allocated a RNTI so it can request / be allocated resources.
In the uplink a group of resources is reserved so any new UE can indicate it’s presence and be assigned an RNTI, so it can go on to request & be allocated resources.
This is done on the Physical Random Access Channel (PRACH), made up of 6 resource blocks, and occurs every 1-20ms depending on what the operator has configured.
Access to the PRACH is by CDMA (Code Division Multiple Access). Without going into the mechanics of CDMA the important thing to note is that on CDMA two transmissions can occur at the same time and as long as they are each using a different one of CDMA’s 64 Codes the eNB will be able to distinguish between the two transmissions.
When attempting to associate the UE will send a CDMA symbol with one of the 64 CDMA sequence codes across all 6 resource blocks. As we discussed the eNB will still be able to determine the code used even if multiple UEs were transmitting at the same time each hoping to associate with the eNB.
UE Attach and RNTI Assignment
The UE begins by listening to the eNB to identify when the Physical Random Access Channel (PRACH)is scheduled.
Once the UE knows when the PRACH is going to be it transmits one of the 64 possible CDMA codes on the PRACH in all 6 of the resource blocks in the Random Access Channel.
The eNB detects the transmission and which one of the 64 CDMA codes was used by the UE wishing to attach, and the eNB assigns it an RNTI.
At this point only the eNB knows the RNTI, it needs to let the UE know it’s assigned RNTI so it can start scheduling.
The eNB creates a new identifier RA-RNTI or Random Access – RNTI. This is calculated using the CDMA code used by the UE in it’s transmission on the PRACH and the RNTI to be assigned.
The eNB then allocates a resource for that RNTI so the UE can send a response back in the form of a Connection Request containing the TMSI.
The eNB then echos back the connection request on the channel allocated to the RNTI.
The echo procedure means if two UEs happened to use the same CDMA Code and both believed they were the owner of the RNTI assigned by the eNB, the eNB would either have received only one of the responses, in which case the other would detect the wrong identity in the echo and start the random access procedure again, or both would be lost and both would start the random access procedure again, as shown below:
As we can see the eNB recieved TMSI1’s Connection Request, and sent back the echo, TMSI one confirmed it and continued the setup procedure, while TMSI2’s Connection Request was not received by the eNB and it knows this beacuse the echo did not contain it’s TMSI. TMSI2 detects thew wrong identity and stops that process and starts the random access procedure again.
The Radio Link Control (RLC) layer sits above the MAC layer and can manage:
Re-sequencing of blocks held up by HARQ
Concatenates / segments messages to fit into the size defined by the MAC layer
Re-transmits lost blocks (independent of ARQ)
These functions are set out and managed based on which of the 3 RLC Modes used based on QoS requirements of the traffic type.
RLC Modes
RLC has 3 services or modes that can be used depending on the type of data transmitted:
Transparent Mode (TM)
Does not offer any RLC features / services
Can only be used for short messages (As no segmentation to fit MAC requirements)
Mainly used for signaling messages
Unacknowledged Mode (UM)
Re-Sequences data if received out of order
Segments data according to MAC needs / limitations
Low latency but no re-transmission on the RLC layer
Suitable for VoLTE / real time communications
Does not re-transmit lost packets
Acknowledged Mode (AM)
Like UM but adds re transmission of lost packets
Higher latency but more reliable
Suitable for web browsing, file transfer, etc.
Upon valid receipt of a message the receiver sends an ACK on the data channel.
Several different RLC modes/services can be used at the same time by a single UE, as we saw in the last post:
The MAC layer takes packets from each of the different RLC streams and packs them into MAC SDUs.
Here we can see 3 different RLC SDUs being packet into MAC SDUs.
RLC SDU 1 is packed into the a RLC PDU along with RLC SDU2. These two are concatenated together. RLC also adds a header to delineate the start of RLC SDU 1 and the start of RLC SDU 2.
The header allows the receiver to determine where each RLC SDU starts and ends and the sequence number of each RLC SDU.
Part of RLC SDU 3 is also packed into the first RLC PDU, and the second part is packed into the next RLC PDU. RLC is said to have segmented or fragmentedthis message as it splits it across multiple RLC PDUs for transmission. Again the RLC PDU adds headers to define that the data it contains is split across multiple RLC PDUs.
The MAC layer (Media Access Control) handles error correction, and performs multiplexing of services to the same UE at the same time (multiplexing).
Automatic Repeat Request (ARQ)
When data is sent a CRC (Cyclic Redunancy Check) is added, containing a checksum equivalent of the data contained in the message.
The receiver runs the same CRC calculation on the data, and if the CRC value is not equal to the CRC value it received it knows the data is not correct/complete.
There are 3 scenarios shown below:
Scenario 1 – Data is sent and the CRC calculated by the sender matches the CRC calculated by the reciver. An ACK is sent to confirm the data was received correctly.
Scenario 2 – Data is sent and the CRC calculated by the sender does not match the CRC calculated by the receiver. The receiver sends a NACK (Negative Ack), The sender sends the data again, the CRC this time matches, so an ACK is sent to confirm the data was received correctly.
Scenario 3 – Data is sent by not ACK or NACK was received. This could mean the data was not received, or the ACK/NACK was not received. The sender then sends the message again. This process is repeated a set number of times after which if no response is received the sender gives up.
Acknowledgement
This technique is called Send and Wait ARQ, because the sender must send the data and wait for an ACK/NACK, and will automatically request re-transmission.
Because CRC may take some time to calculate the ACK/NACK is given time to process by the receiver and the ACK/NACK is sent 4ms after it was received.
If a NACK is received the data is re-transmitted 4ms after receipt of the NACK.
This means all up it takes up to 8ms (8 subframes) to send the data, wait for the response and send again if needed. During this time no other data would be sent.
As you can imagine this isn’t a particularly efficient use of time or resources, so the EUTRAN specs define 8 Send and Wait processes in parallel.
While the first process is blocked waiting for an ACK/NACK, another process can transmit. This is called Parallel Send and Wait.
The problem with this is it can lead to data being received out of sequence, as if data is sent and a re-transmission is needed (NACK received by sender) that data will be received after the data sent 8 frames after it.
Here we can see Block 2 was lost, a NACK was sent and a re-transmission occurs 8 subframes later, long after Block 3 and Block 4 were received.
The MAC layer does not deal with re-sequencing, this is managed by the RLC layer above the MAC layer.
Hybrid ARQ
LTE relies on Hybrid ARQ. To increase redundancy and increase the possibility of decoding a corrupted message correctly.
We talked about coding – sending multiple copies of the same data and comparing them to find the common features that would indicate correct data, Hybrid ARQ functions in much the same way.
To increase error correction performance the receiver keeps the invalid/corrupt messages it sends a NACK for, so it can compare it to the re-transmitted version and hopefully correctly decode the message even if the re-transmission is corrupted.
It is called Hybird because the MAC layer has to communicate to the physical layer to let is know this is a re-transmission and not a new transmission.
Multiplexing on the MAC Layer
You may use your smartphone (UE) for a voice call while looking up something online and getting push notifications, while these are 3 distinct streams of data, there is only one stream of data to and from the eNB <-> UE.
These different types of data all need to be combined into one “pipe” between the eNB and UE, this is known as multiplexing.
The RLC layer has multiple types of data arranged in logical channels, but this data has to be put into a MAC PDU and sent over the air.
In the standard networking model, data in an upper layer is called SDU “Service Data Units”, and data in a lower layer is called a PDU “Protocol Data Units”.
To form the transport blocks the MAC layer must take each of the SDUs from the RLC layer, and put it into the transport block, as show in the image above.
The MAC header contains the delineation of what data is for which SDU on the RLC layer.
To inform UEs of which resources are allocated to it, the eNB regularly publishes Allocation Tables with this information.
Resources are allocated dynamically, by the eNB to all the UEs it is serving.
Because the eNB manages all the resources, the eNB must inform the UEs which resources are allocated to which UEs.
This is broken into two functions:
A UE must be able to be informed it’s going to receive data (downlink) and be allocated the resources for it.
A UE must be able to request resources from the eNB to send data (uplink) and be allocated resources for it.
The eNB manages all resource allocation, for downlink and uplink, when they are needed. This is done through an allocation table published by the eNB every subframe (1ms).
There are two allocation tables – One for uplink, one for downlink.
Addressing on the Radio Interface – RNTI
As an allocation table needs to allocate resources to each UE it needs a way to address them.
GUTI, IMSI, TMSI etc, are all too long (allocation tables are published every subframe so need to be a small as possible).
Instead for addressing in the allocation tables as RNTI – Radio Network Temporary Identifier is issued by the eNB to each UE it is serving, the RNTI is issued by the eNB and only valid for that cell, if the user moves to another cell served by another eNB another RNTI is allocated by that eNB.
The RNTI is 16 bits long, meaning it can store 65,536 decimal values. (65,536 UEs)
Allocation on Downlink
Resource allocation for the downlink is managed by the eNB, which publishes allocation tables every subframe defining which resource blocks are allocated to which UE.
The resource blocks contains the RNTI of each UE to receive data and the resource blocks it’s data will be contained in.
Each UE listens for the allocation tables published in each subframe, and if the UE sees it’s own RNTI in the allocation table it listens on the resource blocks allocated to it.
In the example above we can see the allocation table in the dark blue colour, published every 1ms (aka every subframe).
In this example the UE that has been assigned RNTI 63 (represented in green) has got resource blocks 12 & 13 assigned to it, so will listen on 12 and 13 to get it’s downlink data.
Because UEs only listen for the allocation tables and the resource blocks assigned to them, it leads to power savings on the UE as they don’t all need to listen / decode to all resource blocks. Power savings on the UE translate to better battery efficiency.
The UE with RNTI 61 for example, does not get allocated any resource blocks in the downlink in the example allocation table, so it listens for the allocation table and then goes into standby mode until the next allocation table is published.
The allocation tables are contained in the Physical Downlink Control Channel (PDCCH) a channel used only by the eNB to broadcast resource allocation tables and control data.
The actual downlink data for each UE is contained in the Physical Downlink Shared Channel (PDSCH)
Allocation in the Uplink
Allocation in the uplink is similar to allocation in the downlink, however there are some important differences.
The UE must request the resources from the eNB and wait for them to be allocated in the next uplink resource block.
There is a 4ms delay between a resource block being allocated in an allocation table by the eNB for the uplink and it being used by the UE to send data. This gives the UE time to get the data ready to go into the resource block.
The UE requests a resource from the eNB (covered later) and the eNB publishes an allocation table in the next subframe, however this allocation table is to be used in 4 subframes time.
The UE then buffers this allocation table and uses it in 4 subframes time.
By having this delay in using the resource table / allocating resource tables in advance, it allows our UEs to prepare the message for transmission, encode it, modulate it, etc.
The image below shows the UE in red requesting a resource for uplink from the eNB, the eNB then publishes the allocation table for 4 subframes time, the UE waits for 4 subframes to pass and then the UE transmits using the resources allocated in the allocation table published 4ms prior.
For example in the image below the UE with the RTNI of 64, represented in light blue, has requested a resource to send data (uplink), the eNB publishes an uplink allocation table in the next subframe, and the UE has then 4 subframes to prepare the data for transmission before sending the data using the resources allocated in the allocation table sent to it 4 subframes prior.
Like in the Downlink, Uplink transmissions are managed by a Control Channel and data is contained within a Data Channel.
The Physical Uplink Control Channel(PUCCH) contains the control information and the resource tables for the uplink (to be used in 4 subsframes time), shown in gray.
The data being sent from the UEs is contained in Physical Uplink Shared Channels (PUSCH) allocated 4ms prior in a PUCCH.
When a UE has data to transmit it transmits on the PUCCH to request a resource block for the uplink data.
As spectrum is sparse and expensive, so it must be used wisely and shared across multiple users.
LTE shares spectrum in both frequency and time.
L
LTE can use bandwidths from 1.4Mhz to 20Mhz, based on the spectrum owned and needs of the area.
Spectrum is divided into sub-carriers, allowing each subcarrier to be allocated to a different user, and these subcarriers are re-allocated by the eNB based on the terminal’s needs.
Resource Element (RE)
A Resource Element is the time and frequency a single symbol can be transmitted on.
Resource Elements are allocated by the eNB to UEs and the UE transmits on it’s allocated resource element one symbol.
The size of the data in the symbol is defined by the MCS used.
One Resource Element is contained within 1 subcarrier of 15kHz lasting 66μ s.
Resource Blocks (RB)
Because resource elements are so small, they’re managed in Resource Blocks.
Each Resource Block lasts 0.5ms with 12 sub carriers on each, allowing for 84 Resource Elements in per Resource Block.
The number of Resource Blocks that can be used is determined by the spectrum available.
As we can calculate a Resource Block occupies 180kHz of bandwidth, how many Resource Blocks we can have is determined by how many will fit into our bandwidth.
A system using the minimum bandwidth of 1.4Mhz will have 6 RBs available (1.4Mhz divides into 6 complete 180kHz RBs), while one using the maximum of 20Mhz will have 100 RBs available.
Not all the REs in an RB can be used by terminals though, many of them are reserved for LTE control channels.
The purple and red blocks are reserved as control channels
Meaning only the white REs shown above can be filled with user traffic.
Sub-Frame
Every 1ms (or 2 Resource Blocks) LTE reallocates the RBs to the terminals that need to communicate.
This means Resource Blocks are allocated in pairs, called a subframe, lasting 1ms.
Subframe, RB, RE Hierarchy
Each subframe is 1ms long and made up of 2 0.5ms Resource Blocks.
Each Resource Block contains 84 Resource Elements, each of which contain one symbol of data.
Resource Allocation in Uplink
When a device needs to transmit data it is allocated one or more resource blocks.
If the number of resource blocks is not enough it can be allocated more in the next subframes.
The amount of data a device can transmit in each subframe is called a Transport Block and is made up of the number of RBs and the modulation (MCS) used.
Table of MCS vs Resource Block Pairs (Subframes) and resulting data throughput rate in bits
The sub frame containing contain data for various terminals is shown below in different colors.
Transmission Chain
Transport Blocks are filled with data based on the Transport Block size.
CRC is added to detect errors.
Data is encoded to help recover data containing errors. (Defined by MCS)
Data is modulated (Using modulation scheme defined by MCS)
Data is transmitted in the user-data part that has been allocated in one or more Resource Block Pairs.
The E-UTRAN relies on Phase Shift Keying to modulate data.
The downlink uses orthogonal frequency division multiplex (OFDM) while the uplink uses SC-FDMA due to OFDM’s high peak-to-average-power ratio making it unstable for uplink due to power consumption requirements.
Binary Phase Shift Keying (BPSK)
The simplest modulation is Binary Phase Shift Keying, allowing the phase to be left unmodified to encode a 0, or offset by 180 degrees (aka π) to transmit a 1.
While each bit of data is being transmitted, the time it is being sent over the air is referred to as the symbol length.
2 Phase States of BPSK
Quaternary Phase Shift Keying (QPSK)
QPSK adds to additional phase states, to allow us to send twice as much data in one symbol.
This is done by defining more than two states (phase unmodified, phase offset by pi), but rather 4 states:
Data
Phase Offset
00
π/2
11
5π/2
01
3π/2
10
7π/2
This means we can transmit double the number of bits in a single symbol, with QPSK we can now transmit 2 bits per symbol as per the table above.
This means the data rate of QPSK is twice that of BPSK.
4 phase states of QPSK
BPSK vs QPSK
Thanks to interference, drift, Doppler shift etc, our modulated data probably isn’t going to be received at exactly the same offset that it was sent.
So because our phase shift isn’t going to land exactly on the red dot in the circle, but somewhere nearby.
The receiver will determine the phase of the signal based on it’s proximity to a known phase shift angle.
Because QPSK has more phase states than BPSK we get a higher data rate, but as the recieved data isn’t going to be exactly the phase offsets defined, the states may overlap and the receiver will not receive the correct information
BPSK vs QPSK
Channel conditions restrict the modulation techniques we can use. BPSK is slower but more reliable, while QPSK is faster but more error prone due to it’s lower tolerances.
Transmission Reliability
Error Correction is needed in LTE to make sure the message can be reconstructed correctly by the reciever.
To do this, in a simple form LTE adds redundant data.
For example sending 3 copies of the data increases the chance one will get through correctly, and provides the receiver with information to discriminate the right data.
(If only two copies were sent to increase the reliability, the receiver wouldn’t know which one was the correct one.)
Let’s take an example of sending the message “Hello World” and look at the 3 copies sent.
Copy 1: Helso Wdrld
Copy 2: H1llo Worlp
Copy 3: qello Uorld
Correct Data: Hello World
By looking at what’s common we can see that the first letter is H in the first to copies, but not in the third copy, so we can say with some surety that the first letter is H.
The second letter is e in copy 1 and copy 3, so we can again say the second letter is e.
This is a simplified example of coding the data with redundant data to aid in reconstruction.
The ratio of useful information / total transmitted is called the coding rate.
LTE coding rates can vary from 1/3 for extensive error correction, to close to 1 for almost no error correction.
Modulation Coding Scheme (MCS)
As channel conditions change continuously for each terminal/UE, LTE has to change the modulation technique and coding rate dynamically as channel conditions change for each terminal/UE.
The Modulation Coding Scheme is the combination of modulation and coding scheme used, and this changes/adapts in real time based on the signal conditions, independently for each terminal/UE.
There are 29 MCS combinations in LTE.
Want more telecom goodness?
I have a good old fashioned RSS feed you can subscribe to.
