Optical Channel Layer

The Optical Channel Layer is the highest level layer and interacts directly with the clients system interface. It also provides the mechanism for transporting the client's digital signal through into the OTH compliant network. The optical channel trail from source to sink composes of two distinct logical signals:  

1.The optical client payload 

2.The  optical channel overhead ( the information added by OTH) 

To provide for end-to-end networking the following capabilities are included:  

•Optical Channel connection rearrangement 

•Processes for ensuring the integrity of the information added by the optical channel – This involves the introduction by OTH standards of bit-error rate evaluation and FEC (forward error correction) 

•Supervisory features for allowing network level management and control – this function involves the introduction of OTH standards for provisioning of connections, quality of service parameter exchange, and link protection schemes for network survivability  

The process required to create an optical channel from client data signal is:  

1.To create the optical channel from the client’s signal through interfacing with a transponder/transceiver in order to generate a continuous data stream that can be modulated onto a carrier wavelength 

2.The generation of management/maintenance signals for the OS overhead 

OTN Functional Architecture

Bearing in mind the goals of the OTH initiative, we can begin to visualize the structure and purpose of the OTN system. It would be predominantly optical delivery, certainly in its transmission path as it would be deployed over WDM. It would also retain one of WDM's advantages that of frame, protocol and bit-rate transparency independently of the client signals processing and transmission. Furthermore, we can see that the OTN model will have to provide telecommunications network management, monitoring and administrative control. Last, but not least, the OTN will provide necessary fault-tolerance, by providing protection mechanisms and link fail-over for redundancy.  

Therefore, the OTN must deliver the following functions on a per-client signal basis:  

•Transport 

•Routing 

•Multiplexing 

•Supervision 

•Survivability 

The OTH Goals

Some of the design goals of the OTH initiative were to provide the following:  

1.Develop a holistic system to handle rapid traffic growth 

2.Develop a system to handle transparently diverse signal types, frames, bit-rates and protocols 

3.To develop management OAM&P features through a supervisory information channel that did not negatively impact payload bandwidth 

4.Preserve the natural transparency and protocol independence of WDM and its inherent advantages 

5.To develop OTN standards – for optical termination, regeneration and cross-connects 

6.To work towards standards that would make full mesh OTN network practical 

Optical Transport Hierarchy

Up until the advent of the OTN initiative, the optical layer had been used simply as a physical medium over which to transmit data. This was primarily because of the impossibility to process optical data without first handling it over to the electrical domain. The OTH principle was seen by many as the first step in rectifying this shortcoming and in attempting to deliver some 'intelligence' to a passive system. Now, the OTH does not rewrite the laws of physics and it is still impossible to process data optically. However not to be deterred by such detail they opted for reserving a specific wavelength in order to use as a management or supervisor channel on which they could transport management information between equipment. Designers deemed this out-of-band supervisory channel a good solution as it did not interfere or unduly affect 

The payload of the underlying system was in contrast to SDH's overhead bytes. The OTH out-of-band supervisor channel would carry the same management information as SDH frames carried as overhead, but without using up precious cargo space in the frames. 

The OTH however would have to face come challenges as WDM differed quite considerable from the SDH framed protocol. For instance, there was no defined frame, DWM was light waves, without any frame structure or protocol and that was one of its strengths. Secondly, SDH handled one signal trail per path whereas WDM would be carrying several client signals per path and each would have to have its own individual management information with regards its own client’s state and fault. 

However, the challenge to delivering the project was easily outweighed by the potential benefits. If the principles of the OTH initiative could be applied to a working WDM out-of-band optical supervisory channel (OSC) then the potential was massive. Optical networks would be able to take on new topologies, such as partial and complete mesh networks using optical add/drop multiplexors, cross connects and optical switches in practical real world deployments. This would be due to the underlying management information being carried across the supervisory channel providing insight into the state of the network at every optical termination point, just like SDH. 

Furthermore, it would be possible to even implement protection and link fail-over as a network reliability measure, again due to having insight as to the link state between each optic termination link. However, the comparisons with SDH don't end there the OSC could also make provisioning of services possible, as it provides the ability to create, delete, and manage a service remotely, as can be done with SDH. 

In short, the OSC would do away with the WDM black-box approach to service management and provide all the SDH style visibility, manageability, flexibility and those precious OAM&P features for which everyone was clamoring.

OTH (Optical Transport Hierarchy)

The OTH (Optical Transport Hierarchy) was the initiative to bring intelligence and OAM&P features to WDM. OTH is the underlying optical multiplexing principles and techniques for aggregating several light wave signals onto a single multiplexed signal, which is then transported as a single signal across a single optical fiber. WDM's operation is independent of the original signals format, frames or bit-rate so it can handle any signal type. However, there are some physical restrictions in the WDM mode of operations.

