Access between 3G WCDMA multimedia wireless packetswitched and fixed networks simulation using OPNETTM

A Heath BEng(Hons), MEng, AMIEE and R A Carrasco BSc(Hons), PhD, CEng, FIEEA.L.Heath@staffs.ac.uk, R.A.Carrasco@staffs.ac.uk

Staffordshire University, U.K.

AbstractA new resource management strategy, whichimproves packet latency and reduces signallingtraffic, is proposed. The channel allocationalgorithm proposed is efficient in that it allows anOrthogonal Variable Spreading Factor (OVSF) codeto be allocated only whilst a user has packets totransmit. There are a limited number of downlinkcodes and the amount of signalling required will beevaluated. The system performance is evaluated interms of packet latency, transmitted/received anddropped traffic for different applications, coderequest statistics and scramble code allocation at theMobile Station (MS) and Base Station (BS).

Keywords3G, WCDMA, UMTS, IP, TCP, UDP, MobileCommunications

IntroductionIn future wireless access networks it is anticipatedthat wireless, wired and satellite communicationswill consist of one hierarchical cellular structure inwhich multimedia data will be transferred [1]. Datatraffic is increasing at a much faster rate than voice,so new and efficient mediums are required totransport this information. In future third generation(3G) systems, such as Universal MobileTelecommunications System (UMTS) there areseparate circuit and packet switched channels; in thispaper an entirely packet switched system isproposed, in which all services are treated in thesame way. Mixed data types are transmitted across aWCDMA air interface via an IP based UMTS accessnetwork. Code request statistics, mean codes used,traffic mix, end-to-end packet delay and mean valuesof different traffic transmitted, BS throughput andutilisation is measured. The system proposed in thispaper is a continuation of the work presented in [2].In [2], no packets are dropped, but are queued untilthey are transmitted across the communicationchannel, increasing the packet latency. In this paperthe channel allocation algorithm is introduced, whichlimits the number of times a channel can berequested, this results in significantly reducing thepacket latency with a slight reduction in the amountof overall traffic transmitted. Similar issues havepreviously been studied in an ATM access networkusing a service adaptable virtual connection treealgorithm in [3, 4, 5]. The simulation models

presented in this paper have been developed within asoftware environment, are generic and can be testedover different network layer protocols, such asATM, MPLS and IPv6.The following section presents the background ofmobile communications and fixed packet switchednetworks. Whilst the third section introduces theprinciples of WCDMA, scrambling and spreadingcodes. The fourth section describes the simulationtool and the models developed, then in the followingsection the simulation is explained and the resultsdiscussed. The final section draws conclusions andmakes suggestions for future work.

BackgroundMobile communications have always beenassociated with circuit switched voice services, thesebeing first generation analogue and second-generation digital. There are many differentincompatible standards throughout the world, i.e. auser is unable to use the same mobile deviceglobally. The aim of the third generation (3G)technology is to allow global harmonisation, the ITUset up the third generation partnership project groups3GPP [6] and 3GPP2 to develop InternationalMobile Telecommunications 2000 (IMT-2000). TheInternet Engineering Task Force (IETF) is the bodyresponsible for standardising the Internet Protocols.These are presented, as request for comments,(RFCs); if there is no objection after a period of timethen the comment becomes a standard [7].The Internet Protocol (IP) is a network layerprotocol that is responsible for the routing of theindividual packets which may have to traverseseveral different networks [RFC 791]. There are twodifferent versions of IP, version 4, which is currentlyused and the updated version 6. Version 6 [RFC2460] has been developed to allow more IPaddresses and to improve the quality of service fordifferent applications. The main difference betweenthe two versions of IP are that the header size hasdoubled in size from 20 to 40 bytes.The Transmission Control Protocol (TCP, [RFC793]) is a connection orientated transport layerprotocol that breaks the message into segments at thesource and re-assembles them at the destination, re-sending any that are incorrectly sequenced, lost orcorrupt. This can cause packets to have extremelylong end-to-end delays and for this reason real-timeservices utilise another protocol: the user datagram

protocol (UDP, [RFC 768]). UDP is aconnectionless transport layer protocol and wasdesigned for applications where packet sequencesare not re-assembled at the destination. UDP iscurrently being used for real-time applications alongwith Real Time Protocol (RTP) and Real TimeStreaming Protocol (RSTP).IP can also be deployed over Asynchronous TransferMode (ATM) which is a wired infrastructure thatprovides excellent QoS guarantees, but does notprovide and end-to-end IP solution. In previouswork ATM has been tested at speeds of up to2Mbits/s for the service adaptable handoff algorithmusing different multiple access schemes. Fig. 1shows different future methods of communicationwith a common network layer protocol.

