Medium Access Control (MAC) Protocol

The MAC layer provides services through SAPs to the upper layer as all other sublayers of layer 2. The layer above MAC is the RLC layer; the lower layer is the physical layer which provides services to the MAC. In the case of the MAC, SAPs to the RLC layer are logical channels. Logical channels are used by higher layers to differentiate between logical connections which may use different metrics, for example, in terms of quality or delay, and so on. Furthermore, logical channels are used to distinguish control plane connections, either CCCHs or DCCHs, from user plane connections (DTCHs).

Services provided by the physical layer to the MAC layer are granted via another type of SAP. SAPs between the MAC and the physical layer are transport channels. Transport channels match data units to physical channels in which data is supposed to be transmitted. One exception is the PCH which is multiplexed into the PDSCH identified with the P-RNTI =0xFFFE.

Multiplexing of data units from logical channels to transport channels is one of the tasks of the MAC layer. Logical channels are differentiated with LCIDs. Tables 1 and 2 show the defined LCIDs and their values for DL and UL respectively. A CCCH always has LCID =0. Other UE dedicated channels start with LCID = 1.

Table 1: Values of LCID for DL-SCH. 

Index	LCID values
00000	CCCH
00001–01010	Identity of the logical channel
01011–11011	Reserved
11100	UE contention resolution identity
11101	Timing advance command
11110	DRX command
11111	Padding

Table 1.21: Values of LCID for UL-SCH. 

Index	LCID values
00000	CCCH
00001–01010	Identity of the logical channel
01011–11001	Reserved
11010	Power headroom report
11011	C-RNTI
11100	Truncated BSR
11101	Short BSR
11110	Long BSR
11111	Padding

A MAC PDU consists of a MAC payload part and a MAC header part. The MAC payload conveys multiple units of MAC control elements and MAC SDUs from higher layers. Therefore, the MAC header is also divided into sub-headers depending on the units carried in the MAC payload as MAC sub-headers describe the MAC payload units. There are various possible combinations of MAC control elements, MAC SDUs, and MAC padding derivatives. An example of a MAC PDU with a combination of MAC sub-headers, MAC control elements, and MAC SDUs in the payload section is depicted in Figure 1.

Figure 1: Example of MAC PDU consisting of MAC header, MAC control elements, MAC SDUs, and padding (TS36.321). Reproduced with permission from © 3GPP^™

Logical channels which are multiplexed to transport channels are prioritized by the scheduling algorithm. The scheduling algorithm decides what to schedule on which physical resources as described in detail for DL scheduling. There is only one MAC entity per UE; thus, the UL within the UE has one MAC entity and the eNB executes multiple parallel MAC entities in the DL direction in case the eNB has to handle multiple UEs.

The MAC layer implements a soft combining N -process stop-and-wait FEC and detection mechanism, or HARQ (Hybrid Automatic Repeat Request). Transport blocks are protected with a FEC algorithm known as turbo codes. Soft combining means not correctly decoded blocks are not acknowledged in order to conduct a retransmission, but the previous received not decoded block is held in a soft buffer to be recombined with the new retransmission. This process of soft combining two or more receptions increases the chance that the last received retransmission can be decoded error-free.

Stream Control Transmission Protocol (SCTP)

Originally the SCTP was defined as a transport protocol for SS7 messages to be transmitted over IP networks. As TCP and UDP it is seen as a layer 4 transport protocol in the ISO OSI model.

The SCTP frames are called chunks. All chunks are associated to a connection that guarantees in-order delivery. However, within the same chunk there might be data blocks of different connections transmitted simultaneously. In addition, it is also possible to send urgent packets "out of order" with a higher priority.

SCTP also supports multihoming scenarios where one host owns multiple valid IP addresses.

Besides the data streams, SCTP frequently sends heartbeat messages to test the state of connection.

How SCTP works will be demonstrated by means of an example. Figure 1 shows the message flow required to transport the NAS signaling message Attach Request from the eNB to MME across the S1 interface.

 
Figure 1: SCTP example

