User Guide (Release 1.

5)

INTRODUCTION............................................................................................................................. 5
2. INSTALLATION PROCEDURE ....................................................................................................... 5
2.1 MODFED FLES .......................................................................................................................... 5
2.2 PATCHNG AN EXSTNG NS-2 NSTALLATON.................................................................................... 6
2.3 MERGNG WTH ANOTHER SET OF MODFCATONS TO NS-2.26. ......................................................... 6
2.4 SYSTEM CONFGURATONS ........................................................................................................... 7
3. NODE CONFIGURATION................................................................................................................ 7
3.1 RADO NETWORK CONTROLLER (RNC).......................................................................................... 7
3.2 BASE STATON (BS) .................................................................................................................... 7
3.3 UB CONFGURATON.................................................................................................................... 7
3.4 USER EQUPMENT (UE)................................................................................................................ 8
3.5 MSCELLANEOUS CONFGURATON................................................................................................. 8
3.5.1 Routing Gateway................................................................................................................ 8
4. SIMULATION SET-UP..................................................................................................................... 8
4.1 AGENT CONFGURATON............................................................................................................... 8
4.2 CREATNG/ATTACHNG A TRANSPORT CHANNEL .............................................................................. 9
4.2.1 FACH/RACH...................................................................................................................... 9
4.2.2 DCH................................................................................................................................... 9
4.2.3 HS-DSCH......................................................................................................................... 10
4.3 RLC CONFGURATON................................................................................................................ 11
4.3.1 AM................................................................................................................................... 11
4.3.2 AM-HS............................................................................................................................. 13
4.3.3 UM................................................................................................................................... 14
4.3.4 UM-HS............................................................................................................................. 15
4.4 MAC/MAC-HS CONFGURATON ................................................................................................. 15
4.4.1 MAC-hs PDU Reordering ................................................................................................. 16
4.4.2 Credit Allocation............................................................................................................... 16
4.4.3 Scheduling ....................................................................................................................... 17
4.4.4 MAC-hs PDU Generation ................................................................................................. 17
4.4.5 HARQ.............................................................................................................................. 17
4.5 PHYSCAL LAYER CONFGURATON............................................................................................... 18
4.6 TRACE SUPPORT....................................................................................................................... 18
5. KNOWN ISSUES........................................................................................................................... 19
5.1 HS-DSCH: EVEN NUMBER OF UE NODES MUST BE CONFGURED ................................................... 19
REFERENCES ..................................................................................................................................... 19
APPENDIX A: PRE-PROCESSING...................................................................................................... 21
APPENDIX B: INPUT TRACE FILES................................................................................................... 24
APPENDIX C: EXAMPLE TCL SIMULATION SCRIPT ........................................................................ 26
APPENDIX D: TRANSPORT CHANNELS - A SCHEMATIC VIEW...................................................... 29

Document History

ReIease Version Date Comments
1.0 02/02/2004 nitial version
1.1 06/02/2004 Editorial changes
1.2 24/02/2004 Fixed TCL example script
1.3 18/03/2004 Updated to incorporate FCDS parameters, and up-
dated example parameter values
1.4 27/01/2005 Editorial changes, more information on the pre-
processing procedure, also available in the D3.2v2
document downloadable from the Eurane website
1.5 15/02/2005 Editorial changes formulas appendix B
EURANE User Guide (ReIease 1.5) 15/02/2005


Page 5/31
1. Introduction
t is the intention of this document to provide a description of the installation and configura-
tion requirements for the Enhanced UMTS Radio Access Network extensions to 38 (ver-
sion 2.26), developed within the SEACORN project [1] for Ericsson Telecommunicatie B.V..
An assumption is made that the reader has both a working knowledge of 38 and UMTS
architecture/algorithm concepts. Further information, and updates to code and documenta-
tion can be found at the following website:

http://www.ti-wmc.nl/eurane

The Enhanced UMTS extensions for ns-2 comprise of an additional three nodes, namely
the Radio Network Controller (RNC), Basestation (BS) and the User Equipment (UE),
whose functionality allow for the support of the following transport channels:
N FACH
N RACH
N DCH
N HS-DSCH
The main functionality additions to 38 come in the form of the RLC Acknowledged Mode
(AM), Unacknowledged Mode (UM) MAC-d/-c/sh support for RACH/FACH and DCH, and
MAC-hs support for HS-DSCH, i.e. HSDPA. The following are the associated TCL objects
for this functionality:
N Mac/Umts - MAC-d and MAC-c/sh
N Mac/Hsdpa 8
N UMTS/RLC/AM - Normal AM
N UMTS/RLC/AMHS - Enhanced AM with flow/priority packet status information
2. InstaIIation Procedure
The extensions to 38 come in the form of an additional UMTS C++ library, a UMTS TCL
library (ns-umts.tcl), and additions to ns-default.tcl, ns-packet.tcl and
packet.h.
2.1 Modified FiIes
For readability the header files that have the same name as its companion .cc file are only
indicated by a (h) after the .cc file. Testing scripts and input files are also not listed in the
table.
FiIe Description
Makefile.in nput for configure, updated to include the UMTS code
common/packet.h Added header fields for UMTS
tcl/lib/ns-default.tcl Added default values for UMTS objects
tcl/lib/ns-lib.tcl Changed to include ns-umts.tcl
tcl/lib/ns-packet.tcl Added header definitions for UMTS MAC header extensions
tcl/lib/ns-umts.tcl Code for UMTS nodes in ns
EURANE User Guide (ReIease 1.5) 15/02/2005


Page 6/31
umts/am-hs.cc (h) RLC AM implementation for enhanced UMTS
umts/am.cc (h) RLC AM implementation for UMTS
umts/classifier-sport.cc (h) UMTS Port Classifier
umts/demuxer.cc (h) UMTS Node Demuxer
umts/demuxerRtModule.cc (h) UMTS Routing Module
umts/dummy_drop_tail (h) ub queue implementation with no dropping
umts/hsdpalink.cc (h) MAC-hs implementation (also includes physical layer)
umts/networknterface.cc (h) UMTS Network nterface (NF)
umts/nif-classifier.cc (h) UMTS NF Classifier
umts/rlc.h Generic RLC superclass
umts/tcs.cc (h) UMTS channel switching implementation
umts/um.cc (h) RLC UM implementation for UMTS
umts/um-hs.cc (h) RLC UM implementation for enhanced UMTS
umts/umts-queue.cc (h) Generic Queue class for UMTS implementation
umts/umts-timers.cc (h) Generic Timer Classes for UMTS implementation
umts/umtslink.cc (h) UMTS MAC and physical layer implementation
umts/umtstrace.cc (h) Tracefile generation implementation
umts/virtual_umtsmac.cc (h) Generic MAC class
umts/cqi.h Lookup table for CQ to MAC-hs PDU size
umts/error_model.cc (h) Reads tracefiles for CQ and transmission power

2.2 Patching an existing ns-2 instaIIation

The assumption is that a reasonably standard Linux distribution is used. Other Unix ver-
sions should also work, but might not have certain tools used in this procedure. No attempts
have been made to install the simulator using cygwin. Other requirements are a recent ..
installation with the STL library included.
NB: Before installing this patch, make sure you have a backup.
You can install the enhanced UMTS simulator either by patching the clean ns-2.26 source
tree or by untarring the tarball with complete files over the existing files. The patch method
merges changes relative to the clean ns-2.26 distribution.
Using the patch file:
go into the ns-2.26 directory and run the command:
patch -p1 < <patch_file>
where <patch_file> is the filename of the patch file.