Voice Packet

Switched

M3 Circuit Switched

Fixed Network:

ATM, IPv4/6,

PSTN, ISDN xDSL

Wireless Personal Area Net (WPAN)

Mobile Access Network

(UTRAN)

Hierarchical Cell Structure M3

Satellite Access

Network

Fig. 1 Converged networksIdeally a single device will be used for cellular,ADSL, satellite and WPAN environments to accessthe fixed network dependent on the user’s location.

Wideband CDMA (WCDMA)WCDMA will be used in Europe and Asia, includingJapan and Korea and was Japan’s proposal for the3G air interface. WCMDA is a Direct-SequenceCDMA system, i.e. user information bits are spreadover a wide bandwidth by multiplying them withquasi-random bits that are derived from orthogonalspreading codes [8]. In order to support differentdata rates OVSF codes are used [9]. The chip rate of3.84Mchips/s leads to a carrier frequency ofapproximately 5MHz. There are two modes ofoperation frequency division duplex (FDD) and timedivision duplex (TDD). FDD uses different uplinkand downlink frequencies, whereas in TDD theuplink and downlink packets are given differenttime-slots. Global frequency bands have beenagreed at the World Radio Conference (WRC 2000)at around 2GHz for 3G networks.Scrambling codes are used to separate terminals orBSs from one another [8]. Scrambling is used as wellas spreading, it does not change the signal’sbandwidth but makes signals from different sourcesseparable from one another. The simulation of theallocation and de-allocation of these scramblingcodes has been presented in this paper. There are512 downlink-scrambling codes [2], so this paperproposes a way of allowing multiple users to sharethose codes. When using scrambling the actualspreading can be achieved with identical OVSF

codes from different transmitters and so no controlinformation need be exchanged.

System ModelThe simulation model is constructed using two userdefined nodes, the base station (BS) and the mobilestation (MS) and two radio links. The radio link’scharacteristics are modified by one or more of thefourteen design stages of the radio transceiver. Anexample network is shown in Fig. 2.

Fig. 2 Network nodesThe user defined nodes are the MS and the BS. Thenodes are connected together using 10BaseTstandard links. The application configurationspecifies arrival rates for the different applicationsand the traffic profile is a definition of the differentuser profiles. There are three user profiles: cellular,handheld and laptop. The cellular profile consists ofa voice application with a ToS of 6. The handheldprofile consists of light email, light database accessand heavy web browsing. The laptop user’s profileincludes heavy email, light FTP, heavy databaseaccess and web browsing. The three types of MSnode are exactly the same; it is the applicationprofiles that are different.Fig. 3a, illustrates the protocols inside a MS node.The processes are defined using finite statemachines. CDMA_TX and CDMA_RX are theradio transmitter and receiver nodes respectively andhave a standard isotropic antenna pattern. QPSKmodulation is employed and the wireless channeldata rate is 1,536,000 bits/sec and transmitted at anequivalent isotropic radiated power (EIRP) of26dBm.The CDMA_MAC process is the WCDMA airinterface, which is original to this work and isdefined by dynamic processes which are createdduring a simulation and are illustrated in Fig. 3b.The MS is initialised and has an IPv4 addressassigned to it, the Wait state is then enterred. Thetransmission and receive processes are modelleddynamically and can occur simultaneoulsy from theWait state (parallel processes). When the MS has anuplink IP packet to send a code request message issent to the BS on the control channel. The MS thenawaits a response from the BS or a timeout period,whilst queuing uplink packets.

a) b)

Initialise

Rx dl Pkts !Last Pkt

UL IP pkt to send

Wait

Code Req to

BS, Start Timer

Q UL Pkt

Empty Q

UL Pkt Arrive, cancel timer

!UL Pkt Arrive && Timeout

Last Pkt Rx DL code from BS

Send dealloc

code msg to BS

Code Alloc’d, cancel timer

!Empty Q || Q UL Pkt

Encaps UL pkt, send to

BS

Start Timer

!Code Alloc’d

Channel alloc alg

Fig. 3 MS node modelIf a code is not allocated within the timeout periodthen the channel allocation algorithm is executed, asin Fig. 4 until such a time that a code is allocated orthe packet is dropped.When a code is allocated, the MS de-queues,encapsulates and transmits the uplink packets acrossthe air interface in 10ms frames to the BS. Whenthere are no packets left in the queue , the code isretained for the channel-hold time. If the channel-hold time elapses and no more uplink packets arrive,a code de-allocate message is transmitted to the BSand the code is released and made available for useby other users. For the receiving process, the MSawaits a downlink code allocation message on thecontrol channel from the BS. When a downlink codehas been allocated packets are received with theallocated scrambling code until a code de-allocationmessage is received.

