ARROWS

1
ARROWS

• Advanced Radio Resource Management fOr Wireless
  Services

Ian Rice Wireless Access Research
Group University of Limerick 15/05/02
2
Content

• Project Description
• Testbed and Multimedia Application Implementation
• Radio Resource and QoS Management

3
ARROWS Consortium

• Universitat Politécnica de Catalunya (Spain)
• University of Limerick (Ireland)
• INESC Porto (Portugal)
• Telefónica ID (Spain)
• Telecom Italia Lab (Italy)

4
Objectives

• To develop, simulate, evaluate and validate
  advanced RRM algorithms and procedures for the
  optimal and efficient use of the radio resources
  provided by UTRA.
• To achieve a specific QoS for packet switched
  services.
• To demonstrate the benefits of the developed RRM
  algorithms by means of multimedia IP based
  applications over a testbed.

5
Project Organisation
6
System Service Requirements

• Identification of the services that will be
  demanded by mobile users in the next years,
  establishing a set of QoS requirements for each
  service both from the point of view of users and
  operators
• Determination of the features of the relevant
  standards (from 3GPP and IETF) that must be taken
  into account in the development of simulators,
  algorithms and testbed.
• To carry out a first classification of RRM and
  QoS Management strategies from previous European
  projects, standards bodies and literature

7
Service Mappings onto radio bearers
8
Real Time Testbed
Objectives

• To build a UTRA testbed operating in real time
• To study the impact of advanced RRM algorithms on
  the system performance for different scenarios
• Traffic loads
• Mobility and propagation characteristics
• Service configurations

• To demonstrate the benefits of the developed RRM
  algorithms by means of multimedia IP based
  applications.

9
Why a Real Time Testbed ?
The ARROWS testbed aims to provide a number of
functions not available when considering
conceptual studies or simulations
1.- In addition to the Access Stratum
functionalities, a testbed allows the assessment
of other Non Access Stratum functions related to
RRM and QoS, like impact of IP Core Network, QoS
sharing between different segments, etc. 2.- To
assess in real time the effects of the RRM
algorithms on the quality of service perceived by
the user or measured on a running
application. 3.- To compare RRM algorithms in a
fast and realistic way as much as the
implementations details like Buffers size,
Delays, HW limits, etc. are included someway.
4.- Specify the design parameters , i.e. BLER,
for different applications, i.e. streaming video,
just by moving in a fast and easy way the
different parameter settings like Eb/No, delays
in the Access Network, etc. 5.- To use real
traffic coming from a current application for the
emulated UE.
10
ARROWS Testbed Architecture
IP Network
UMTS
Core Network
UMTS
Core Network
Server Terminal
Server Terminal
UTRAN
UTRAN
PC3
PC3
PC2
PC2
PC1
PC1
Multimedia Test Terminal (reference user)
PC4
PC4

• Flexible SW/HW platform, which allows the
  experimental evaluation of different RRM
  algorithms under realistic conditions
• Multi-user, multi-service and multi-cellular
  testbed
• All the users within a reference cell are
  emulated in detail.
• Real Time Emulation Very severe time
  constraints are guaranteed

11
ARROWS Testbed Architecture

• UMTS functionalities included in the ARROWS
  testbed

12
ARROWS Testbed Architecture

• PCs as HW platform
• real time objectives may not be easy to achieve
• hardware can be adjusted to cope with processing
  demand ? platform modified
• a flexible solution to absorb any specific
  requirement must be adopted, then

• LINUX as O.S.
• Some extensions allow to work in Real time
  RTLinux, Red Linux, RTAI etc. Adjustments to O.S.
  kernel are possible.
• Communications Manager
• Modules must only use specific functions supplied
  by the communication module to perform any kind
  of data movement. This hides the underlying
  hardware platform.

13
ARROWS Testbed Architecture

• Functions of Communications Manager include
• Inter process communication
• Provide an uniform method for all partners to
  exchange data
• Generate session logs and provide session
  configuration parameters
• Keep modules apart from input/output operations
  to disk
• Control system resource utilisation
• Keep system stable even though module errors
• Track module message exchange for easy debugging
• Clean session start and stop
• Keep software controlled from a centralised
  control console
• Report of modules not properly initialising or
  closing
• All the functions are oriented to separate the
  processing modules from specific hardware and
  O.S. and to keep the testbed under control in any
  case.

14
ARROWS Testbed Architecture

• General structure using Communications Manager

15
Lower Layers Emulation

• Emulation of the Physical layer by means of
  histograms of the Bit Error Rate per packet
  obtained from the Link Layer Simulators