Using the tarball with modified files:
Untar the tarball (e.g. tar zxvf "umts-files.tar.gz") in a clean directory or if you're
daring, untar in the clean ns-2.26 directory. Changed files will then be overwritten.

2.3 Merging with another set of modifications to ns-2.26.
f you have made your own modifications to the standard ns-2.26 distribution, you will need
to copy the new files from our version to your own modified ns-2.26 tree and then look at all
the files that exist in both trees. See what differences there are and merge them individu-
ally.

EURANE User Guide (ReIease 1.5) 15/02/2005


Page 7/31
2.4 System Configurations
Configurations on which the installation were tested:
Linux:
Distribution: Mandrake 9.1
Compiler version(s): gcc-3.2.2

Distribution: Mandrake 9.2
Compiler version(s): gcc-3.3.1
SoIaris:
t should not be a problem to use this software under Solaris, provided a way is found to
configure the use of the STL library. t is included in the package of gcc available on sun-
freeware.com, but the files end up in a non-standard location. A modification to the make-
file.in and/or the configure.in script is required to fix this. Solaris has not been
tested, since no effort has been made to make the code compile on Solaris.

3. Node Configuration
For a successful simulation the new UMTS nodes must be configured correctly. This in-
cludes the order of configuration and parameter settings. An example TCL simulation script
is given in Appendix C. The following sub-sections describe the parameters required for
each node, and are listed in the order in which they must be configured, i.e. RNC first, etc.

3.1 Radio Network ControIIer (RNC)
The RNC is the first node to be configured, but is the simplest, only requiring the following
configuration:
$ns node-config -UmtsNodeType rnc
809 rnc [$ns create-Umtsnode]

3.2 Base Station (BS)

The BS is next to be configured, where the additional parameters relate to the bandwidth
and TT of the FACH (downlink) and RACH (uplink), which are partially set-up during BS
configuration.
$ns node-config -UmtsNodeType bs \
-downlinkBW 32kbs \
-downlinkTTI 10ms \
-uplinkBW 32kbs \
-uplinkTTI 10ms

809 bs [$ns create-Umtsnode]

3.3 Iub Configuration
Once the RNC and BS have been created and configured, the interface (ub) between them
is then set-up using the 809:5:- command and the following parameters:
EURANE User Guide (ReIease 1.5) 15/02/2005


Page 8/31
$ns setup-Iub $bs $rnc <ubw> <dbw> <udelay> <ddelay> <qtype> <qsize>