Start

Receive pktto send to BS

Code allocated?

Set Counterto zero

Counter<maxattempts?

Request code fromlocal BS

Increment Counter

CodeAllocated?

Request timedout?

Tx pkt usingallocated code

Drop pkt

Yes

No

Yes

No

Yes

No

Yes

No

Fig. 4 Channel allocation algorithmFig. 5 shows the state machine of the BS, there arefour events that could occur simultaneously, namely:1. Receive an uplink code request from a MS; 2.Receive an uplink IP packet; 3. Receive an uplinkcode de-allocate request or 4. Receive a downlink IPpacket for a MS currently in the BS’s cell.

Found UL code

UL IP Pkt

DL IP pkt to send to MS

Wait

Dealloc UL code,

send delloc msg to MS

Decaps & send pkt

through IP to dest

UL dealloc req msg from MS

UL code req msg from MS

Send MS code

alloc’d msg on cc

!Found UL code

DL code alloc’d

Found a free DL code

!DL code alloc’d

!Found a free DL code

Empty DL Q for this MS

DL pkt for this MS

Timeout

Q DL pkts || !Found a free DL code

Q DL pkts

Q DL pkts

Q DL pkts Search for

alloc’d code

Q DL pkts

Channel alloc alg

Dealloc DL code to

MS, send last pkt

Initialise

Start Timer

Send code to

MS on cc

Search for free UL code

Encaps & send pkt

at head of Q

Search for free

code

Send MS code not alloc’d

msg on cc

Fig. 5 BS node model

When an uplink code request is received from a MS,a free code is searched for, if one is found, it is sentto the MS on the control channel. If there are no freechannels then a code not allocated message is sent tothe MS. If an uplink IP packet is received from aMS it is de-capsulated and then re-assembled in abuffer before being forwarded to its final destinationacross the fixed IP network. When the BS receivesan uplink code de-allocation request, the code isfreed and is available for use by other users.If the BS receives a downlink IP packet, which mustbe forwarded to a MS located within the cell, thepacket is placed in a queue (a separate queue isgenerated for each MS) and if the MS already has adownlink code then the packet is encapsulated andtransmitted to the MS. If there is no code alreadyallocated to the MS then one is searched for, if thereare no free codes the packets are queued until onebecomes available. When a new code is found, amessage is transmitted to the MS on the controlchannel, and the packets are encapsulated andtransmitted to the MS. The BS transmits all thepackets in the queue to the MS, until the queue isempty. If no more packets arrive within the channelhold time then the code is de-allocated and a lastmessage is sent to the MS.The simulation was run for an hour, with 105 MSscomprising of: 31 mobile telephones; 33 handheldterminals and 41 laptop computers. Initially themaximum code attempts was set to ∞ then to 5.

Simulation ResultsFig. 6 shows the scramble codes allocated to arandom laptop computer, handheld terminal andmobile phone in a network with 105 MSs and 1 BS.

17

10

5

10

15

20

20 21 22 23 24 25

Time (min)

Tx

Scra

mbl

e C

ode

Laptop Handheld Cellphone

Fig. 6 Transmission Scramble codes at the MSThe mobile telephone holds on to scramble code 17for 1.5s and later code 1 for more than 0.5s, this isbecause the hold time is set for 0.1s this was foundto be the optimal setting for this network, due tothere being distinct on and off periods. This is nottrue for the laptop computer or handheld terminal asthey both send packets continually but at differentrate to a voice application. The hold times for otherapplications are set to zero, and a code must be

obtained every time a packet is sent, as these patternsare more sporadic. Fig. 7 shows the code requeststatistics for a network containing 105 MSs with themaximum code allocation attempts set to ∞ and 5.

7.97

2.27

1.15

4.63

1.240.85

6.84

4.24

0

2.5

5

7.5

10

Requests RequestTimeouts

De-allocationAttempts

De-allocationTimeouts

Req

uest

s/D

e-al

loca

te (a

ttem

ps/s

ec)

Infinite Attempts 5 Attempts

Fig. 7 WCDMA Code request statisticsReducing the number of times that a code can berequested has resulted in a drop of approximately40% traffic on the control channel. 28.54% of coderequests timeout for ∞ attempts compared to 26.78%for 5 attempts an improvement of 1.76%. Conversely16.85% of de-allocate requests timeout for ∞attempts compared to 20.11% for 5 attempts areduction of 3%, this is the trade-off for reducing thesignalling traffic by 40%. There are no code requestfailures because the number of available codes ishigh, the timeouts occur because there is congestionon the control channel. The average number ofcodes in use at any one time is shown in Fig. 8.