• Radio Channel characterized by means of PDP and
  Doppler Spectrum
• RAKE receiver and diversity schemes

16
Lower Layers Emulation
Physical layer Channel Coding Power
Control

• Turbo Code with rate 1/3
• Uplink
• Conversational UL64 kbps / CS RAB
• Interactive UL64 kbps / PS RAB
• Downlink
• Conversational DL 64 kbps / CS RAB
• Streaming DL128 kbps / CS or PS RAB
• Interactive DL256 kbps / PS RAB
• Background 32 kbps PS RAB
• Convolutional Code with rate ½
• Uplink Background 32 kbps / PS RAB

Open Loop (RACH, FACH) Closed Loop (DCH, DSCH)
17
Lower Layers Emulation

• RLC (Radio Link Control )
• 3 different operation modes
•   Transparent Mode (TM)
• transmits higher layer Packet Data Units (PDU)
  without adding any protocol information. Used in
  Conversational RABs.
•  
•  Unacknowledged Mode (UM)
• transmits higher layer PDUs without guaranteeing
  delivery to the peer entity. No retransmissions
  only sequence numbers. Not implemented only
  signalling RB use it
•  
•  Acknowledged Mode (AM)
• transmits higher layer PDUs and guarantees
  delivery to the peer entity. Retransmissions are
  applied. Used in Streaming, Background and
  Interactive RABs.
• There is no difference between TDD and FDD.

18
Lower Layers Emulation

• RLC (Radio Link Control )
• Emulation of the
• Acknowledge and Transparent RLC operation modes
• Segmentation and reassembly procedures
• Parameters to be defined by RRM when the RLC
  entity is created
• Operation mode (TM or AM)
• PU size for segmentation procedure.
• For AM
• max_num_retransmissions
• SDU timeout

19
Lower Layers Emulation

• MAC (Medium Access Control)
• MAC must talk with RRM to obtain the allowed
  Transport Format.
• Parameters to be exchanged
• Eb/No measured
• Selected TFC per TTI
• Instant of a new SDU-RLC arrival
• SDU-RLC size
• ACK/NACK for the different transmitted PDU-RLC

20
Lower Layers Emulation
PDCP (Packet Data Convergence Protocol)

• Robust Header Compression (ROHC) (RFC 3095) ?
  To compress IP/UDP/RTP headers (streaming and
  video-telephony)

• Compressed TCP (CTCP) (RFC 2507) ? To compress
  IP/TCP headers (web-browsing and e-mail)

21
RRM Controller

• RRM Control architecture developed according to
  the algorithms proposed in WP2
• Detailed emulation of all the users in the RRM
  module

22
Upper Layers Emulation

• User Plane
• Emulation of the Iu UP protocol
• Transparent and Support for predefined SDU size
  modes
• Influence of the number of active connections on
  the Iu performances
• Control Plane
• Emulation of the basic functionalities of the
  RANAP protocol
• Radio Resource Control Emulator
• Establishment, maintenance and release of
  connections
• Establishment, reconfiguration and release of
  Radio Bearers
• Control of the requested QoS
• NAS
• Offers Access stratum services to higher layers

23
Signalling

• Objective To demonstrate the proposed RRM
  algorithms.
• Methodology
• Specification of the functionality and
  performance requirements of the testbed.
• Identification of the relevant sub-set of
  functionality from 3GPP specifications.
• Generation of message sequence charts.
• Implementation using SDL.
• Inter-module communication using CommManager

24
Implementation

• Specification and Description Language (SDL).
• C code generation using targeting expert.
• Environmental functions added to generated code.
• Linux make.
• CommManager integration.

25
Applications Development

• End-to-end QoS implementation
• Mapping of IETF Guaranteed Service QoS parameters
  to UMTS QoS parameters
• Use of RSVP (3GPP aligned)

• IP oriented applications
• Videoconference vic, rat (vat)
• Video Streaming Mpeg4IP Project
• Web browsing Mozilla, Apache
• E-mail Mozilla, Qmail, UW IMAP

26
RRM Framework
27
Radio Resource Management Framework
28
STRATEGIES FOR RADIO RESOURCE MANAGEMENT IN UTRA
FDD/TDD
To provide a final optimisation of the Radio
Resources available while guaranteeing the
established Quality of Service (QoS) for the
services involved ARROWS developes strategies
for the following RRM functions

• SOFT-HANDOVER MANAGEMENT
• ADMISSION CONTROL FOR UPLINK AND DOWNLINK
• CONGESTION CONTROL
• MANAGEMENT OF TRANSMISSION PARAMETERS
• CODE ALLOCATION STRATEGIES
• DYNAMIC CHANNEL ALLOCATION FOR TDD