1.       All the client wavelengths must be different to avoid interference.

2.       All the wavelengths must be sufficiently separated by a distance, a guard gap, to avoid signal cross talk.

WDM's advantage though is that it can take many different wavelengths (client signals) and multiplex them onto a single fiber, which had previously been only capable of handling one wavelength (client signal). This efficiency of resource usage is just one of WDM's beneficial features another is that it can carry transparently any client signal type. For instance client inputs can be from SDH, TDM, IP, ATM or any data stream as it is all transparent to WDM, it concerns itself only with carrying wavelengths.

At this point, it will be good to introduce the term Lambdas as this term is often used to describe a single wavelength. Consequently, the words wavelength and lambdas will be used inter-changeably in this book as the terms are synonymous.  On a similar note, the term OTH (Optical Transport Hierarchy) is used to describe the efforts to the OTH party to standardize the OTN network. However it can also be considered to be interchangeable with the term G.709, which was the resultant standard.

The OTH goal was to apply the principles of OTH design, learned from SDH, with the technology of WDM to provide the basis for a manageable fully meshed optical transport network, the OTN.

Narrowband-Internet of Things (NB-IoT)

The IoT and 5G massive Machine-Type Communications (mMTC) will be a large market in 5G. NB-IoT is a Low Power Wide AreaNetwork (LPWAN) radio technology 4G standard for IoT sensorsand devices to communicate over cellular networks. However,unlike many other characteristics of 5G, NB-IoT is not necessarily designed for speed.

Cat-NB1 uses a channel bandwidth of just200kHz, more akin to the old Global System for Mobile Communications (GSM) standard than the 20MHz of LTE and 100MHz of5G NR.Cat-NB1 and its 5G derivative is the antithesis of 5G enhanced Mobile Broadband (eMBB). It uses the narrowest bandwidth andslowest data rate to lower costs and enable a ten-year (or more) battery life.

Kbps stands for kilobits per second — and one million kilobits equalsone gigabit — a popular measure of speed back when modems used tone-modulated phone signals (accompanied by annoyingscreeching sounds) and people still used the yellow pages.

NB-IoT is designed primarily for IoT sensors and devices. Thelong range, using bands less than 1GHz, allows a vast network of low power sensors, each sending small data reports, to be aggregated efficiently. For these devices, it isn’t critical that the data they transmit is received with ultra-low latency, or that every transmission be acknowledged by the receiver. Thus, NB-IoT is an ideal technology for massive IoT use cases

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

LTE Network Protocol Architecture

Uu – Control/User Plane

The protocol stack used on radio interface Uu is shown in Figure 1. The physical layer in this stack is represented by OFDM in the DL and SC-FDMA in the UL. Then we see the MAC protocol that is responsible for mapping the transport channels onto the physical channels, but also for such important tasks as packet scheduling and timing advance control. RLC provides reliable transport services and can be used to segment/reassemble large frames. The main purpose of PDCP is the compression of larger IP headers as well as ciphering of user plane data and integrity protection of both user plane and control plane data.

 
Figure 1: Protocol stack LTE Uu interface

On top of PDCP the stack is split into the user plane and control plane parts. On the control plane side we see RRC protocol, that is, the expression for the communication between the UE and eNB. RRC provides all the necessary functions to set up, maintain, and release a radio connection for a particular subscriber. 

RRC also serves as a transport protocol for NAS signaling messages. NAS is the expression for the communication between the UE and MME in which MME represents the core network.

On the user plane side we see IP as the transport layer for end-to-end applications. On the Uu stack the IP is always end-to-end IP, which means that all these IP packets are transparently routed, often tunneled through the mobile network. The user plane IP frames we see on Uu are the same IP frames that can be monitored at SGi reference points before or behind the PDN-GW.

The IP version can be Internet Protocol version 4 (IPv4) or Internet Protocol version 6 (IPv6). In the case of VPN (Virtual Private Network) traffic, IPsec will be used.

The applications on top of IP in the user plane stack are all protocols of the TCP/IP suite, such as the File Transfer Protocol (FTP), HTTP (web-browsing), and POP3/SMTP (for e-mail), but also Real-Time Transport Protocol (RTP) and SIP for real-time services like VoIP.

Initial UE Radio Access

Cell search is a procedure for synchronizing time and frequency to a base station sector. Additionally, cell search and synchronization include deriving basic information of the target cell.

LTE defines a hierarchical cell search as it is deployed with WCDMA UMTS. PSS and SSS provide radio frame and slot synchronization, as well as information like the duplex mode TDD or FDD and the physical layer group and c-ID.