4.81

13.19

3.45

1.15

0

5

10

15

Downlink Codes Uplink Codes

Mea

n C

odes

Use

d

Infinite Attempts 5 Attempts

Fig. 8 Mean number of codes usedThere are less codes being used in the system with 5attempts, 28% less downlink and 93% less uplinkcodes, this means that there is much less interferencein the 5 attempts network for the same amount ofusers trying to transmit the same amount of data.Packet latency for different applications is shown inFig. 9, for ∞ and 5 attempts. The packet latency forvoice packets is shortest in both cases, however themean values dropped from 0.17s to 0.03s, when thenumber of attempts was reduced from ∞ to 5attempts, this represents and 84% drop in mean

packet latency. Even the peak value for the systemwith 5 request attempts is 0.1s, which is well belowthe noticeable value of 0.25s.

0.17

0.03

8.15 9.43

1.51 1.37

38.03

0.34

28.05

63.93

0.01

0.1

1

10

100

Infinite Attempts 5 Attempts

Mea

n Pa

cket

Lat

ency

(sec

)

Voice Email FTP HTTP Database

Fig. 9 Mean Packet LatencyThe packet latency for Email and HTTP haveimproved most significantly 8.15-0.34s and 28.05-1.37s respectively, this is a 95% improvement inboth cases. FTP has improved by 84% and databaseby 68%, so overall packet latencies have improvedsignificantly. Fig. 10 shows the average quantity oftraffic transmitted for each case.

1,265

27 22

3440

722632

1,535

5,793 5,161

783

1

10

100

1,000

10,000

Infinite Attempts 5 Attempts

Mea

n Tr

ansm

itted

Tra

ffic

(byt

es/se

c)

Voice Email FTP HTTP Database

Fig. 10 Mean transmitted trafficThis graph shows the reduction in the amount oftransmitted traffic by application. The quantity ofvoice traffic transmitted compared to the otherapplications was the highest in both cases Voicetraffic dropped from 5,793-5,161bytes/s which is areduction of 10% when the number of channelrequests was reduced to 5. this is a small amount ofextra traffic dropped in comparison to the 84%packet latency improvement. There is more databasetraffic transmitted in the second network, withaverage values from 632-1,535 bytes/s which is anincrease of 43%. The most significant drop intransmitted traffic is Email which dropped from1,265-783 bytes/s which is a decrease of 38%.Fig. 11 shows the traffic transmitted compared thatreceived and therefore the traffic dropped for the twocases. This graph shows that the mean values fortransmitted, received and dropped traffic are

decreased when the number of code attempts islimited to 5.

17,940

9,8538,087

13,485

7,2106,274

0

5,000

10,000

15,000

20,000

Tx Rx Dropped

Tra

ffic

(byt

es/se

c)

Infinite Attempts 5 Attempts

Fig. 11 Transmitted, Received & Dropped TrafficThe amount of traffic dropped or lost on the radiolink falls from 8,087-6,274 bytes/s which is a22.42% decrease. The mean and peak values ofpacket loss ratio are shown in Fig. 12, these lossesare due to dropping, radio interference and queueoverflow.

0.1006

0.3425

0.1008

0.7742

0

0.25

0.5

0.75

1

Mean Peak

Mea

n pa

cket

loss

rat

io

Infinite Attempts 5 Attempts

Fig. 12 Mean & Peak packet loss ratiosThe mean packet loss ratios are very similar, 5attempts being 0.19% more than ∞ attempts.However, the peak values show that 26% moretraffic is dropped within the 5 attempts network. InFig. 13 it is illustrated how these packet losses aredivided between different applications.

315.20

2.78

237.99

6,756.06

775.22786.60

1.94 2.34

5,334.87

148.61

1

10

100

1,000

10,000

Voice Email FTP HTTP Database

Tra

ffic

(byt

es/se

c)

Infinite Attempts 5 Attempts

Fig. 13 Traffic dropped by application

The amount of traffic dropped for voice is verysimilar for the two cases, a 1.46% increase when thenumber of attempts is changed ∞ to 5. For the otherapplications the traffic dropped is reduced, the mostsignificant being HTTP from 237.99-2.34 bytes/swhich is a reduction of 99%. The most droppedtraffic was database and least was FTP in both cases.The mean frequency throughput and utilisation of thenetwork is 40% less, when 5 attempts werestipulated instead of ∞ attempts, this shows that lessresources are being utilised.