After setting up a RRC connection on the Uu interface between the UE and the eNB, the UE sends the attach request message. When the appropriate RRC transport container is received by the eNB, the establishment of a dedicated SCTP stream on the S1 interface as shown in Figure 2 is triggered.

The establishment of the SCTP stream starts with a SCTP initiation message. It will always be sent by the eNB in the case of the attach procedure, because the RRC connection is established earlier and the request to transport the NAS message triggers the request to have a S1 connection. The SCTP initiation message contains the IP addresses of both the eNB and MME. The individual subscriber for which this connection is established is represented by a unique pair of SCTP source port and destination port numbers.

The SCTP initiation needs to be acknowledged by the peer SCTP entity in the MME. In the next step a SCTP cookie echo message is sent and acknowledged by Cookie Echo ACK. In the protocol world, this is called a heartbeat procedure. Such a procedure periodically checks the availability and function of the active connection. Similar functions with other message names are found, for example, in SS7 SCCP Inactivity Test or GTP Echo Request/Response.

On SCTP higher layer messages are transported using SCTP datagram (SCTP DTGR) packets. Each SCTP DTGR contains a Transaction Sequence Number (TSN) in addition to source and destination address information. This TSN will later be used by the peer entity to acknowledge the successful reception of the DTGR by sending an SCTP selective ACK message on S1 that confirms error-free reception of the SCTP DTGR that carried the attach request message. Further S1AP and NAS messages of this connection will be transported in the same way and the Cookie Echo/Cookie Echo ACKs will be sent periodically as long as the connection remains active.

If the S1 signaling transport layer SCTP has problems in offering proper functionality, there will be no signaling transport on S1 if the problems are located in the eNB SCTP entity. If the MME suffers from congestion or protocol errors on the SCTP level as shown in Figure 1.83, the expected selective ACK messages will be missing (maybe not sent at all, maybe sent with a TSN out of the expected range). This malfunction may be detected by a NACK Cookie Echo and as a result the connection will be terminated. Or the attach accept message expected to be received by the UE will be missed. The missing attach accept message will be recognized by the UE where a timer is guarding the NAS procedures. After the guard timer expires on the UE side the attach request message will be repeatedly sent up to n times (the counter value of n is configurable and typically signaled on the broadcast channel SIBs; the default value recommended by 3GPP is n = 5). If neither an attach request message nor an attach reject message is received by the UE the handset will go back to IDLE when the maximum number of attach request repetitions has been sent.

 
Figure 2: Failure in SCTP signaling transport

Internet Protocol (IPv4/IPv6)

The IP frame is called the datagram and there exist two main versions of the IP: IPv4 and IPv6.

IPv4

The IP header has a minimum size of 20 bytes (if no options are used) and a maximum size of 64 bytes (including options and padding bits). Due to a set of different options that can be appended to the IPv4 header, these headers can become very large.

The included information elements shown in Figure 1 are:

• Version: IP protocol version, here IPv4.
• Internet header length (IHL length): The length of the header.
• Type of Service: The QoS parameters for IP.
• Total Length: The length of the IP frame including header and payload field.
• Identification, Fragment Offset: Both used in case of fragmentation/reassembly.
• Time to Live: A hop counter to prevent circular routing.
• Protocol: Indicates the higher layer protocol that uses IP as the transport layer; typical examples are ICMP, TCP, UDP.
• Source Address: IP address of the sender of the datagram.
• Destination Address: IP address of the receiver of the datagram.
• Options: For example, the timestamp of each router that the IP packet passed.
• Padding: Fill bits to align the header to a multiple of 32 bits.

 
Figure 1: IP datagram structure