UEs synchronizing to a new LTE cell start searching for a PSS which is a Zadoff–Chu sequence. Three sequences are defined indicating the physical cell group ID. Three physical layer c-ID groups with 168 physical layer c-IDs each are defined. After successfully detecting the PSS with its physical layer c-ID group and slot timing, the SSS is decoded which is broadcasted one OFDM symbol prior to the PSS. Now the UE retrieved DL slot, radio frame timing and frequency synchronization. With decoding successfully PSS and SSS, it obtained as well the complete 9-bit physical layer c-ID together with the radio frame type (either type 1 for FDD or type 2 for TDD) and the CP length.

Figure 1 illustrates the initial steps of cell synchronization and access. After synchronization, the UE is ready to detect and decode the PBCH in order to derive the system bandwidth, PHICH configuration, and the current System Frame Number (SFN). Other common system information now needs to be retrieved from the DL-SCH. SIBs are scheduled on regular shared channel resources by using a special C-RNTI = 0xFFFF. SIBs provide general system configuration information like UL configuration and random access configuration.

 
Figure 1: Initial cell access with level of retrieved information

Channel Mapping and Multiplexing

Besides physical and transport channels, LTE also defines logical channels. Logical channels are multiplexed to transport channels within the MAC layer. Logical channels map different content connections to transport channels, like CCCHs to multiple UEs or DCCHs to a specific UE or dedicated transport channels carrying higher layer application data.

Logical channels are addressed with a logical channel ID. The logical ID is a field within the MAC header PDU. Logical channels are multiplexed by using logical channel IDs to transport channels specifying where the information should be transmitted. Finally, transport channels are transferred with physical channels as a service provided by the physical channel.

Figures 1 and 2 show the above-described channel architecture from the basic physical channels via transport channels to logical channels bearing higher layer messages for DL and UL respectively.

 
Figure 1: Downlink channel mapping and multiplexing from logical channels via transport channels to physical channels

 
Figure 2: Uplink channel mapping and multiplexing from logical channels via transport channels to physical channels

Two basic sets of logical channels are defined:

• Control channels: CCCH and DCCHs.
• Traffic channels: CCCH and DTCHs.

The nature of common channels is such that no specific UE is addressed, but the information is either general for all cell-wide subscribers or a message from a UE which has not yet established a dedicated control/traffic channel. A typical example of a CCCH is the broadcast of SIBs.

Traffic channels carry user plane protocols like the Packet Data Convergence Protocol (PDCP) and application IP packets, while control channels carry control plane protocols as RRC and NAS.

• DL logical channels:
  • – Broadcast Control Channel (BCCH).
  • – Paging Control Channel (PCCH).
  • – Common Control Channel (CCCH).
  • – Dedicated Control Channel (DCCH).
  • – Dedicated Traffic Channel (DTCH).
• UL logical channels:
  • – Common Control Channel (CCCH).
  • – Dedicated Control Channel (DCCH).
  • – Dedicated Traffic Channel (DTCH).

Transport Channels in LTE

The physical layer provides a transport service for MAC PDUs. This service is accessed by transport channels. Most transport channels are directly mapped to physical channels. Thus, in other words, transport channels are the gateway to physical channels and a selection for MAC PDUs where they are to be transmitted.

The following DL transport channel types are defined:

• Broadcast Channel (BCH):
  • – Uses a static transport format and has the requirement that all UEs within the cell have to receive its information error-free. The reception of the BCH is mandatory for accessing any service of a cell.
• DL-SCH:
  • – Carries all semi-static broadcast information (SIB) and all UE-specific traffic channels.
  • – DL-SCH is secured with HARQ algorithms.
  • – Efficiency is realized with AMC link adaptation.
  • – Various TMs are defined to meet different environment scenarios to increase efficiency in respect of current conditions.
  • – DRX is available in order to increase handset operating time.
  • – Makes use of spatial algorithms like beamforming or MIMO.
• Paging Channel (PCH):
  • – Needs to be received in complete cell coverage area.
  • – Supports DRX in order to increase battery operating cycle.
  • – Dynamically allocated via own physical identifier (P-RNTI).
• Multicast Channel (MCH):
  • – Broadcast to entire cell coverage area.
  • – MBMS transmission with use of multiple cells.

A designated DL control channel is not defined as the PDCCH is used for physical channel control only. All the higher layer control plane is transmitted via the DL-SCH.

Defined UL transport channel types are shown in the following items:

• UL-SCH:
  • – UL-SCH is secured with HARQ algorithms.
  • – Fully dynamic and semi-static resource allocation schemes.
  • – Can make use of multi-user MIMO (UL "virtual" MIMO).
  • – Uses dynamic link adaptation like AMC.
• RACH:
  • – Accessible without UL synchronization.
  • – Collision-based and collision-free operating modes.
  • – Various modes depending on cell size and interference.

As in the DL direction, no UL control transport channel is defined as all the higher layer control plane is transmitted on the UL-SCH. The PUCCH is a control channel used by the physical layer only.