ConclusionA WCDMA air interface has been successfullyimplemented and simulated. A channel allocationalgorithm is being designed so that a limit is placedon the number of times that a code can be requested.This has resulted in packet latency being reduced by93% and the transmitted traffic has only reduced by36%, when the maximum code request attempts wasset to 5. The amount of signalling traffic has beenreduced by 40%, which was the reason for the lowerpacket latencies. The optimum setting for thenumber of times a code can be requested will beobtained by exhaustive searching. It is expected thatthis will be different for different applications i.e. alower value for voice where latency is most criticaland a higher value for HTTP and FTP where packetloss is more critical. For video applications it isexpected to lie somewhere between the two. Furtherwork includes: designing handoff policies usingCellular IP [10] or HAWAII [11] using ahierarchical cell structure ;investigating the effect ofblocking users; allowing users to transmit at variousdata rates simultaneously and signallingmeasurements incorporating either SIP [12] or H.323[13], so this will be compatible with signallingsystem number seven (SS7).

References1. Godara L C, Ryan M J, Padovan N, ‘Third

generation mobile communication systems:Overview and modelling considerations’Annales des Telecomms/Annals of Telecommsvolume: 54, number: 1, (1999, p 114-136)

2. Heath A L, Carrasco R A, 'Simulation of Accessfor 3G IP WCDMA to fixed packet switchednetworks using OPNETTM' IEE ElectronicsLetters, accepted for publication (02 May 2001)

3. Larrinaga F, and Carrasco R A, ‘VirtualConnection Tree Concept Application overCDMA Based Cellular Systems’ IEEColloquium on ATM Traffic in the PersonalMobile Communications Environment, SavoyPlace, London (11 Feb 1997)

4. Heath A L, Carrasco R A, ‘Virtual ConnectionTree over Multiple Access Techniques For 3GWireless Communication Systems’, IEE/IEEESecond International Symposium onCommunication Systems, Networks And DigitalSignal Processing (CSNDSP2000)Bournemouth University (18-20 Jul 2000)

5. Heath A L, Carrasco R A, 'Virtual ConnectionTree based algorithms for 3G MobileCommunication Systems', Prep2000Engineering and Physical Sciences ResearchCouncil, EPSRC Conference (11-14 Apr 2000)

6. 3GPP Home page: http://www.3gpp.org/7. RFC Home Page: http://www.faqs.org/rfcs/8. Holma H., Toskala A., ‘WCDMA for UMTS

Radio Access for third Generation MobileCommunications’, John Wiley and Sons (Aug2000) {WCDMA for UMTS}

9. Adachi F, Sawahashi M, Okawa K, ‘Tree-structured generation of orthogonal spreadingcodes with different lengths for forward link ofDS-CDMA mobile radio’, Electronics Letters,volume:33, number:1, (Jan 2 1997, p 27-28) 393

10. Campbell A T, Gomez J, Kim S, Valko A G,Chieh-Yih W, Turanyi Z R, ‘Design,implementation, and evaluation of cellular IP’,IEEE Personal Communications, volume: 7issue: 4 (Aug 2000, p 42-49) {434-22}

