1 © 2006 nokia esitelma.ppt / 2006-05-09 / jh seminar presentation implementation of mac-c protocol...

1 © 2006 Nokia esitelma.ppt / 2006-05-09 / JH

Seminar Presentation

Implementation of MAC-c Protocol for an Improved UMTS Internet Access

Juhani Hietikko9.5.2006

Thesis done at the Signal Processing Systems unit of Nokia Networks

Supervisor Professor Jörg Ott

Instructor M.Sc. Antti Lehtonen


Contents

• Abbreviations

• Introduction

• The MAC-c protocol

• Software design

• Algorithms

• Evaluation results

• Conclusions


Abbreviations

• Medium Access Control (MAC)

• UMTS Terrestrial Radio Access Network (UTRAN)

• Internet High Speed Packet Access (I-HSPA)

• Digital Signal Processor (DSP)

• Paging Channel (PCH)

• Forward Access Channel (FACH)

• Random Access Channel (RACH)

• Uplink (UL)

• Downlink (DL)

• User Equipment (UE)

• Transport Format (TF)

• Transport Format Combination (TFC)

• Transport Block Set (TBS)

• Transmission Time Interval (TTI)

• Radio Resource Control (RRC)

• Radio Link Control (RLC)

• Frame Protocol (FP)


Introduction

• Medium Access Control (MAC) is a communication protocol used in the data-link layer of the UMTS Terrestrial Radio Access Network (UTRAN).

• MAC-c is one of the “sub-protocols” of MAC.

• The objective of the thesis was to produce a prototype implementation of MAC-c. This particular implementation has two properties that make it special:

• It is tailored to be used primarily in the Nokia I-HSPA system, and

• the software is developed to be run on Digital Signal Processor (DSP).

• Internet High Speed Packet Access (I-HSPA) is a concept that features a simplified network architecture for the UMTS Internet Access service. It can be thought as a direct connection from a base station to the Internet.

• The planning of I-HSPA gave rise to this undertaking of producing a new implementation of MAC-c on DSP.


The MAC-c protocol

• MAC has above it a set of logical channels and below it a set of transport channels.

• It maps logical channels to transport channels and controls the utilization of the latter.

• MAC in its entirety consists of several components, MAC-c being one of those.

• MAC-c controls transport channels of three types: Paging Channel (PCH), Forward Access Channel (FACH) and Random Access Channel (RACH).

• PCH, FACH and RACH are cell specific and shared between all UEs in the cell.

• An UTRAN MAC-c entity has its peer entities in UEs.


The MAC-c protocol (cont.)

• The functions required from MAC-c include• Flow control towards MAC-d,

• Multiplexing and demultiplexing of logical channels on transport channels,

• Scheduling of downlink data, and

• Transport format combination (TFC) selection for downlink data.

• Multiplexing is basically the insertion (in DL) or interpretation (in UL) of the MAC header.

• Scheduling and TFC selection are tightly coupled to each other and together form the most interesting functionality of MAC-c.



• The MAC header contains the following fields:

• TCTF – specifies the target or source logical channel type

• UE-Id and UE-Id type – for a dedicated logical channel, specifies the target or source UE

• C/T - for a dedicated logical channel, specifies the target or source logical channel instance



• Scheduling of a DL data frame means that a suitable transmission time on a transport channel is selected for it.

• At the same time, a transport format (TF) is selected for the transmission.

• Transport channels are often co-dependent so that their TFs cannot be freely selected, but they must form a legal TF combination (TFC).


Software design

• The implementation was done in software that is designed to run on DSP. It was programmed in C language.

• The OSEck real-time operating system is used to host the software; there is one process (i.e. thread) for each cell.

• Inter-process communication is based on OSE signal delivery. The root of a MAC-c process contains an infinite loop; on each iteration of the loop, a signal is received. The received signal can be e.g. DL data from a logical channel or UL data from a transport channel.

• UL data is delivered to the upper layer (RRC/RLC/MAC-d) and DL data to the lower layer (FP) by sending OSE signals to corresponding processes.


Software design (cont.)

• The module structure of the software is based on a object-oriented decomposition of the functional requirements.

• A single Cell object contains all the other objects.

• Alongside the Cell class, other classes represent different types of channels, UEs located in the cell, and transmission events on DL transport channels.


Algorithms

• Scheduling and TFC selection is done in principle as follows:

1. For each data frame, first select a suitable TF (usually smallest possible).

2. Search the transmission buffer of the transport channel to find the first “slot” where this TF is available. Reserve the TF (which may restrict TFs on other channels at the same transmission time) and put the data in the buffer to wait for DL delivery.

• DL frames from logical channels are at first buffered, and the scheduling procedure is executed often enough to ensure that the buffering does not introduce latency.

• UEs (or their dedicated logical channels) are served in a round robin by the scheduler.


Evaluation background

• The MAC-c software is part of a real-time system that puts a strong demand on performance.

• Because of this, the main emphasis in evaluation was on performance measurements, especially on measuring processor utilization.

• Measurements were done with a test bench where the program is executed on a Texas Instruments TMS320VC5510 DSP.

• “Worst case” test cases were designed to generate the largest bitrate supported by each combination of logical channel and transport channel.

• Idle state (no traffic at all) was also simulated by a test case.

• The average load is somewhere between these extremes.

• Code complexity is also used as an evaluation criterion.

• Results were compared to the current Nokia MAC-c implementation, though it is based on a different hardware and operating system.


Evaluation results

• Utilization of TI C5510 by a single cell:

• Idle state: 0.4 %

• Maximum traffic load: 6.2 %

• Reference implementation normalized for comparison: ~7.5 %

• Complexity (code line count):• Our implementation: 3152

• Reference implementation: 9350

• Response time to any single input signal < 1 ms (requirement ~10 ms)

Code complexity

0 2000 4000 6000 8000 10000

C line count

McCabe

met

ric

value

MAC-c on DSP

reference

Processor utilization

0 1 2 3 4 5 6 7 8

max load

idle

scen

ario

% on C5510 DSP

MAC-c on DSP

reference


Conclusions

• Evaluation indicates that the performance is at least as good as in the older implementation. In addition, there is a big difference in code complexity in the favour of our implementation.

• Based on the evaluation, the DSP platform with the OSEck operating system seems to be a good “home” for MAC-c.

• The object-oriented architecture was a good idea although C is not inherently an o-o language. It helped in keeping the code clear and simple.

• Our algorithm for scheduling and TFC selection is characterized by simplicity. A more sophisticated algorithm could achieve a more optimal use of available transport formats. This would be an interesting topic for further study.

• Also the timing of the scheduling procedure could be studied further. Scheduling can make the best decisions when it has lots of data to schedule at the same time. On the other hand, if data is buffered for too long before scheduling, it will suffer latency. Our solution is to always avoid latency, but this might not be the optimal approach in every situation.

1 © 2006 nokia esitelma.ppt / 2006-05-09 / jh seminar presentation implementation of mac-c protocol...

Documents

macc protocol mac

mac header

utran macc entity

new implementation of

subprotocols of mac

set of transport channels

umts internet access

dedicated logical channel