top button
Flag Notify
    Connect to us
      Facebook Login
      Site Registration Why to Join

    Get Free Article Updates

Facebook Login
Site Registration
Print Preview

An introduction to the LTE MAC Scheduler

+1 vote

LTE brought a completely new network architecture and managed to revolutionize the data capabilities ever achieved on a mobile network. LTE also brought a new type of radio network, much simpler in its organization. In a previous post we discussed about OFDM being the main reason behind LTE’s high data speed. Today we look into an essential component of the LTE radio network: the MAC Scheduler.

Sitting just above the Physical layer, the MAC Scheduler assigns bandwidth resources to user equipment and is responsible for deciding on how uplink and downlink channels are used by the eNodeB and the UEs of a cell. It also enforces the necessary Quality of Service for UE connections. QoS is a set of rules that come from the Policy and Charging Rules Function (PCRF in the core network. These rules define priority, bit rate and latency requirements for different connections to the UE. They is usually based on the types of applications using the UE connection. For example, the QoS requirements for a VoLTE call are different from those for checking the e-mail.

As seen in the image below, the MAC scheduler has control over the OFDM modulation in the sense that it decides, according to information received from other LTE network components, how much bandwidth each UE receives at any given moment. In this figure, the resource element (sub-carrier) is represented on the frequency axis, while the sub-frames are represented on the time axis.

mac_scheduler1This figure shows downlink scheduling, but the MAC Scheduler controls uplink scheduling in a similar way.

In order to take its resource allocation decisions, the MAC Scheduler receives information such as:

  • QoS data from the PCRF: minimum guaranteed bandwidth, maximum allowed bandwidth, packet loss rates, relative priority of users, etc.
  • messages from the UEs regarding the radio channel quality, the strength or weakness of the signal, etc.
  • measurements from the radio receiver regarding radio channel quality, noise and interference, etc.
  • buffer status from the upper layers about how much data is queued up waiting for transmission


Typically, a MAC Scheduler can be programmed to support one scheduling algorithm with many parameters.

Here are some examples of scheduling algorithms:

  • Round Robin – used for testing purposes and uses equal bandwidth for all UEs without accounting for channel conditions
  • Proportional Fairness – tries to balance between the QoS priorities and total throughput, usually preferred in commercial networks
  • Scheduling for Delay-Limited Capacity –  guarantees that the MAC Scheduler will always prioritize applications with specific latency requirements
  • Maximum C/I – guarantees that the Mac Scheduler will always assign resource blocks to the UE with the best channel quality

One of the key features of LTE is the ability to control and prioritize bandwidth across users. It is the MAC scheduler that gives LTE this capability.

posted Jul 30, 2015 by Gratiela D

  Promote This Article
Facebook Share Button Twitter Share Button Google+ Share Button LinkedIn Share Button Multiple Social Share Button

Related Articles

GTP stands for the GPRS Tunneling Protocol and is used to encapsulate user data when passing through core network and also carries bearer specific signalling traffic between various network nodes.

Functionality Of GTP
- It provides mobility. When UE is mobile, the IP address remains same and packets are still forwarded since tunneling is provided between PGW and eNB via SGW
- Multiple tunnels (bearers) can be used by same UE to obtain different network QoS
- Main IP remains hidden so it provides security as well
- Creation, deletion and modification of tunnels in case of GTP-C

Types of GTP Protocol
Type of GTP

Various GTP Interfaces in LTE

GTP-C - Version 2
GTP-U - Version 1

In LTE network GTP-v2 is used on S5 and S11 interfaces and GTPv1 is used on S1-U, S5, X2-U interfaces (as shown below). In inter-RAT and inter PLMN connectivity, S3, S4, S8, S10, S12 and S16 interfaces also utilize GTP protocols
GTP Interfaces

GTP-U encapsulation of UE user plane traffic can be understood by following example. Lets see what happens when IP packet generated by UE reaches to eNodeB and is then forwarded to SGW.

Consider any application on UE creates an IP/TCP packet. This packet consist of actual data by application, TCP or UDP header and then IP field information which has source address of UE and destination address of application server (e.g. Twitter)

When the eNodeB receives this packet over air interface, it will put the IP packet inside GTP header which has information related to tunnel IDs. Then further, it is encapsulated inside UDP and IP header and forwarded as ethernet frame towards SGW. Here the IP header contains eNodeB IP as a source address and SGW IP as a destination address

As GTP-Cv2 in LTE is used for tunnel management, some of the signalling messages cab be seen in the following figure -


GTP' (GTP prime)
GTP' uses the same message structure as GTP-C and GTP-U, but has an independent function. It can be used for carrying charging data from the charging data function (CDF) of the LTE network to the charging gateway function (CGF) over a Ga Interface.


The P-CSCF is the single point of contact in the control plane for an IMS, When the user User Equipment (UE) trying to make a call. All SIP messages sent by the UE must pass through the P-CSCF towards the other IMS elements. It can be located either in the visited network (in full IMS networks) or in the home network (when the visited network is not IMS compliant yet).

The UE attaches to the P-CSCF prior to performing IMS registrations and initiating SIP sessions.

For attachment to a given P-CSCF, the UE performs the P-CSCF discovery procedures. Attachment to the P-CSCF is necessary for the UE for initiating IMS registrations and sessions.

enter image description here

Before sending any Session Initiation Protocol (SIP) requests, the UE must perform “P-CSCF discovery”, the process of identifying (by address) the correct Proxy-Call Session Control function (P-CSCF). The P-CSCF address may be discovered in one of three different ways:

  1. It may be stored in the IP Multimedia Services Identity Module (ISIM).
  2. The UE may request it as part of the PDN connectivity request during the Attach process.
  3. The UE may request an IP address and fully Qualified domain Name (FQDN) from a DHCP server and then perform a DNS query on the returned IP address and FQDN.

In these procedures, the UE first establishes the IP connectivity access network (IP-CAN) bearer. Then, the UE sends a query to the DHCP server for retreiving the IP addresses and FQDN (Fully Qualified Domain Name) of the P-CSCF. After the DHCP query, the UE performs a DNS query on the FQDN received from the DHCP server. In response to the DNS query, the IP address of the P-CSCF is returned. This is known as the DHCP-DNS procedure for P-CSCF discovery. However, in some cases, it may be possible that the FQDN of the P-CSCF is pre-configured in the UE. In these scenarios, the UE can directly query the DNS server and get the IP address of the P-CSCF.

enter image description here

Subsequent to P-CSCF discovery, the UE can send a SIP REGISTER request to register itself in the IMS core network. The P-CSCF sets up IPSec security associations with the UE, which are facilitated with the two-way registration handshake (i.e. REGISTER-401-REGISTER-200 OK). The IPSec security assocaiations (SAs) setup four protected ports between the UE and the P-CSCF and ensure that all subsequent signaling traffic passes through the protected ports. The four protected ports negotiated during IMS registration are: The protected server port at the P-CSCF, the protected server port at the UE, the protected client port at the P-CSCF and the protected client port at the UE. The Protected client ports are used by the UE and P-CSCF to send requests while the server ports are used to receive incoming requests. IMS registration will be discussed seperately in another post.

The P-CSCF also translates the SDP body contained in the SIP INVITE message from the UE into DIAMETER over the Rx interface and sends it to the PCRF. The PCRF is responsible for policy control in the IMS core network. If the SDP offer contains a codec or any other media characteristics that are not allowed as per the policies of the IMS operator, the operator can choose to disallow that session setup.


Customized Applications for Mobile Network Enhanced Logic (CAMEL):

CAMEL was developed as a standard for mobile intelligence across different vendor equipments for GSM network. What this means is that the end user should be able to roam between different networks (maybe in different countries) and be reachable at the same number and should receive only one bill from the original service provider (Home Operator).
The CAMEL is a network feature and not a supplementary service. It is a tool for the network operator to provide the subscribers with the operator specific services even when roaming in the another network.

The CAMEL protocol supports these mobile-calling operator-provided services: originating and terminating phone calls, charging features, prepaid minute usage, and personal subscriber options such as voice-mail prompts, recorded messages and ringtones.

The CAMEL protocol ensures that if the caller accesses another mobile operator's towers or equipment, his services remain the same as if the caller accessed his own operator's towers or equipment. And, the minutes used and the services rendered will only be billed once by the caller's own operator. This network system applies to GSM operators all over the globe.

The CAMEL protocol does not apply to Emergency Setup. If a mobile user dials 911 while roaming, the CAMEL protocol is disabled. This ensures that the caller is routed to the local emergency response system and not to services in his home calling area.

Applicability of CAMEL procedures:
1. The CAMEL feature is applicable to Mobile Originated and Mobile Terminated Call Related Activities.
2. CAMEL procedures are applicable to all circuit switched basic services without distinction (except Emergency calls).
3. The CAMEL feature is applicable to Supplementary Services Invocation
4. CAMEL procedures are applicable to GPRS sessions and PDP contexts
5. CAMEL procedures are applicable to Mobile Originating/Terminating short message service through both circuit switched and packet switched serving network entities
6. CAMEL procedures are applicable to IP multimedia services (except Emergency calls) to support legacy services
7. CAMEL shall support IPMM sessions which are based on the same charging paradigm as CS/PS calls. 8. This applies most probably to VoIP and Video over IP.
9. CAMEL procedures are applicable to IP multimedia sessions addressed by either E.164 numbers or SIP URLs.

Example of CAMEL procedure:

enter image description here

Take a simple scenario of a voice call being made. When a subscriber starts to make a call, this request is received by the network's Mobile Switching Centre (MSC). The MSC then sends a message that 'queries' the SCP's database. Note that the essential element of any CAMEL solution is a Service Control Point (SCP). This unit effectively hosts a database which holds the instructions needed for an intelligent application.

The SCP processes that query, comes up with an appropriate response and then sends a message back to the MSC telling what action it should take with the subscriber’s request for a specific service. The call is then connected in the most appropriate manner, a process which is transparent to the customer. A very good example of this process in action is short code dialling over a VPN (Virtual Private Network) where the user calls a colleague’s internal extension telephone number but is, in fact, routed to that person’s mobile phone which is roaming abroad.

The main addition in CAMEL phase 2 which phase 1 omitted is support for a Specialised Resource Function (SRF) a component most often found in Voice Response Units (VRUs). For example, when an account balance reaches zero for a pre-paid customer under phase 1, the customer will simply be cut off. With phase 2 thanks to support for SRF, the customer will hear automatically generated messages from the Voice Response Unit warning that the balance is dangerously low before a call and even during the call. Naturally this leads to greater customer satisfaction.

Contact Us
+91 9880187415
#470/147, 3rd Floor, 5th Main,
HSR Layout Sector 7,
Bangalore - 560102,
Karnataka INDIA.