where,
<ubw> and <dbw> define the uplink and downlink bandwidth, respectively. -9(
:/0, and //0, define the uplink and downlink delay, respectively. 28(
6950defines the Queue type of the link. [DummyDropTaiI]
,3/680 defines the maximum queue size, in bytes. (
n the case where the Queue type is DummyDropTail, the queue size is unlimited and the
last parameter is ignored. This Queue was implemented because the queue size could not
be set larger than 2000, using DropTail, which led to packet dropping in the ub at high
rates.
Note: t is assumed that the ub nterface is lossless, and typical configuration values are
given in square brackets ([ ]).

3.4 User Equipment (UE)
Finally the UE can be created and configured using the following commands:
$ns node-config -UmtsNodeType ue \
-basestation $bs \
-radioNetworkController $rnc
809 ue1 [$ns create-Umtsnode]
3.5 MisceIIaneous Configuration
3.5.1 Routing Gateway
As part of the routing between the fixed network and the UMTS nodes, a gateway is intro-
duced between the RNC and the last core network node before the UMTS nodes. From the
example TCL script in Appendix C, this last core network node would be the SGSN. The
gateway is added only after the RNC and SGSN have been created, with the following com-
mand:
$rnc add-gateway $sgsn0

4. SimuIation Set-up
Once the UMTS nodes have been created and configured then a specific simulation sce-
nario of applications and transport channel connections to the UEs can be constructed. The
algorithm specifics of the nodes, at this point, can be selected and configured. The parame-
ter settings listed, have their defaults set in the ns-default.tcl file.


4.1 Agent Configuration
The HS-DSCH implementation uses a scheduling algorithm based on priorities and flows,
so the agent should set the values for the priority and the flow. For this, the fields 1/* and
574* in the P header are used. The following commands creates a TCP agent that cre-
ates packets with flow-id 0 and priority 2:
EURANE User Guide (ReIease 1.5) 15/02/2005


Page 9/31

809 tcp0 [new Agent/TCP]
$tcp0 set fid_ 0
$tcp0 set prio_ 2

Even when the agent is not a TCP agent, these fields should be used. For example, it is
also possible to create an UDP agent that will use a flow-id of 0 and a priority of 2:

809 udp0 [new Agent/UDP]
$udp0 set fid_ 0
$udp0 set prio_ 2

Each UE should use one flow-id. UE1 should use flow-id 0, UE2 should use flow-id 1, etc.
Priorities can be set from 0 to priority_max_, which has a standard value of 5. Packets
with a lower prio_ value have a higher priority.
4.2 Creating/Attaching a Transport channeI
Once an Agent and traffic source/sink have been created they can be attached to a desired
transport channel using the following procedures. For a clearer view of these transport
channels' construction in TCL, using a schematic approach, see Appendix D.
4.2.1 FACH/RACH
The link layer components of the Forward Access Channel (FACH) and Random Access
Channel (RACH), which are both Common channels, are created at the time of the BS and
UE node configuration, and only require an 'attachment' procedure to an RLC entity. This is
achieved through the use of the attach-common command, with the following parameters
configured:

$ns node-config -llType UMTS/RLC/AM \
-downlinkBW 64kbs \
-uplinkBW 64kbs \
-downlinkTTI 20ms \
-uplinkTTI 20ms

$ns attach-common <node> <agent>


The Dedicated Channel (DCH) operates in both the uplink and downlink, and its entire link
components, from the RLC at the RNC to the RLC at the UE, need to be created. This is
achieved through the create-dch command, along with the following parameter configu-
ration:
$ns node-config -llType UMTS/RLC/AM \
-downlinkBW 64kbs \
-uplinkBW 64kbs \
-downlinkTTI 10ms \
-uplinkTTI 10ms

809 dch0 [$ns create-dch <node> <sink>]

EURANE User Guide (ReIease 1.5) 15/02/2005

Page 10/31
f more than one application is to be connected to a DCH then the attach-dch command
is used to attach another Agent and traffic source to an already existing DCH, in the follow-
ing way:
$ns attach-dch <node> <agent> <dch>

t would however not be correct to create multiple applications connected to a single UE
using multiple instances of create-dch.
4.2.2.1 Channel Switching
Only in the case of the DCH is there the possibility to channel switch to the RACH/FACH,
and this can be configured from the TCL level using the following commands (normally set
in ns-default), which set-up both the channel switcher and traffic channel measurer.
TrChMeasurer 809 THP_REPORT_INTERVAL_ 500ms
TrChMeasurer 809 DOWNSWITCH_THRESHOLD_ 8kbps
TrChMeasurer 809 DOWNSWITCH_TIMER_THRESHOLD_ 16kbps
TrChMeasurer 809 DL_RLC_BUF_UPSWITCH_THRESH_sRAB_ 500bytes
TrChMeasurer 809 UL_RLC_BUF_UPSWITCH_THRESH_sRAB_ 265bytes
TrChMeasurer 809 PENDING_TIME_AFTER_TRIGGER_ 0.5s
TrChMeasurer 809 BUFF_CHECK_INTERVAL_ 10ms

ChannelSwitcher 809 DOWNSWITCH_TIMER_sRAB_ 1s
ChannelSwitcher 809 noSwitching_ false


THP_REPORT_INTERVAL_ : This parameter defines the time interval between throughput
reporting.
DOWNSWITCH_THRESHOLD_ : This is the throughput, in bits per second, below which
one would trigger a down-switch from a DCH to a Common channel.
DOWNSWITCH_TIMER_THRESHOLD_ : This is the throughput, in bits per second, which
one would trigger an up-switch from a Common channel to a DCH.
DL_RLC_BUF_UPSWITCH_THRESH_sRAB_ : This is the transmission buffer level, in
bytes, at the BS RLC, above which one would trigger an up-switch to a DCH.
UL_RLC_BUF_UPSWITCH_THRESH_sRAB_ This is the corresponding RLC buffer level
at the UE, in bytes, above which one would trigger an up-switch to a DCH.
PENDING_TIME_AFTER_TRIGGER_ This parameter defines the time delay between the
decision to switch channels and the actual switching.
BUFF_CHECK_INTERVAL_ This is the time interval between checking of the transmis-
sion buffer at the RLC.
DOWNSWITCH_TIMER_sRAB_ This defines the time interval between checks of the
channel switching status.
noSwitching_ This allows the channel switching functionality to be switched on or off. A
value of 'false' indicates that channel switching is on, while a value of 'true' indicates that it
is off.

4.2.3 HS-DSCH
The HS-DSCH also has to be fully constructed, as in the case of the DCH, and although it is
a downlink transport channel, an uplink return path, for RLC retransmissions and TCP ac-
EURANE User Guide (ReIease 1.5) 15/02/2005


Page 11/31
knowledgments, is also required. As the HS-DSCH always requires an associated DCH, an
uplink DCH is always created alongside the HS-DSCH. These are created using the cre-
ate-hsdsch command and configured using the following TCL commands:
$ns node-config -llType UMTS/RLC/AM \
-uplinkTTI 10ms \
-uplinkBW 64kbs \
-hs_downlinkTTI 2ms \
-hs_downlinkBW 64kbs

$ns create-hsdsch <node> <agent>

Once an HSDSCH has been created, other UEs can be connected to it using the attach-
hsdsch command, in the following way:
$ns attach-hsdsch <node> <agent>

490 The parameter <agent> defines what is being connected directly to the <node>, i.e.
UE, and this parameter could possibly even be a sink or TCP/UDP Agent, etc.
An attach-hsdsch command is used because the AM-HS at the RNC, and the MAC-hs at
the BS, only have to be created once, as it is a shared channel.

4.3 RLC Configuration
At the RNC, two implementations of Acknowledged Mode (AM) are available for RLC. The
type of RLC (AM or AM-HS) to use is dependent on the transport channel. Two implementa-
tions of Unacknowledged Mode, UM and UM-HS, are also available, and are basically a
functional sub-set of the AM and AM-HS, respectively.
4.3.1 AM
This RLC entity is used for both the Dedicated Channel (DCH) and the two Common chan-
nels (RACH and FACH), at the RNC/UE, and at the UE for HS-DSCH. t has the following
configuration parameters:

UMTS/RLC/AM 809 ack_mode_ 2
UMTS/RLC/AM 809 win_ 1024
UMTS/RLC/AM 809 maxRBSize_ 100kB
UMTS/RLC/AM 809 overhead_ 20us
UMTS/RLC/AM 809 payload_ 40
UMTS/RLC/AM 809 ack_size_ 5
UMTS/RLC/AM 809 rtx_timeout_ 140ms
UMTS/RLC/AM 809 noFastRetrans_ 0
UMTS/RLC/AM 809 numdupacks_ 2
UMTS/RLC/AM 809 poll_PDU_ 256
UMTS/RLC/AM 809 poll_timeout_ 170ms
UMTS/RLC/AM 809 stprob_timeout_ 150ms
UMTS/RLC/AM 809 macDA_ -1
UMTS/RLC/AM 809 bandwidth_ 0
UMTS/RLC/AM 809 TTI_ 10ms
UMTS/RLC/AM 809 length_indicator_ 7
UMTS/RLC/AM 809 ack_pdu_header_ 1
UMTS/RLC/AM 809 status_pdu_header_ 4
EURANE User Guide (ReIease 1.5) 15/02/2005


Page 12/31
UMTS/RLC/AM 809 min_concat_data_ 3
UMTS/RLC/AM 809 max_status_delay_ 10ms
UMTS/RLC/AM 809 max_ack_delay_ 10ms


ack_mode_ : Defines the type of Acknowledgment. A value of 1 indicates a Positive Ac-
knowledgment (PA) and a value of 2 indicates a Bitmap Acknowledgment (BA).
win_ : This defines the RLC Window Size, which is the amount of packets that can be sent
after the last acknowledged packet.
maxRBSize_ : The maximum size of the receive buffer, in bytes.
overhead_ : Time that is needed to construct SDUs.
payload_ : Defines the size of the MAC-d PDUs in bytes.
ack_size_ : This defines the size, in bytes, of the status PDUs that are generated by the PA
scheme.
rtx_timeout_ : After this time, the unacknowledged packets are assumed to be lost. All the
packets after the last acknowledged packet are retransmitted. The timer is reset each time
the first unacknowledged packet is acknowledged.
noFastRetrans_ : This defines whether an RLC entity will wait for a timeout before re-
transmitting missing RLC PDUs. A value of 0 indicates that this functionality is off, while a
value of 1 indicates that it is on.
numdupacks_ : This is the number of duplicate Positive Acknowledgments, after which the
Fast Retransmit function is invoked.
poll_PDU_ : A poll for a bitmap acknowledgement is sent every poll_PDU_ MAC-d PDUs.
poll_timeout_ : A poll for a bitmap acknowledgement is sent at least every poll_timeout_
time. The poll timer will be cleared every time a poll has been sent.
stprob_timeout_ : This parameter defines the timeout value of the Status Prohibit Timer.
After a bitmap acknowledgement has been sent, for the next stprob_timeout_ time no new
bitmap acknowledgement will be sent.
macDA_ : MAC destination address (Node D)
bandwidth_ : The Transport Channel's bandwidth.
TTI_ : The duration of the Transport Channel's Transmission Time nterval (TT).
length_indicator_ : The size of a length indicator in bits, without the extension bit. When
the payload is less than 127 bytes it is defined to be 7, otherwise it is defined to be 15.
ack_pdu_header_ : The size of the header of a PA status PDU, in bytes.
status_pdu_header_ : The size of the status PDU header in bits.
min_concat_data_ : The minimum amount of bytes available to the next SDU before an
incomplete MAC-d PDU can be used for concatenation. Otherwise the MAC-d PDU will be
padded and send without concatenation.
max_status_delay_ : The maximum time that a status PDU can be postponed. During this
period piggybacking of the status PDU is attempted.
max_ack_delay_ : The maximum time that an acknowledgement PDU can be postponed.
During this period piggybacking of the acknowledgement PDU is attempted. The difference
between a status PDU and an acknowledgement PDU is that a status PDU is a request for
EURANE User Guide (ReIease 1.5) 15/02/2005


Page 13/31
an acknowledgement PDU (so it is sent by the transmitter of user data), and an acknowl-
edgement PDU is the answer to a status PDU (so it is send by the receiver of user data).

4.3.2 AM-HS
This RLC entity is solely for use with the HS-DSCH, and has the following configuration pa-
rameters:

UMTS/RLC/AMHS 809 temp_pdu_timeout_time_ 2ms
UMTS/RLC/AMHS 809 credit_allocation_interval_ 15
UMTS/RLC/AMHS 809 flow_max_ 20
UMTS/RLC/AMHS 809 priority_max_ 5
UMTS/RLC/AMHS 809 win_ 4095
UMTS/RLC/AMHS 809 buffer_level_max_ 500
UMTS/RLC/AMHS 809 TTI_ 2ms
UMTS/RLC/AMHS 809 macDA_ -1
UMTS/RLC/AMHS 809 payload_ 40
UMTS/RLC/AMHS 809 poll_PDU_ 256
UMTS/RLC/AMHS 809 poll_timeout_ 170ms
UMTS/RLC/AMHS 809 stprob_timeout_ 150ms
UMTS/RLC/AMHS 809 length_indicator_ 7
UMTS/RLC/AMHS 809 status_pdu_header_ 4
UMTS/RLC/AMHS 809 min_concat_data_ 3
UMTS/RLC/AMHS 809 status_timeout_ 1ms


temp_pdu_timeout_time_ : This parameter defines the time in which status information,
that needs to be sent, is attempted to be piggybacked. When the status information is not
sent during this time a separate status PDU is created with the status information.
credit_allocation_interval_ : This parameter sets the number of timeslots between credit
requests to the MAC-hs. Credit allocation forms the basis of the flow control between the
RNC and MAC-hs in HSDPA.
14*2,* : Defines the maximum number of flows (or users).
priority_max_ : Defines the maximum number of priorities.
3* : This defines the RLC Window Size, which is the amount of packets that can be sent
after the last acknowledged packet.
buffer_level_max_ : Defines the maximum number of MAC-d PDUs to be stored in the
transmission buffer.
TTI_ : The duration of an HS-DSCH Transmission Time nterval (TT).
macDA_ : MAC destination address (Node D)
payload_ : Defines the size of the MAC-d PDUs in bytes.
poll_PDU_ : A poll for a bitmap acknowledgement is sent every poll_PDU_ MAC-d PDUs.
poll_timeout_ : A poll for a bitmap acknowledgement is sent at least every poll_timeout_
time. The poll timer will be cleared every time a poll has been sent.
EURANE User Guide (ReIease 1.5) 15/02/2005


Page 14/31
stprob_timeout_ : This parameter defines the timeout value of the Status Prohibit Timer.
After a bitmap acknowledgement has been sent, for the next stprob_timeout_ time no new
bitmap acknowledgement will be sent.
length_indicator_ : The size of a length indicator in bits, without the extension bit. When
the payload is less than 127 byte it is defined to be 7, otherwise it is defined to be 15.
status_pdu_header_ : The size of the status PDU header in bits.
min_concat_data_ : The minimum amount of bytes available to the next SDU before an
incomplete MAC-d PDU can be used for concatenation. Otherwise the MAC-d PDU will be
padded and sent without concatenation.
status_timeout_ : This parameter defines the time in which a packet is held for concatena-
tion.

&
This RLC entity is used for both the Dedicated Channel (DCH) and the two Common chan-
nels (RACH and FACH), at the RNC/UE, and at the UE for HS-DSCH. t has the following
configuration parameters:

UMTS/RLC/UM set payload_ 40
UMTS/RLC/UM set bandwidth_ 0
UMTS/RLC/UM set macDA_ -1
UMTS/RLC/UM set win_ 1024
UMTS/RLC/UM set temp_pdu_timeout_time_ 10ms
UMTS/RLC/UM set buffer_level_max_ 500
UMTS/RLC/UM set TTI_ 10ms
UMTS/RLC/UM set length_indicator_ 7
UMTS/RLC/UM set min_concat_data_ 3

5,4,/* : Defines the size of the MAC-d PDUs in bytes.

bandwidth_ : The Transport Channel's bandwidth. Overwritten at node-config.
macDA_ : MAC destination address (Node D).
win_ : This defines the RLC Window Size, which is the amount of packets that can be sent
after the last acknowledged packet.
temp_pdu_timeout_time_ : This parameter defines the time in which status information,
that needs to be sent, is attempted to be piggybacked. When the status information is not
sent during this time a separate status PDU is created with the status information.
buffer_level_max_ : Defines the maximum number of MAC-d PDUs to be stored in the
transmission buffer.
TTI_ : The duration of the Transport Channel's Transmission Time nterval (TT).
length_indicator_ : The size of a length indicator in bits, without the extension bit. When
the payload is less than 127 byte it is defined to be 7, otherwise it is defined to be 15.
min_concat_data_ : The minimum amount of bytes available to the next SDU before an
incomplete MAC-d PDU can be used for concatenation. Otherwise the MAC-d PDU will be
padded and sent without concatenation.

EURANE User Guide (ReIease 1.5) 15/02/2005


Page 15/31
4.3.4 UM-HS
This RLC entity is solely for use with the HS-DSCH, and has the following configuration pa-
rameters:

UMTS/RLC/UMHS set macDA_ -1
UMTS/RLC/UMHS set win_ 1024
UMTS/RLC/UMHS set temp_pdu_timeout_time 2ms
UMTS/RLC/UMHS set credit_allocation_interval_ 30ms
UMTS/RLC/UMHS set flow_max_ 20
UMTS/RLC/UMHS set priority_max_ 5
UMTS/RLC/UMHS set buffer_level_max_ 500
UMTS/RLC/UMHS set payload_ 40
UMTS/RLC/UMHS set TTI_ 2ms
UMTS/RLC/UMHS set length_indicator_ 7
UMTS/RLC/UMHS set min_concat_data_ 3

macDA_ : MAC destination address (Node D).

win_ : This defines the RLC Window Size, which is the amount of packets that can be sent
after the last acknowledged packet.
temp_pdu_timeout_time_ : This parameter defines the time in which a packet is held for
concatenation.
credit_allocation_interval_ : This parameter sets the number of timeslots between credit
requests to the MAC-hs. Credit allocation forms the basis of the flow control between the
RNC and MAC-hs in HSDPA.
14*2,* : Defines the maximum number of flows (or users).
priority_max_ : Defines the maximum number of priorities.
buffer_level_max_ : Defines the maximum number of MAC-d PDUs to be stored in the
transmission buffer.
payload_ : Defines the size of the MAC-d PDUs in bytes.
TTI_ : The duration of the Transport Channel's Transmission Time nterval (TT).
length_indicator_ : The size of a length indicator in bits, without the extension bit. When
the payload is less than 127 byte it is defined to be 7, otherwise it is defined to be 15.
min_concat_data_ : The minimum amount of bytes available to the next SDU before an
incomplete MAC-d PDU can be used for concatenation. Otherwise the MAC-d PDU will be
padded and sent without concatenation.

4.4 MAC/MAC-hs Configuration
As mentioned previously, there are two possible MAC architectures to choose from. The
basic MAC (Mac/Umts) used for the DCH and common channels (RACH and FACH), and
the more complicated MAC-hs (Mac/Hsdpa) used for the HS-DSCH.
The following are the parameters, for each type of MAC that are not specific to any particu-
lar functional algorithm. Due to the simplicity of the Mac/Umts entity, these are the only
parameters settings required for it.
Mac/Umts 809 delay_ 10us
Mac/Umts 809 TTI_ 10ms
EURANE User Guide (ReIease 1.5) 15/02/2005


Page 16/31
Mac/Umts 809 shared_delay_ 3ms

Mac/Hsdpa 809 delay_ 10us
Mac/Hsdpa 809 TTI_ 2ms

delay_ : The processing delay of the MAC.
TTI_ : The Transmission Time nterval of the MAC's associated transport channels.
shared_delay_ : The average delay experienced in accessing the RACH.

n the following subsections, the algorithm parameter settings for the ,.8/5, entity are
presented.
4.4.1 MAC-hs PDU Reordering
n HSDPA, at the BS MAC-hs, the different data flows are buffered separately by their flow
and priority combination. At the MAC-hs of the UE corresponding reordering queues for that
particular UE's flows and priorities are also formed. The following parameters enable the
creation of these buffers and queues, and the parameter values should correspond to the
identical parameter settings of the RLC entities, as described in Section 4.3.

Mac/Hsdpa 809 flow_max_ 20
Mac/Hsdpa 809 priority_max_ 5

flow_max_ : The maximum number of flows (or UEs).
priority_max_ : The maximum number of priority classes per flow.

At the UE the MAC-hs PDUs are reordered and disassembled into MAC-d PDUs. The reor-
dering queues have both a timer and window based stall avoidance measure implemented,
as defined in reference [1].

Mac/Hsdpa 809 reord_buf_size_ 64
Mac/Hsdpa 809 stall_timer_delay_ 25ms

reord_buf_size_ : The maximum size of the reordering buffers is limited, by the 6 bits avail-
able in the MAC-hs header for the Transmission Sequence Number (TSN), to 64. The size
of the stall avoidance window is always half of reord_buf_size_
stall_timer_delay_ : This parameter defines the time between the stall avoidance timer
being started and when it is utilised.

4.4.2 Credit AIIocation
The amount and rate of packet transmission between the RNC and BS is determined by the
flow control algorithm, which is based upon a credit allocation scheme [3].
Mac/Hsdpa 809 credit_allocation_interval_ 15
Mac/Hsdpa 809 flow_control_mode_ 1
Mac/Hsdpa 809 flow_control_rtt_ 30ms
Mac/Hsdpa 809 max_mac_hs_buffer_level_ 250

EURANE User Guide (ReIease 1.5) 15/02/2005

Page 17/31
credit_allocation_interval_ : The time, defined in the amount of TTs, between credit allo-
cation requests from the RNC to the BS.
flow_control_mode_ : The type of flow control algorithm to use. At present, only one algo-
rithm has been implemented, that monitors the size of each flow/priority buffer at the MAC-
hs, and ensures the amount of MAC-d PDUs in each does not exceed a maximum value.
This algorithm is chosen with the value set to 1.
flow_control_rtt_ This parameter defines the round-trip time (RTT) of the credit alloca-
tion, from the point that the MAC-hs allocates credits to the RNC, till the allocated packets
arrive at the MAC-hs. t is typically assumed to be equivalent to the RTT over the ub inter-
face, and should correspond to the values used when setting up the ub (see Section 3.3).
max_mac_hs_buffer_level_ : This defines the maximum allowable number of MAC-d
PDUs at the flow/priority buffers of the MAC-hs. This is the target value of the flow control
algorithm when flow_control_mode_ 880994.
4.4.3 ScheduIing
Every TT the MAC-hs checks the status of the flow/priority buffers, and depending on the
scheduling algorithm, determines which packets (and the amount) will be used to construct
a MAC-hs PDU for transmission.
Mac/Hsdpa 809 scheduler_type_ 1
Mac/Hsdpa 809 alpha_ 0.999

scheduler_type_ : This parameter defines the type of scheduling performed at the MAC-
hs. A value of 1 configures Round Robin Scheduling to be used, while a value of 2 would
configure the scheduling to be Maximum C/. A value of 3 would set the scheduler to oper-
ate as Fair Channel Dependent Scheduling (FCDS) 47(
,5,* : This parameter, used when the scheduler is set to FCDS defines the amount of
weighting used in the algorithm. A value of 0.0 would equate to the Round Robin case,
while a value of 1.0 would equate to the Maximum C/ case.
4.4.4 MAC-hs PDU Generation
Once the scheduling algorithm has made a decision, the packets are dequed from their
flow/priority buffer, concatenated and a MAC-hs header attached to form a MAC-hs PDU.
Mac/Hsdpa 809 mac_hs_headersize_ 21

mac_hs_headersize_ : This parameter sets the MAC-hs PDU header size, in bits, based
on the assumption that the size of the MAC-d PDUs remains constant for each flow. [21]
4.4.5 HARQ
The transmission of the MAC-hs PDUs to their respective UEs is achieved through the use
of parallel Stop-and-Wait (SAW) HARQ processes. The implemented HARQ algorithm uses
Chase-Combining, which utilises retransmissions to obtain a higher likelihood of packet ac-
knowledgment.
Mac/Hsdpa 809 nr_harq_rtx_ 3
Mac/Hsdpa 809 nr_harq_processes_ 6
Mac/Hsdpa 809 ack_process_delay_ 15us

37*,76*79* : This parameter defines the number of transmissions (NOT ReTransmis-
sions) of a MAC-hs PDU before it is assumed to be unreceivable. The parameter has a
maximum value of 3.
EURANE User Guide (ReIease 1.5) 15/02/2005


Page 18/31
nr_harq_processes_ : This defines the number of parallel SAW HARQ processes.
ack_process_delay_ : This represents the delay in clearing the HARQ process after it has
been Acknowledged (ACK), or finally Not Acknowledged (NACK).

4.5 PhysicaI Layer Configuration
The physical layer is represented by a standard 38 channel object, which is used to con-
nect the BS and UE. This is combined with the attachment of an error model.
Channel 809 delay_ 5us

set_delay_ : This parameter defines the transmission delay of a UMTS radio channel.

n the case of HSDPA, Chase Combining is used to increase the likelihood of acknowledg-
ment, but this also means that a more complicated transmission error model is necessary in
order to reflect this. The error model that has been implemented for this uses input from a
physical layer simulator to generate a BLER performance curve, and also an input trace file
of received powers. The generation and structure of these input files are further described
in Appendices A and B.

For the DCH, RACH and FACH transport channels a standard ns-2 error model was used,
and created/configured in the following way:

809 em_ [new ErrorModel]
$em_ unit pkt
$em_ 809 rate_ 0.02
$em_ ranvar [new RandomVariable/Uniform]

$node interface-errormodel $em_ <network interface number>

The last command is the only new one added to 38 by the UMTS implementation. t will
add an error model to the receive path of the specified interface on the given node (specifi-
cally, between the MAC and its upper layer).

4.6 Trace Support

Trace files using UMTS nodes and links are very similar to conventional ns-2 tracing. Spe-
cial UmtsTrace objects (class UmtsTrace derives from class Trace) are used to trace RLC
packets inside the UTRAN and the UE. These trace objects log those fields already logged
by the normal ns-2 trace objects plus one extra, the sequence number of the RLC packet
i.e. the trace format will change to:

Note that since fields seven to twelve relate to transport layer packets, this part of the trace
will be logged from the RLC SDU being transported inside the RLC PDU, allowing the user
to "see the SDU being transported inside the PDU. When (parts from) multiple RLC SDUs
are concatenated within the payload of a single RLC PDU, the trace information logged will
#.
806
Event
From
node
Time
To
node
Pkt
type
Pkt
size
Flags Fid
Src
addr
Dst
addr
Seq
num
Pkt
id
EURANE User Guide (ReIease 1.5) 15/02/2005


Page 19/31
correspond to the first of those SDUs. Simulating UMTS requires new packet types in 38,
and therefore the fifth field (pkt type) in the trace output can additionally be one of those
presented in Table 4-1.
TabIe 4-1: AdditionaI UMTS packet types

PKT Type ExpIanation
UM_Data UM data PDU
AM_Data AM data PDU
AM_Ack AM Positive acknowledgement (like in TCP)
AM_Bitmap_Ack AM Bitmap acknowledgement
AM_Piggybacked_Ack AM piggybacked Positive acknowledgement
AM_Piggybacked_Back AM piggybacked Bitmap acknowledgement

To enable tracing at all the wired nodes in the topology, use the following commands before
instantiating nodes and links:

809 f [open out.tr w]
$ns trace-all $f

Tracing at UMTS links needs to be specified per Network nterface (NF). To enable tracing
of a specific NF use the following commands:
$node trace-outlink $f <network interface number>
$node trace-inlink $f <network interface number>

To enable tracing of TCP PDUs received on a specific NF the following command is used:
$node trace-inlink-tcp $f <network interface number>

This command will put a receive trace between the RLC of that NF and the receiving agent.
The trace object will log events corresponding to the RLC layer sending up reassembled
RLC SDUs. Note that because the BS does not have any RLC entities, trace-inlink-
tcp can only be used for NFs at the UE or RNC.
5. Known Issues

5.1 HS-DSCH: Even number of UE nodes must be configured
Due to an undetermined error the construction method of the HS-DSCH return path (see
Figure 5-3 in Appendix D), a TCL error will occur if a simulation of an odd number of UEs is
performed. This can be avoided if an additional 'dummy' UE node is configured, but not
connected.


References
EURANE User Guide (ReIease 1.5) 15/02/2005


Page 20/31

[1] http://seacorn.ptinovacao.pt/
[2] 3GPP TS 25.321 V6.0.0, Technical Specification Group Radio Access Network;
MAC Protocol Specification, Release 6, January 2004.
[3] 3GPP TS 25.877 V5.1.0, Technical Specification Group Radio Access Network;
High Speed Downlink Packet Access: ub/ur protocol aspects, Release 5, June
2002.
[4] F. Brouwer, Usage of Link-Level Performance ndicators for HSDPA Network-Level
Simulations in E-UMTS, SSSTA 2004, Sydney, 2004.
[5] N. Whillans (editor), End-to-end network model for Enhanced UMTS, ST Seacorn
Project Deliverable D3.2v2, 2004.
EURANE User Guide (ReIease 1.5) 15/02/2005


Page 21/31
Appendix A: Pre-Processing
The pre-processing phase of the enhanced UMTS end-to-end P simulator consists of two
parts:
N generation of an SNR trace
N generation of the corresponding BLER / SNR curve

The SNR trace is further discussed in appendix B. The BLER/SNR curve is based on statis-
tics. The probability a block is received correctly depends on the SNR, the CQ of the block
and the implementation of the receiver. Each CQ has a specific relation between SNR and
block error rate (BLER). n [1] it was found that all these curves have the same shape and
only introduce a CQ specific constant offset.
nside the network-level simulator the UE indicates the CQ to the Node-B. The CQ repre-
sents the largest TBS resulting in a BLER of less than 0.1. There is no closed form solution
to express the CQ as function of BLER and SNR. For simplicity in the simulator, the relation
between CQ and SNR for a BLER of 0.1 is approximated through a linear function, based
on 3GPP standard [4]:
$#
$#
$#
$#
"
<=
< <
<=

+ =

.
The RMSE of this approximation is less than 0.05 dB, based on integer CQ values. Recall
that a CQ equal to 0 indicates out of range and the maximum CQ equals 30. So the func-
tion truncates at these limits.

The relationship between SNR and BLER is implementation dependent. Numerical results
of this relationship are provided by physical layer simulations. The curve used in this end-to-
end network simulator is SNR versus BLER in an AWGN channel. This curve is needed in
order to select the minimum SNR required for a specific transport block. This value is com-
pared with the actual channel condition in order to determine whether the transport block
triggers an ACK or a NACK. This process is illustrated in Figure A-1. First the model draws
a uniformly distributed random integer, pointing to a corresponding BLER rate class. The
range of this class is chosen small enough to consider it as a single value, :. This value is
than translated into a minimum SNR value through a look-up table, corresponding to the
AWGN curve which also includes the CQ number. This SNR
u
is kept during the HARQ re-
ception process and it decides between a NACK or an ACK. Note that also the CQ number
remains the same during the HARQ process.
EURANE User Guide (ReIease 1.5) 15/02/2005


Page 22/31
0.01
0.1
1
-5 -4 -3 -2 -1 0
SNR (dB)
B
L
E
R


Figure A-1: BLER versus SNR for reference curve (CQI = 1).

The data contained in the AWGN curve is used in the ns-2 simulator by means of a look-up
table, with filename SNRBLERMatrix, of length numSNR. t is imported as a 1000x30 matrix
containing the numSNR SNR values that correspond to the numSNR BLER classes. The
matrix can be made as long (i.e., as accurate) as we like. t is chosen such that the range of
the resulting class of SNR values is smaller than the error made in the curve fitting process
of the different CQ values.
This results in the schematic of the look-up table as shown in Table A-1:

TabIe A-1: Schematic of the BLER versus SNR Iook-up tabIe, SNRBLERMatrix.

CQ number Class # BLER Range
1 . 30
1 0-0.001 SNR
1,1

. SNR
1,30

2 0.001-0.002 SNR
2,1
. .
. . . . .
1000 0.999-1 SNR
1000,1
. SNR
1000,30


Summarizing:
N draw a integer between 1 and 1000
N this integer corresponds to a certain BLER range
N together with the CQ specific SNR-versus-BLER curve, this BLER range corre-
sponds to a certain SNR range
N this range is next reduced to a single SNR value (average of the SNR range)



SNR
u
Random u

EURANE User Guide (ReIease 1.5) 15/02/2005


Page 23/31
At first sight, the procedure described above, which from now on will be referred to as pro-
cedure A, seems more complicated than necessary. An alternative procedure (referred to
as B) would be to:
N Map the SNR to the corresponding BLER value (Fig A-1, with arrows in opposite di-
rection).
N Based on that BLER, determine the outcome, by means of a weighted toss, resulting
in an ACK or a NACK
For the first transmission of a packet, procedures A and B statistically give the same result.
A H-ARQ Retransmission is better modelled however by implementation A (Fig. A-1) since
alternative B does not correctly take pre-conditioning into account. Consider for example the
case that the SNR of the retransmission is extremely low, and no more information is added
to the overall power (data) already available at the user after the original transmission. The
overall SNR after the first Retransmission remains equal to the SNR of the original trans-
mission. The corresponding BLER also remains equal. However, the actual determination of
success is still random. The NACK of the first transmission might be followed by an ACK,
despite the fact that actually no more power (data) is available at the user. n procedure A,
the randomly picked BLER class (Fig. A-1) remains the same during the whole H-ARQ proc-
ess. By definition, the power (received data) can never decrease after a retransmission.
Thus procedure A is closer to how the real-time system works.

#010703.08
[1] Motorola and Nokia, Revised HSDPA CQI Proposal, R4-020612, 3GPP TSG-RAN Work-
ing Group 4 Meeting #22.
[2] F. Brouwer, Usage of Link-Level Performance ndicators for HSDPA Network-Level
Simulations in E-UMTS, SSSTA 2004, Sydney, 2004.
[3] N. Whillans (editor), End-to-end network model for Enhanced UMTS, ST Seacorn Pro-
ject Deliverable D3.2v2, 2004.
[4] 3GPP TS 25.214 V5.5.0, "Physical layer procedures (FDD), Release 5

EURANE User Guide (ReIease 1.5) 15/02/2005

Page 24/31
Appendix B: Input Trace FiIes
n this appendix we describe the format of the input trace file. This trace file is generated in
Matlab.
Since the number of input trace files to be generated will be huge, we start with some com-
mented information containing relevant parameters. The actual data is saved as a matrix of
4 columns and 3:2%%748
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Number of comment lines: 31
% Tracefile generated at: 15-Feb-2005 13:35:41
% in directory: /project/seacorn/Matlab
% with file name: output/Ray_corr-3kmh-500m-0-199.95s-UEnr1
% by: irene
% containing: P, P_1stRT, P_2ndRT, CQI
% i.e. P(t), MRC{P(t),P(t+H)}, MRC{P(t),P(t+H),P(t+2*H)}, CQI(.. P(t-D).. )
% with MRC=Maximum Ratio Combining technique
% with H=HARQcycle= 6
% and D=CQIdelayinTTI= 3
% with trace length (numTTItrace): 99974
% corresponding time interval in seconds: 1.999500e+02
% (Note that this is the time between stop and finish for the event
% scheduler in ns-2, which is longer than the time interval of the source)
% for user #: 1
% velocity (km/h): 3.00000000
% distance (m) from BS: 500.00000000
% which environment (nr,name): 1 Ray_corr environment
% BS Transmission power (dBm): 38
% Base station antenna gain (in dBi): 17
% Linit (distance loss at 1 km): 1.374000e+02
% Iintra (intra cell interference): 30
% Iinter (inter cell interference): -70
% HARQ cycle period: 6
% Time delay (TTI) in CQI: 3
% Minimum CQI value: 0
% Maximum CQI value: 30
% Percentage of adapted (too low) CQI values: 10
% Percentage of adapted (too high) CQI values: 0
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-11.39653819 -3.23906629 1.79447430 8
-10.79391795 -2.35008379 2.28501357 6
-9.35659589 -1.37460983 2.77595117 5
-7.87940480 -0.47598784 3.27475454 5
-6.52217991 0.20986639 3.71837398 6
-5.14451187 0.95224462 4.11469627 7
-3.95944035 1.58101639 4.51746459 8
-3.02074388 2.06583194 4.84659584 10
-2.12741461 2.50168597 5.06778610 11
-1.34753625 2.92835838 5.34592656 12
-0.82610851 3.28672301 5.65486774 13
-0.27205113 3.56643414 5.88381533 14
0.15901344 3.85230245 6.05700937 15
0.45440945 4.07174714 6.15460580 15

At TT_ t the information required for the HARQ process that starts at TT_ t, with
t[1,3:2%%], is loaded. The corresponding received power (in dB) is provided in the first
column. The power in the second column corresponds to the combination of the original
power and the retransmission power that is needed in case the first transmission is not suc-
cessful. Similarly the third column contains the power resulting from all three transmissions.
See for example the highlighted numbers: both first column powers -11.39653819 ,8
EURANE User Guide (ReIease 1.5) 15/02/2005


Page 25/31
well as -3.95944035 generate a power of value of -3.23906629 in the second col-
umn. Another six TTs later, also the power value of 0.15901344 is used to generate the
1.79447430 level in the third column.
The last column contains the CQ integer that should be used throughout this HARQ proc-
ess. See for example the underlined numbers: the first column power of -9.35659589
results in a CQ value of 7 three TTs later. t is based on a curve fitting process of physical
layer results, and eventually rounded down in order to make it an integer (this process is
described more extensively in Deliverable D3.2v2, which can be downloaded from the
Eurane website as well). The time delay needed to send this control information is already
included in the CQ value. Summarizing, all elements of this row belong to the HARQ proc-
ess that starts at TT_ t. n formulas this looks as follows:

1
st
column SNR
1
=P(t) SNR(t)
2
nd
column SNR
2
=P1stRT(t) {SNR(t),SNR(t+#"..0)}
3
rd
column SNR
3
=P2ndRT(t) {SNR(t), SNR(t+#"..0), SNR(t+2*#"..0)}
4
th
column CQ(t) $#9CQIdelayinTTIOffset

The second or third reception is soft combined with the previous received reception(s). This
soft combining is adding-up the signals in a maximum ratio combining fashion. The total
SNR after N (re)transmissions equals the sum of the SNRs of the individual receptions
(SNR expressed linearly):
4

b

3
837

3
$#
9
snr
1
=SNR(t)
snr
2
=SNR(t+1*HARQcycle)
snr
3
=SNR(t+2*HARQcycle)

The default setting of the variables used here is:
N HARQcycle=6
N CQdelayinTT=3
N Offset=16.62 based on the physical layer results

Some remaining remarks:
N One input trace file for each user
N A CQ value equal to zero implies the 'out of range' status for that user. To start with,
we will take a CQ value of 1 in these cases. We only consider users that most of the
time have a positive CQ value (otherwise these users should not be served on the
HS-DSCH). So at the actual moment of the first transmission the bad channel condi-
tions (on which the CQ equal to zero is based) may have improved such that the
transmission has a reasonable chance of success.
N Mind that the tracefile should last long enough in order to guarantee that when the
traffic source stops, the packets that are in the system still take some time.
EURANE User Guide (ReIease 1.5) 15/02/2005


Page 26/31
Appendix C: ExampIe TCL SimuIation Script
The following is an example simulation script for 2 UEs connected to an HS-DSCH. For the
script to work, the following additional files are needed:
N SNRBLERMatrix - An SNR to BLER look-up table.
N UE1_trace_file - An input trace file for UE1
N UE2_trace_file - An input trace file for UE2

4-,38

# Remove all Packet headers and add only those that are required.
# This significantly reduces the memory requirements of large simulations
remove-all-packet-headers
add-packet-header MPEG4 MAC_HS RLC LL Mac RTP TCP IP Common Flags

set ns [new Simulator]

set f [open out.tr w]
$ns trace-all $f

proc finish {} {
global ns
global f
$ns flush-trace
close $f
puts " Simulation ended."
exit 0
}

$ns node-config -UmtsNodeType rnc

# Node address is 0.
set rnc [$ns create-Umtsnode]

$ns node-config -UmtsNodeType bs \
-downlinkBW 32kbs \
-downlinkTTI 10ms \
-uplinkBW 32kbs \
-uplinkTTI 10ms \
-hs_downlinkTTI 2ms \
-hs_downlinkBW 64kbs \

# Node address is 1.
set bs [$ns create-Umtsnode]

# Interface between RNC and BS
$ns setup-Iub $bs $rnc 622Mbit 622Mbit 15ms 15ms DummyDropTail 2000

$ns node-config -UmtsNodeType ue \
-baseStation $bs \
-radioNetworkController $rnc

# Node address for ue1 and ue2 is 2 and 3, respectively.
set ue1 [$ns create-Umtsnode]
set ue2 [$ns create-Umtsnode]

# Node address for sgsn0 and ggsn0 is 4 and 5, respectively.
set sgsn0 [$ns node]
set ggsn0 [$ns node]

# Node address for node1 and node2 is 6 and 7, respectively.
set node1 [$ns node]
set node2 [$ns node]

# Connections between fixed network nodes
EURANE User Guide (ReIease 1.5) 15/02/2005


Page 27/31
$ns duplex-link $rnc $sgsn0 622Mbit 0.4ms DropTail 1000
$ns duplex-link $sgsn0 $ggsn0 622MBit 10ms DropTail 1000
$ns duplex-link $ggsn0 $node1 10MBit 15ms DropTail 1000
$ns duplex-link $node1 $node2 10MBit 35ms DropTail 1000
# Routing gateway
$rnc add-gateway $sgsn0

# Agent set-up for ue1
set tcp0 [new Agent/TCP]
$tcp0 set fid_ 0
$tcp0 set prio_ 2

# Agent set-up for ue2
set tcp1 [new Agent/TCP]
$tcp1 set fid_ 1
$tcp1 set prio_ 2

# Attach agents to a common fixed node
$ns attach-agent $node2 $tcp0
$ns attach-agent $node2 $tcp1

# Create and connect two applications to their agent
set ftp0 [new Application/FTP]
$ftp0 attach-agent $tcp0

set ftp1 [new Application/FTP]
$ftp1 attach-agent $tcp1

# Create and attach sinks
set sink0 [new Agent/TCPSink]
$sink0 set fid_ 0
$ns attach-agent $ue1 $sink0

set sink1 [new Agent/TCPSink]
$sink1 set fid_ 1
$ns attach-agent $ue2 $sink1

# Connect sinks to TCP agents
$ns connect $tcp0 $sink0
$ns connect $tcp1 $sink1

$ns node-config -llType UMTS/RLC/AM \
-downlinkBW 64kbs \
-uplinkBW 64kbs \
-downlinkTTI 20ms \
-uplinkTTI 20ms \
-hs_downlinkTTI 2ms \
-hs_downlinkBW 64kbs

# Create HS-DSCH and attach TCP agent for ue1
$ns create-hsdsch $ue1 $sink0

# Attach TCP agent for ue2 to existing HS-DSCH
$ns attach-hsdsch $ue2 $sink1

#Loads input tracefiles for each UE, identified by its fid_
$bs setErrorTrace 0 "UE1_trace_file"
$bs setErrorTrace 1 "UE2_trace_file"

# Load BLER lookup table from file SNRBLERMatrix
$bs loadSnrBlerMatrix "SNRBLERMatrix"

# Tracing for all HSDPA traffic in downtarget
$rnc trace-inlink-tcp $f 0
$bs trace-outlink $f 2

# UE1 Tracing
$ue1 trace-inlink $f 2
$ue1 trace-outlink $f 3
$bs trace-inlink $f 3
$ue1 trace-inlink-tcp $f 2

EURANE User Guide (ReIease 1.5) 15/02/2005


Page 28/31
# UE2 Tracing
$ue2 trace-inlink $f 2
$ue2 trace-outlink $f 3
$bs trace-inlink $f 4
$ue2 trace-inlink-tcp $f 2

$ns at 0.0 "$ftp0 start"
$ns at 0.002 "$ftp1 start"
$ns at 10.1 "$ftp0 stop"
$ns at 10.102 "$ftp1 stop"
$ns at 10.201 "finish"

puts " Simulation is running ... please wait ..."
$ns run
EURANE User Guide (ReIease 1.5) 15/02/2005


Page 29/31
Appendix D: Transport ChanneIs - A schematic View
FACH and RACH
Figure 5-1 shows the interconnection of the main UMTS TCL objects for the case where two
UEs are created but only one is connected to an Application/Agent. At UE-1, two Applica-
tions are connected in Acknowledged Mode (AM), using the RACH and FACH for transport.
The Network nterface (NF) numbers can be seen for each node.


Figure 5-1: Transport over Common ChanneIs (RACH and FACH)
RNC

PRACH SCCPCH
ub
UE- 1 (ID:2)
Agent-1
NF stack
UE-2 (ID:3)
RACH FACH
PHY_RX PHY_TX
0
MAC
1
MAC
PHY_RX PHY_TX
0
MAC
1
MAC
2 3
AM AM
BS (ID:1)
MAC MAC
PHY_RX PHY_TX
0 1
RACH FACH
SGSN
0 1
AM AM
Agent-2
FACH RACH
RNC (ID:0)
EURANE User Guide (ReIease 1.5) 15/02/2005


Page 30/31

DCH
n Figure 5-2, the implementation shown is for a single UE using a DCH as its transport
channel. Note, that although the Common channels are not used, they are always con-
structed when the BS and UE nodes are created. Also, the RLC for the DCH belongs to the
same NF stack as that of the MAC and PHY.


Figure 5-2: Transport over a Dedicated ChanneI (DCH)

UE- 1 (ID:2)
MAC MAC
PRACH
ub
BS (ID:1)
RACH FACH
RACH FACH
MAC MAC
PHY_RX
MAC
PHY_TX
AM
DPDCH DPDCH
PHY_TX
MAC
PHY_RX
PHY_RX PHY_TX
PHY_RX PHY_TX
RNC (ID:0)
AM
2
2
0
Agent
SGSN
SCCPCH
0 1
0 1
DCH
DCH
EURANE User Guide (ReIease 1.5) 15/02/2005


Page 31/31
HS-DSCH
n Figure 5-3, the implementation shown is for two connected UEs over a HS-DSCH trans-
port channel. t should be noted that although the FACH and RACH are created automati-
cally, they have been omitted from the figure for clarity.



Figure 5-3: Transport over HS-DSCH

&
MAC-HS
AM 2
Agent
MAC
PHY_TX PHY_RX
3
UE-1 (ID:2)
UE- 1
MAC-HS
AM 2
Agent
MAC
PHY_TX PHY_RX
3
UE-2 (ID:3)
HS-PDSCH DPDCH DPDCH
PHY_RX
MAC
PHY_TX
MAC-HS
PHY_RX
MAC
3
4 2
BS (ID:1)
ub
AM-HS
0
RNC (ID:0)
SGSN