Since the maximum packet size of an IP datagram can vary from one local network to the next, the IP is equipped with fragmentation/reassembly functionality that allows the transmission of larger frames in series of smaller portions. Figure 2 shows an example where a frame with 1600 bytes of data is fragmented into two smaller frames with 1480 and 120 bytes of data each. Fragmented frames do all have the same frame ID (in the example: 1234). As long as more fragments are following the first one, the fragmentation flag MF is set to "1." The last frame in a series of fragments has fragmentation flag MF = "0," but a fragmentation offset that is required for proper reassembly on the receiver side.

 
Figure 2: IP fragmentation

IP fragmentation (Figure 2) may be found in the user plane data streams, but should be avoided on interfaces that carry 3GPP signaling.

IPv4 addresses are typically written in the so-called dotted decimal notation, for example, 195.24.1.2. There are 32 bits (= 4 bytes) reserved for the address fields in the IP datagram. Each number in the dotted decimal format represents the decimal value of a single byte. The dot "." is used as the separator between the different bytes of the IP address. Figure 3 shows a sample address in binary, hexadecimal, and decimal dotted notation format.

 
Figure 3: Example of IPv4 address format

 

IPv6

The most important improvements that come with IPv6 are:

• A larger number of possible address values become available. In IPv4 the number of addresses is limited to 32 bits, which means in turn that 2³² (≈4.3 billion = 4.3 × 10⁹) possible values can be addressed. IPv6 provides space for 2¹²⁸ (=3.4 × 10³⁸) possible address values. This is an improvement by a factor of 2⁹⁶ and reached by a restructuring of the IP header. In the IPv6 header shown in Figure 4, 128 bits (16 bytes) is reserved for source and destination addresses. The larger address ranges available for IPv6 will also allow more direct end-to-end packet routing and, hence, less address translation in network nodes is required and the packet routing in the overall network is expected to be faster and more efficient.
  
  
  
   
  Figure 4: IPv6 header format
• The automatic configuration of dynamically assigned IP addresses is improved and in turn legacy procedures like DHCP (Dynamic Host Configuration Protocol) become unnecessary.
• IPv6 supports Mobile IP, simplifies renumbering (change of dynamically assigned IP addresses), and allows multihoming of subscribers. The purpose of multihoming is to increase the reliability of Internet connections by using two different Internet service providers simultaneously. If the access to one of the providers is interrupted a redirection of packets via the second connection is possible. Mobile IP means that the subscriber always gets the same IP address assigned, no matter if working at home or traveling around.
• IPsec is integrated into IPv6 to achieve a higher security of IP data transmission, while back in IPv4 no security functions were provided at all.
• All in all, the basic header of IPv6 has a simpler structure compared to the header of IPv4. Although the overall header size is larger than in IPv4 (40 bytes, most of them occupied by the longer IP addresses), there are less basic header fields.
• For the version, the decimal number 6 is encoded as binary bit sequence "0110."
• The IPv6 traffic class indicates the packet priority and should not be mistaken for the traffic class QoS element introduced in 3GPP standards that classifies the throughput sensitivity and delay sensitivity of application services. IPv6 traffic class priority values subdivide into two ranges: traffic, where the source provides congestion control, and non-congestion control traffic.
• The flow label is used for QoS management and encoded in 20 bits. Packets having the same flow label value will be treated with the same priority and reliability. This is important for the routing of packets that contain real-time service data.
• The payload length indicates the size of the payload in octets and is encoded in 16 bits. When cleared to zero, the option is a "Jumbo Payload" (hop by hop). The size of the basic header is not counted by the payload length, but the optional header extensions are included. So payload length + 40 bytes (of basic header) = total length of the IPv6 packet.
• The next header information element specifies the next upper layer protocol of the transported payload such as UDP and TCP. The values are compatible with those specified for the IPv4 protocol field (8 bits). The next header information can also point to optional extension headers. In this case the upper layer payload protocol is not indicated by this field.
• The hop limit field (8 bits) indicates the maximum number of routers that are allowed to be involved in routing an IPv6 packet. It replaces the time to live field of IPv4. If the hop limit reaches the value "zero" the packet will be discarded by the router.
• Source and destination addresses, 128 bits each, represent the sender and receiver of the IPv6 datagram.