11. Ramjee R, La Porta T, Thuel S, Varadhan K,Wang S Y, ‘HAWAII: a domain-based approachfor supporting mobility in wide-area wirelessnetworks’, Proceedings of the 1999 7thInternational Conference on Network Protocols(ICNP'99) sponsored by IEEE ComputerSociety (Nov 1999, p 283-292) {440-22}

12. Schulzrinne H, Rosenberg J, ‘Session initiationprotocol: Internet-centric signalling’, IEEECommunications Magazine, volume: 38,number: 10, (Oct 2000, p 134-141) {441}

13. Wanjiun L, ‘Mobile Internet telephony: Mobileextensions to H.323’, INFOCOM '99.Eighteenth Annual Joint Conference of the IEEEComputer and Communications Societies,volume: 1 (1999 p 12 –19) {245-18}

Access techniques for 3G multimediaAccess techniques for 3G multimediawireless packet switched networks wireless packet switched networks

Alison HeathBEng (Hons), MEng, AMIEEA.L.Heath@staffs.ac.ukhttp://www.soc.staffs.ac.uk/~cmrah

and

Professor Rolando CarrascoBSc(Hons), PhD, CEng, FIEER.A.Carrasco@staffs.ac.uk

School of Computing

2

IndexIndex

� Introduction�Aims, multiple access techniques, mobile communication

evolution, future converged networks� Code Holding Technique, Channel Allocation

Algorithm� Mobile Station & Base Station� Simulation Parameters� Results: code alloc/dealloc stats, latency,

transmitted traffic and dropped traffic statistics� Conclusions

3

Introduction, aims of researchIntroduction, aims of research

� Accommodate mixed information types�different QoS requirements (delay sensitive, loss sensitive)�Multimedia applications; Voice, web browsing, e-mail,

voice, video conferencing, file transfer, database access

� Mobility and high bit rates (>2Mbps) with a finitebandwidth

3GSystems

VoiceData

M3

4

Multiple Access TechniquesMultiple Access Techniques

Code

Frequency

Time

Cha

nnel

1C

hann

el 2

Cha

nnel

3

Cha

nnel

NFDMA Code

Frequency

Time

Channel 1Channel 2

Channel 3

Channel N

Time S

lots

TDMA

Code

Frequency

Time

Channel 1Channel 2Channel 3

Channel N

CDMA

PRMA

pkt Npkt 1 pkt 2 pkt 3

5

Mobile Communication EvolutionMobile Communication Evolution

� 1G Analogue, cct sw� 2G Digital, cct sw� 3G Digital, pkt sw

� High bw, broadband systems

� Multi media applications

� Single set of services

� Anytime, anyplace communications

� Packet based transport mechanismsTCP

IS-95

HSCSD

GPRS

cdma2000 WCDMA

IMT-2000,UMTS

Voice

GSM

Data Voice Data

IS-136

SecondGeneration

Systems

ThirdGeneration

Systems

ATM

TransportMedium

TransportMechanism

USAKorea Europe

JapanKorea

EDGE

UDP

IS-41

IPv4 v6MPLS

6

Standardisation BodiesStandardisation Bodies

� ITU

� Internet Engineering Task Force,�Request for Comments

http://www.faqs.org/rfcs/

7

Access Transmission SpeedsAccess Transmission Speeds

Basic second generation (GSM, IS-95, IS-136, PDC)

Evolved second generation (GSM HSCSD and GPRS, IS-95B)10 kbps

144 kbps

2Mbps

384 kbps

GSM EDGE

IMT-2000

Fixed/Low Mobility Wide Area/High Mobility

User Bit Rate

8

Enabling Air InterfacesEnabling Air Interfaces

� Global frequency bands agreed around 2GHz for3G�WCDMA

� Direct Spread, 5MHz bw, chip rate 3.84/7.68/15.36Mchips/s,10/20ms frames

� cdma2000� Direct Spread or multicarrier, 1.26MHz bw, 1.2288Mchips/s

(n=1, 3, 6, 9, 12) backward compatible with IS-95

� Allows users of 3G terminals to use existing 2Ginfrastructure�EDGE - Enhanced Data Rates for GSM evolution, TDMA

9

Converged NetworksConverged Networks

Voice Packet

Switched

M3 Circuit Switched

Fixed Network:

ATM, IPv4/6, Diff Serv, MPLS

PSTN, ISDN xDSL

Wireless Personal Area Net (WPAN)

Mobile Access Network

(UTRAN)

Hierarchical Cell Structure M3

Satellite Access

Network

IP in the RAN is currently being standardised andshould be completed by December 2001.

Ideally a single device will be used for cellular,ADSL, satellite and WPAN environments to accessthe fixed network dependent on the user’s location

(scalable structure).

10

Code Holding TechniqueCode Holding Technique

http://www.opnet.comEfficient code holding technique for WCDMA FDD Interfaceusing IP, which reduces the number of codes used and allows

BandWidth to be supplied On Demand (BWOD).

The channel allocation algorithm reduces latencies considerably.

Mixed data types (Voice,email, FTP, HTTP, database

query & entry) are transmittedacross a common WCDMA

FDD air interface.

11

Mobile Station, MSMobile Station, MS

Rx dl pkts !Last Pkt

Last Pkt Rx DL code from BS

!UL Pkt Arrive && Timeout

Send dealloc

code msg to BS

Empty Q

UL Pkt Arrive, cancel timer

!Empty Q || Q UL Pkt

Encaps UL pkt, send to

BS

Start Timer

Code Alloc’d,cancel timer

!Code Alloc’d Channel alloc alg

UL IP pkt to send

Code Req to

BS, Start Timer

Q UL Pkt

Rx dl Pkts !Last Pkt

Last Pkt Rx DL code from BS

Empty Q

UL Pkt Arrive, cancel timer

!Empty Q || Q UL Pkt

Encaps UL pkt, send to

BS

Start Timer

UL IP pkt to send

Code Req to

BS, Start Timer

Q UL Pkt

Code Alloc’d,cancel timer

!Code Alloc’d Channel alloc alg

!UL Pkt Arrive && Timeout

Send dealloc

code msg to BS

Initialise Wait

12

Channel Allocation AlgorithmChannel Allocation Algorithm

Initialise Wait

Rx pkt to Tx across air interface

Initialise Counter

!ChannelAlloc’d

Increment

counter

Rx pkt to Tx across air interface

Initialise Counter

!Counter<Max Attempts

Drop Packet

!ChannelAlloc’d

Increment

counter

Req code from BS,

start timer

!Channel Alloc’d

|| Request timed out

Counter<Max Attempts

!Counter<Max Attempts

Drop Packet

Channel Alloc’dTx Pkt using

alloc’d code

ChannelAlloc’d

Req code from BS,

start timer

!Channel Alloc’d

|| Request timed out

Counter<Max Attempts

Channel Alloc’dTx Pkt using

alloc’d code

ChannelAlloc’d

13

Dealloc DL code to

MS, send last pkt

Empty DL Q for this MS DL pkt for

this MS

Timeout

Start Timer

FoundUL code

Send MS code alloc’d

msg on cc

UL codereq msg

Search for free UL code

from MS

!Found

UL code

Send MS code not alloc’d

msg on cc

from MS

!Found

UL code

Send MS code not alloc’d

msg on cc

Found UL code

Send MS code alloc’d

msg on cc

UL codereq msg

Search for free UL code

UL IP Pkt

Decaps & send pkt

through IP to dest

Base Station, BSBase Station, BS

• Receive an uplinkcode request from aMS

• Receive an uplinkIP packet

• Receive an uplinkcode de-allocaterequest

• Receive a downlinkIP packet for a MScurrently in theBS’s cell.

Dealloc UL code,

send delloc msg to MS

UL dealloc req msg from MS

UL IP Pkt

Decaps & send pkt

through IP to dest

DL code alloc’d

Found free DL code

Q DL pkts

Send code to

MS on cc Encaps & send pkt

at head of Q

Q DL pkts

!DL code alloc’d Q DL pkts

!Found a free DL code

Q DL pkts || !Found a free DL code

Search for free

code

Channel alloc alg

DL IP pkt to send to MS

Q DL pkts Search for

alloc’d code Dealloc

UL code, send delloc msg to MS

UL dealloc req msg from MS

Empty DL Q for this MS DL pkt for

this MS

Timeout Dealloc DL code to

MS, send last pkt

Start Timer

Found free DL code

Q DL pkts

!Found a free DL code

Q DL pkts Channel

alloc alg

Send code to

MS on cc

DL code alloc’d

Q DLpkts

Encaps & send pkt

at head of Q !DL code

alloc’d

Q DL pkts || !Found a free DL code

Search for free

code

DL IP pkt to send to MS

Q DL pktsSearch for

alloc’d code

WaitInitialise

14

Simulation ParametersSimulation Parameters

� Each mobile is allowed to hold onto a code for a specific time, when it has no packetsto send in the uplink and downlink. 1hour simulation time:� 105 MSs comprising of: 31 mobile telephones; 33 handheld terminals and 41 laptop

computers.� maximum code request attempts was set to ∞ then to 5.

� Application profile:� Voice: active (0.35) and silent (0.65) parts, exponentially distributed, two state Markov

model. UDP/IP protocols due to the long delays caused by lost TCP packets, ToS=6.� Email: transmitted every 180s to 3 receivers and received every 60s with an exponential

distribution. Each e-mail is 1000 bytes & ToS=0.� FTP: 0.5 command mix every 60s, exponential distribution, file is 5000 bytes, ToS=0.� HTTP: A 500byte page with a 10-400byte picture arrives every 720s (exponential) for

light apps, & a 1000byte page with a 500-2000byte picture arrives every 120s for heavyuse.

� Database: 0.5 command mix (entry/query), 16bytes arrive every 30s (exponential) for lightapp & 32,768bytes every 12s for heavy.

= voice = light email/database & heavy HTTP

= heavy email/FTP/ database/HTTP & light FTP

15

mobile phone holds onto scramble code 17for 1.5mins and latercode 1 for more than

0.5mins, this isbecause the hold timeis set for 0.1s this was

found to be the optimalsetting for this

network, due to thedistinct on-off periods.

Allocated CodesAllocated Codes

other applicationsdo not

control channel = 0

7

10

1

17

0

2

4

6

8

10

12

14

16

18

20

20 22 24 26 28 30

Time (min)

Tx S

cram

ble

Cod

e

Laptop Handheld Cellphone

Zero hold times for other applications, code must be obtained every time a packet istransmitted, (uplink & downlink) as these patterns are more sporadic.

16

WCDMA Code Request/De-allocate Statistics (105 MSs)

7.97

2.27

6.84

1.15

4.63

1.24

4.24

0.85

0

2

4

6

8

Requests Request Timeouts De-allocationAttempts

De-allocationTimeouts

Req

uest

s/De-

allo

cate

(att

emps

/sec)

Code StatisticsCode Statistics

� Code request timeouts:28.54% ∞, 26.78% 5 =improvement of 1.76%.

� De-allocate requeststimeout: 16.85% ∞,20.11% 5 = reduction of3%

� No code request failures,timeouts occur becausethere is congestion onthe control channel =drop of approximately40% traffic on thecontrol channel.

Infinite Attempts 5 Attempts

17

Code StatisticsCode StatisticsWCDMA mean number of codes used (105 MSs)

4.81

13.19

3.45

1.15

0

2

4

6

8

10

12

14

Downlink Codes Uplink Codes

Mea

n C

odes

Use

d

Infinite Attempts 5 Attempts

� There are less codesbeing used in the systemwith 5 attempts, 28%less downlink and 93%less uplink codes, thismeans that there is muchless interference in the 5attempts network for thesame amount of userstrying to transmit thesame amount of data.

18

Packet Latency & Transmitted TrafficPacket Latency & Transmitted Traffic

Mean packet latency

0.17

0.03

8.15 9.43

1.51 1.37

38.0363.93

0.34

28.05

0.01

0.1

1

10

100

Infinite Attempts 5 Attempts

Number of Code Request Attempts

Pack

et L

aten

cy (s

ec)

Voice Email FTP HTTP Database

� Voice shortest: 0.17s ∞,0.03s 5 = improvementof 84% drop in meanpacket latency.

� Email and HTTPimproved most 8.15-0.34s and 28.05-1.37srespectively, =improvement of 95%

19

Packet Latency & Transmitted TrafficPacket Latency & Transmitted Traffic

Mean Transmitted Traffic

5793 5161

1265

27 22

3440

722632

1535783

1

10

100

1,000

10,000

Infinite Attempts 5 Attempts

Number of Code Request Attempts

Tra

nsm

itted

Tra

ffic

(byt

es/se

c)

Voice Email FTP HTTP Database

� Most voice traffic inboth cases. Voice trafficdropped from 5,793-5,161bytes/s which is areduction of 10%attempts from ∞ to 5.

� There is more databasetraffic transmitted in thesecond network, withaverage values from632-1,535 bytes/s whichis an increase of 43%.

20

Dropped StatisticsDropped StatisticsWCDMA Packet Loss Ratio (105 MSs)

0.1006

0.3425

0.1008

0.7742

0

0.2

0.4

0.6

0.8

Mean Peak

Mea

n pa

cket

loss

rat

io

Infinite Attempts 5 Attempts

� The mean packet lossratios are very similar, 5attempts being 0.19%more than ∞ attempts :due to dropping, radiointerference and queueoverflow.

� However, the peakvalues show that 26%more traffic is droppedwithin the 5 attemptsnetwork.

21

Dropped StatisticsDropped Statistics

Traffic not Receveived by Applications (105 MSs)

315.20

2.78

237.99

6,756.06

775.22

5334.87

2.341.94

786.60

148.61

1

10

100

1,000

10,000

Voice Email FTP HTTP Database

Tra

ffic

(byt

es/s

ec)

Infinite Attempts 5 Attempts

� The amount of trafficdropped or lost on the radiolink falls from 8,087-6,274bytes/s = decrease of22.42%.

� Voice, only a 1.46%increase

� All other apps trafficdropped is reduced, HTTP,237.99-2.34 bytes/s = 99%reduction

� The most dropped trafficwas database and least wasFTP in both cases

22

Traffic Mix & DroppedTraffic Mix & Dropped

Voice Email FTP HTTP Database

51.92%

11.34%

0.24%

30.84%

5.66%Traffic Mix(∞∞∞∞Attempts)

62.76%

9.52%

0.27%8.78%

18.67%Traffic Mix(5 Attempts)

9.59% 3.90%0.03%2.94%

83.54%

Traffic Dropped(∞∞∞∞Attempts)

12.54% 2.37%0.03%0.04%

85.03%

Traffic Dropped(5 Attempts)

The traffic mixthat is transmittedis not the same as

that, that isdropped. More

database traffic isdropped than any

other.

23

ConclusionsConclusions

� By introducing resource management strategy: voice packets givenpriority, resulting in lower latencies than other applications.

� By introducing Channel Allocation Algorithm: increased cell capacity,by reduction control channel traffic by 40%, thus reducing latencies.� Voice: 84% latency reduction & 10% less transmitted traffic �� Email: 95% latency reduction & 38% less transmitted traffic� HTTP: 95% latency reduction & 38% less transmitted traffic

� Find out optimum no. of attempts for different applications dependingon QoS required.

� Similar mean values of packet loss ratios for ∞∞∞∞ and 5 attempts, using lessresources.