29
HANDOVER MANAGEMENT
30
HANDOVER MANAGEMENT

• THE RESERVED SET REGION

When a mobile moves from the Active Set Region
1to the Reserved Set Region 2, only the resources
of BTS3 should be reserved. Hence, the
reservation is always carried out on a single
cell basis.
31
ADMISSION CONTROL
The ADMISSION CONTROL is employed to decide
whether to accept or reject a new connection
depending on the QoS?? requested and the
interference it adds to the existing connections.

• ARROWS proposes admission control algorithms
  according to the following steps
• Capacity check
• Power availability
• OVSF code availability (Only Downlink)

• Once a new RAB is to be set-up, the following
  parameters are assumed to be known
• - (Eb/No) min o (SIRtarget) associated to the
  specific service
• Highest bit rate in the TFCS defined for the RAB
• Path loss for the new user
• UE capabilities (maximum transmitted power)

32
ADMISSION CONTROL
33
CONGESTION CONTROL
34
CONGESTION CONTROL
 
35
MANAGEMENT OF TRANSMISSION PARAMETERS

• UPLINK TFC SELECTION and DECENTRALIZED APPROACH

The algorithms for the management of uplink
parameters relies on the selection of the most
appropriate TFC among the TFCS for each TTI
considering a decentralized aproach at UE level
 a) Interactive services Delay-oriented
strategy To select the TFC that allows the
transmission of the information within the
specified delay bound. Rate-oriented strategy
To select the TFC that allows the transmission of
the information within the specified bit rate The
SCr of a connection accounts for the difference
between the obtained bit rate and the expected
bit rate for this connection.
b) Best effort services Individual-oriented
policies Selecting the TFC that allows the
highest transmission bit rate according to the
amount of bits Li to be transmitted.
Collective-oriented policies Selecting the TFC
according to a. A set of thresholds depending on
the measured interference level Io that is
broadcast in the BCH. b. The own experience of
each terminal   Energy conserving policies The
UE transmits information only under favorable
propagation conditions
36
MANAGEMENT OF TRANSMISSION PARAMETERS

• DOWNLINK TFC AND OVSF CODES SELECTION
  CENTRALIZED APPROACH

37
OVSF codes
In UTRA-FDD, each user in downlink is assigned
one or more Orthogonal Variable Spreading Factor
(OVSF) codes for channelisation purposes.

• R bit rate supported by a layer 1 code
• Nmax total number of codes in layer 1 (i.e. the
  maximum spreading factor)

Assumption If a service requiring R bps can be
mapped into a code belonging to layer 1, a code
belonging to layer M can be used to map a service
requiring 2M-1R bps.
38
OVSF codes

• All codes belonging to the same layer (having the
  same length and SF) are orthogonal with each
  other
• When a code is assigned, it is not possible to
  assign either any descendant code, or any mother
  code. In fact these codes are not orthogonal to
  each other

?

• Limited number of available codes in downlink
• It is extremely important to be able to
  allocate/reallocate the channelisation codes in
  downlink with an efficient method, in order to
  prevent code blocking

39
OVSF codes

• Code blocking the situation where a new call
  could be accepted in a cell on the basis of
  interference analysis and also on the basis of
  the spare capacity of the code tree. However,
  due to an inefficient code assignment, this spare
  capacity is not available for the new call that
  therefore must be blocked.

40
Dynamic Assignment Scheme

• A code allocation/reallocation strategy aims
• To minimize code tree fragmentation
• To preserve the maximum number of high rate codes
• To eliminate code blocking
• The strategy introduced is a DCA scheme that
  reassigns OVSF codes such that code blocking is
  eliminated
• This strategy is optimal in the sense that it
  minimizes the number of OVSF codes that must be
  reassigned to support a new call

41
Dynamic Assignment Scheme
L active users in the system KiR bit rate of i
user NmaxR total tree capacity
(Krafts inequality)
42
UTRA-FDD LINK LEVEL SIMULATOR
Total 3480 different Off-Line simulations
43
BLOCK DIAGRAM OF THE SIMULATED UTRA-FDD LINK LAYER
Space diversity with 2 antennas in UL
44
System Level Simulator
45
System Level Simulator
46
Dissemination

• 3 papers for the IST Mobile summit 01.
• 1 paper at PIMRC01.
• 2 papers submitted to IEEE Electronic letters.
• 1 paper at the European Wireless conference 02.
• 4 papers accepted for the IST Mobile summit 02.

47
Thank You