Seminar Presentation
Implementation of MAC-c Protocol for an
Improved UMTS Internet Access
Juhani Hietikko
9.5.2006
Thesis done at the Signal Processing Systems unit of Nokia Networks
1
Supervisor
Professor Jörg Ott
Instructor
M.Sc. Antti Lehtonen
© 2006 Nokia
esitelma.ppt / 2006-05-09 / JH
Contents
• Abbreviations
• Introduction
• The MAC-c protocol
• Software design
• Algorithms
• Evaluation results
• Conclusions
2
© 2006 Nokia
esitelma.ppt / 2006-05-09 / JH
Abbreviations
• Medium Access Control (MAC)
• User Equipment (UE)
• UMTS Terrestrial Radio Access Network
(UTRAN)
• Transport Format (TF)
• Internet High Speed Packet Access (IHSPA)
• Transport Block Set (TBS)
• Digital Signal Processor (DSP)
• Paging Channel (PCH)
• Forward Access Channel (FACH)
• Random Access Channel (RACH)
• Uplink (UL)
• Downlink (DL)
3
© 2006 Nokia
esitelma.ppt / 2006-05-09 / JH
• Transport Format Combination (TFC)
• 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.
4
© 2006 Nokia
esitelma.ppt / 2006-05-09 / JH
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.
5
© 2006 Nokia
esitelma.ppt / 2006-05-09 / JH
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.
6
© 2006 Nokia
esitelma.ppt / 2006-05-09 / JH
The MAC-c protocol (cont.)
• 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
7
© 2006 Nokia
esitelma.ppt / 2006-05-09 / JH
The MAC-c protocol (cont.)
• 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).
8
© 2006 Nokia
esitelma.ppt / 2006-05-09 / JH
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.
9
© 2006 Nokia
esitelma.ppt / 2006-05-09 / JH
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.
10
© 2006 Nokia
esitelma.ppt / 2006-05-09 / JH
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.
11
© 2006 Nokia
esitelma.ppt / 2006-05-09 / JH
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.
12
© 2006 Nokia
esitelma.ppt / 2006-05-09 / JH
Evaluation results
• Utilization of TI C5510 by a single cell:
Processor utilization
• Idle state: 0.4 %
• Maximum traffic load: 6.2 %
scenario
• Reference implementation normalized for
comparison: ~7.5 %
idle
MAC-c on DSP
reference
max load
• Complexity (code line count):
• Our implementation: 3152
0
1
2
3
4
5
6
7
8
% on C5510 DSP
• Reference implementation: 9350
• Response time to any single input signal <
1 ms (requirement ~10 ms)
Code complexity
metric
McCabe
MAC-c on DSP
reference
C line count
0
2000
4000
6000
value
13
© 2006 Nokia
esitelma.ppt / 2006-05-09 / JH
8000
10000
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.
14
© 2006 Nokia
esitelma.ppt / 2006-05-09 / JH