IPv6 addresses are normally written as eight groups of 16 bits, where each group is separated by a colon (:). For example, 2001:0db8:85a3:0000:0000:8a2e:0370:7334 is a valid IPv6 address.

To shorten the writing and presentation of addresses, several simplifications to the notation are permitted. Any leading zeros in a group may be omitted; thus, the given example becomes: 2001:db8:85a3:0:0:8a2e:370:7334.

Also, one or any number of consecutive groups of value 0 may be replaced with two colons (::): 2001:db8:85a3::8a2e:370:7334.

It is possible to use IPv6 addresses in the URL notation format. In this case the IPv6 address information is enclosed in square brackets:

The brackets prevent that part of the IPv6 address being misinterpreted as port number information. A URL including IPv6 address and port number looks like this:

Ethernet | Protocol Functions, Encoding, Basic Messages, and Information Elements

Ethernet is the typical transport layer protocol in IP networks. It is designed to transmit packets from a sender to a receiver, both identified on behalf of an address information element.

According to this limited functionality, Ethernet has a very small header. The header field (Figure 1) contains only the information elements:

• Destination address.
• Source address.
• Ethernet type.

 
Figure 1: Ethernet header example

Ethernet type is similar to a SAPI (Service Access Point Identifier). It contains information about which higher layer protocol information is transported by Ethernet frames.

The Ethernet addresses, often called MAC addresses (but with nothing in common with RLC/MAC!), consist of 6 bytes. These MAC addresses are fixed hardware addresses and, due to a defined numbering scheme, each address is unique worldwide.

If IP data is to be transmitted using Ethernet the hardware MAC address of the receiver of IP packets is unknown when the connection starts. Only the target IP address is known. However, since Ethernet is the lowest layer of the connection there must be a source and a destination MAC address included in each header. In other words, for each sender IP address there is an appropriate sender hardware address, and for each destination IP address there must be an appropriate target hardware address.

The target hardware address that is related to the target IP address is requested by the Address Resolution Protocol (ARP). Its sister protocol, the Reverse Address Resolution Protocol (RARP), can be used to find the target IP address (or, in terms of ARP/RARP, the target protocol address) to a known MAC address.

The address resolution procedure consists of two steps:

1. ARP request (req) message with Target Hardware Address = "0" is sent to all(!) IP clients in the network.
2. The client that has the target protocol address as set in the ARP req message sends ARP Replay (rpl). The sender hardware address in ARP rpl is the Ethernet MAC address related to the destination IP address that the sender of the ARP req is looking for. An example of the Ethernet address resolution procedure is shown in Figure 2.
   
   

 
Figure 2: Ethernet address resolution

S1 – Control/User Plane

On the S1 reference point the physical layer L1 will in most cases be realized by Gigabit Ethernet cables. L2 in this case will be Ethernet. On top of Ethernet we find IP, but used as a transport protocol between two network nodes: eNB and MME. This lower layer IP does not represent the user plane frames.

Instead, the user plane IP frames (higher layer IP) are carried by the GTP Tunneling Packet Data Unit (T-PDU). The GTP is responsible for the transport of payload frames through the IP tunnels on S1-U. The transport layer for GTP-U is the User Datagram Protocol (UDP). As IP this protocol may be found twice in the user plane stack: lower UDP for transport between the eNB and MME and higher UDP (not shown in Figure 1) that is transparently routed through the mobile network as the transport protocol for real-time application data. The higher layer IP on top of GTP-U as well as all application data on top of this higher layer IP are identical with the user plane information.

 
Figure 1: Protocol stack S1 control/user plane

On the control plane side, the Streaming Control Transport Protocol (SCTP) provides reliable transport functionality for the very important signaling messages. S1AP is the communication expression between MME and S-GW while NAS