institutionen för systemteknik - diva portal18557/fulltext01.pdfinstitutionen för systemteknik 581...

Institutionen för systemteknikDepartment of Electrical Engineering

Master thesis

Design and implementation of a test tool for the GSM traffic channel

Theo Öjerteg

ISY-LITH-EX-3169-20022002-06-04

TEKNISKA HÖGSKOLANLINKÖPINGS UNIVERSITET

Department of Electrical engineering Linköpings tekniska högskolaLinköping University Linköpings UniversitetS-581 83 Linköping 581 83 Linköping

Design and implementation of a test tool for the GSM traffic channel

Examensarbete utfört i datatransmissionvid Linköpings Tekniska Högskola av

Theo Öjerteg

Reg nr:LiTH-ISY-EX-3169-2002

Handledare: Michael Lundkvist, Danjel McGougan, Enea EpactExaminator: Ulf Henriksson, ISY

Linköping 2002-06-04

Avdelning, InstitutionDivision, Department

Institutionen för Systemteknik581 83 LINKÖPING

DatumDate2002-06-04

SpråkLanguage

RapporttypReport category

ISBN

Svenska/SwedishX Engelska/English

LicentiatavhandlingX Examensarbete

ISRN LITH-ISY-EX-3169-2002

C-uppsats D-uppsats

Serietitel och serienummerTitle of series, numbering

ISSN

Övrig rapport _____

URL för elektronisk versionhttp://www.ep.liu.se/exjobb/isy/2002/3169/

TitelTitle

Design och implementation av ett testverktyg för GSM talkanal. Design and implementation of a test tool for the GSM traffic channel.

FörfattareAuthor

Theo Öjerteg

SammanfattningAbstractTodays’ systems for telecommunication are getting more and more complex. Automatic testing is required to guarantee quality of the systems produced. An actual example is the introduction of GPRS traffic in the GSM network nodes. This thesis investigates the need and demands for such an automatic testing of the traffic channels in the GSM system. A solution intended to be a part of the Ericsson TSS is proposed. One problem to be solved is that today’s tools for testing do not support testing of speech channels with the speech transcoder unit installed. As part of the investigation, a speech codec is implemented for execution on current hardware used in the test platform. The selected speech codec is the enhanced full rate codec, generating a bitstream of 12.2 kbit/s, and gives a good trade-off between compression and speech quality. The report covers the design of the test tool and the implementation of speech codec. Particularly performance problems in the imple-mentation of the encoder will be addressed.

NyckelordKeywordGSM, speech codec, traffic generation, test tool, test automation, DSP, telecommunication, TSS, encoder, decoder

Contents

CHAPTER 1 Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

CHAPTER 2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 Background . . . . . . . . . . . . . . . . . . . . . . . 32.2 Assignment . . . . . . . . . . . . . . . . . . . . . . . 42.3 Limitations . . . . . . . . . . . . . . . . . . . . . . . . 52.4 Purpose of this report . . . . . . . . . . . . . . . 52.5 Reading instructions . . . . . . . . . . . . . . . . 5

CHAPTER 3 GSM basics. . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.1 Telecommunication overview . . . . . . . . . 73.2 Networking elements. . . . . . . . . . . . . . . . 73.3 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . 93.4 Inside the equipment. . . . . . . . . . . . . . . 10

CHAPTER 4 Speech coding . . . . . . . . . . . . . . . . . . . . . . . . 13

4.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . 134.2 Human speech model . . . . . . . . . . . . . . 134.3 Different codecs. . . . . . . . . . . . . . . . . . . 154.4 Enhanced full rate codec . . . . . . . . . . . 164.5 Speech encoding . . . . . . . . . . . . . . . . . . 194.6 Speech decoding . . . . . . . . . . . . . . . . . . 22

Design and implementation of a test tool for the GSM traffic channel vii

4.7 Discontinuous Transmission Mode . . . 234.8 Voice Activity Detection . . . . . . . . . . . . 244.9 Substitution and muting . . . . . . . . . . . . 264.10Comfort Noise . . . . . . . . . . . . . . . . . . . . 264.11Homing . . . . . . . . . . . . . . . . . . . . . . . . . . 274.12Transmission parameters . . . . . . . . . . . 27

CHAPTER 5 Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.1 TSS overview . . . . . . . . . . . . . . . . . . . . . 295.1.1 Overview . . . . . . . . . . . . . . . . . . . . 295.1.2 TSS architecture . . . . . . . . . . . . . . 29

5.2 Problems. . . . . . . . . . . . . . . . . . . . . . . . . 305.3 Use cases . . . . . . . . . . . . . . . . . . . . . . . . 31

5.3.1 Use case 1. . . . . . . . . . . . . . . . . . . 325.3.2 Use case 2. . . . . . . . . . . . . . . . . . . 325.3.3 Use case 3. . . . . . . . . . . . . . . . . . . 335.3.4 Use case 4. . . . . . . . . . . . . . . . . . . 335.3.5 Use case 5. . . . . . . . . . . . . . . . . . . 345.3.6 Use case 6. . . . . . . . . . . . . . . . . . . 345.3.7 Use case 7. . . . . . . . . . . . . . . . . . . 355.3.8 Use case 8. . . . . . . . . . . . . . . . . . . 35

5.4 Requirements . . . . . . . . . . . . . . . . . . . . . 36

CHAPTER 6 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.1 Proposed solution . . . . . . . . . . . . . . . . . 396.2 Functional overview . . . . . . . . . . . . . . . 40

6.2.1 PCM Frame adaption. . . . . . . . . . . 406.2.2 TRAU/TRAB Frame adaption. . . . . 416.2.3 Speech codecs . . . . . . . . . . . . . . . 416.2.4 PCM conversion. . . . . . . . . . . . . . . 426.2.5 Traffic generator . . . . . . . . . . . . . . . 426.2.6 Statistics . . . . . . . . . . . . . . . . . . . . 436.2.7 User interface . . . . . . . . . . . . . . . . 44

6.3 Communication interfaces . . . . . . . . . . 466.3.1 A interface . . . . . . . . . . . . . . . . . . . 466.3.2 Abis interface . . . . . . . . . . . . . . . . . 46

viii Design and implementation of a test tool for the GSM traffic channel

6.3.3 TSS Interface . . . . . . . . . . . . . . . . . 476.3.4 Signal interface. . . . . . . . . . . . . . . . 47

6.4 Software implementation. . . . . . . . . . . . 486.4.1 External traffic generator . . . . . . . . 496.4.2 Driver modules . . . . . . . . . . . . . . . . 496.4.3 Proxy module . . . . . . . . . . . . . . . . . 496.4.4 Traffic generator links . . . . . . . . . . . 506.4.5 Traffic generators . . . . . . . . . . . . . . 516.4.6 Traffic generator manager . . . . . . . 516.4.7 PCI Interface. . . . . . . . . . . . . . . . . . 526.4.8 ESSI Interface . . . . . . . . . . . . . . . . 526.4.9 Codecs and frame adapters . . . . . . 52

CHAPTER 7 Implementation and Test . . . . . . . . . . . . . . . . . 53

7.1 Implementation of test tool . . . . . . . . . . 537.2 Implementation of speech codec . . . . . 54

7.2.1 Multichannel mode . . . . . . . . . . . . . 547.2.2 DSP implementation. . . . . . . . . . . . 54

7.3 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557.4 Problems . . . . . . . . . . . . . . . . . . . . . . . . . 55

7.4.1 Performance of generated code . . . 557.4.2 Size of generated code. . . . . . . . . . 577.4.3 Word length . . . . . . . . . . . . . . . . . . 587.4.4 Performance of individual routines . 58

7.5 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 607.5.1 Multichannel mode . . . . . . . . . . . . . 607.5.2 DSP implementation. . . . . . . . . . . . 60

7.6 Improvements . . . . . . . . . . . . . . . . . . . . . 61

CHAPTER 8 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

8.1 Need of system . . . . . . . . . . . . . . . . . . . . 638.2 Implementation so far . . . . . . . . . . . . . . 638.3 Alternative solutions . . . . . . . . . . . . . . . 64

Design and implementation of a test tool for the GSM traffic channel ix

APPENDIX A Generated code examples . . . . . . . . . . . . . . . 65

APPENDIX B Original C-code . . . . . . . . . . . . . . . . . . . . . . . . 69

References . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

x Design and implementation of a test tool for the GSM traffic channel

CHAPTER 1 Preface

Thanks to all people at Enea Epact and Ericsson who have been answering my questions and helping with whatever problem I’ve had.

Also a lot of thanks to my wife who has been very support-ive when I really wanted to throw the computer out of the window.

Linköping 2002-06-04

Theo Öjerteg

Design and implementation of a test tool for the GSM traffic channel 1

2 Design and implementation of a test tool for the GSM traffic channel

CHAPTER 2 Introduction

2.1 Background

This master thesis work was done as part of the programme for Computer Science and Engineering at Linköping Uni-versity.

The employer was Enea Epact, but the real customer was Ericsson Radio Network Center.

With the introduction of GPRS in the GSM network, the need for verification of the traffic channels increase. For example, a useful scenario for this new tool would be when there are a lot of GPRS traffic going on through the BSC, then a voice call is being set up and GPRS traffic channels has to be pre-empted. It would also be interesting to use the system for generating background load on the traffic chan-nels, while performing other automatic tests.

The thesis consists of two parts. The first part consists of an analysis to find out the needs and to see how it is possible to implement the system. The second part involves implement-ing part of the system.


Assignment

2.2 Assignment

The customer has a product called Test and Simulation Solutions (TSS), used for testing nodes in the Global Sys-tem for Mobile Communications (GSM) and General Packet Radio Systems (GPRS). The TSS consists of special hard-ware as well as software and is used to simulate traffic in mobile cell phone networks.

Within TSS there is a problem when it comes to circuit switched networks like the GSM. The test tool is only able to set up the connections using the signalling channels, the physical channels used for traffic are not verified with this tool. When it comes to packet switched networks, like the GPRS, this problem has been handled.

The first assignment was to see how the product TSS could be enhanced with a new tool allowing for verification of the GSM traffic channels. This includes how to insert traffic (i.e. simulated speech) into the physical channel, how to generate it, and how to control the tool in a way that is con-sistent with the rest of the product. To do this, several sub-areas have to be studied. The GSM network itself has to be studied in order to find out scenarios where this new tool can become useful. What standards are there that the new tool must comply to in order to connect to the GSM net-work? And what about the user interface part, what are the common standard the tool must comply to in order to be eas-ily integrated with the TSS?

The second assignment for this master thesis was to imple-ment part of the system proposed. In this case the choosen part is the enhanced full rate speech codec, which is the most commonly used codec of cellular phone systems. This part will involve examining the speech compression and decompression algorithms to be able to implement them on the target hardware.


Limitations

2.3 Limitations

Only the speech encoding and decoding functions will be implemented since this is an area where there is not enough knowledge at the employer or the customer. This is basically one function which can be developed detached from the rest of the test system and easily integrated later.

The full test system, with traffic generator, user interface etc., will not be implemented within this master thesis due to limitations in time. Also this area is more well known and the both the employer and the customer has a lot of experi-ence in this area.

2.4 Purpose of this report

The purpose of this report is to summarize the work per-formed and to document the results achieved. The situation before is described as well as the gains from implementing and using the proposed test system.

2.5 Reading instructions

The report is intended to be readable by most senior students at a Master of Science programme and teachers at those pro-grammes. However it will also include details about the sys-tem useful for professionals working in the area of telecommunication using or further developing the system. Professionals implementing the system should consider reading [1] and [2].

Chapter 2 gives a brief introduction to the report and defines the assignment.

Chapter 3 deals with the theory behind the GSM network and is useful for those not working within the telecommuni-cation area.


Reading instructions

Chapter 4 gives an introduction to the theory behind speech coding and the parts of a full featured speech coder.

Chapter 5 gives a deeper analysis of the need and usage of a test tool.

Chapter 6 describes the design to be used for the proposed system.

Chapter 7 discusses issues concerning test and implementa-tion. Problems, improvements and errors are discussed.

Chapter 8 summarizes the thesis and discusses drawn con-clusions.


CHAPTER 3 GSM basics

3.1 Telecommunication overview

The following sections will introduce terminology from the area of mobile telecommunication. The intention is to give an overview and to define the concepts of mobile telecom-munication and its notion. Details can be found in [3] and [4].

3.2 Networking elements

The GSM network consists of a hierarchy of elements as can be seen in figure 3.1. In this particular network there are two Mobile Switching Centres (MSC), one Gateway MSC (GMSC) and three different access networks. There are also some databases to store the information needed in the net-work. This public land mobile network (PLMN) is also con-nected to the public switched telephone network (PSTN) and one other PLMN.

The mobile station (MS) can be any type of end user equip-ment like a cellular phone, laptop or fax machine with radio modem.


Networking elements

FIGURE 3.1. GSM network hierarchy.

The Base Transceiver Station (BTS) contains equipment for the physical radio transmitting and receiving, signal meas-urements, encryption and communication with the base sta-tion controller (BSC).

Base station controllers serve as concentrator nodes for sev-eral BTS. It is responsible for allocating radio channels used by the BTS and to connect speech and signalling channels to the MSC. It also handles transfers, handovers, of mobile sta-tions between different BTS. This occurs for example, when the mobile station is being moved within a limited area, for example in a city.

The mobile switching centre corresponds to the local station in a public switched telephone network, though it does not have any hard wired subscribers. It is responsible for mov-

G M S CPS T N

O therP L M N

A U C E IR

H L R

V L R V L R

B S C

M S C M SC

B T S

B T S

B T S M S

A

A b is

U m


Interfaces

ing mobile stations between different BTS and between dif-ferent MSC. Transfer of mobile stations between BTS occurs for example when the end user is travelling longer distances.

The GMSC is similar to the MSC. It serves as an interface between the network and other networks, for example the PSTN or other PLMN. It is responsible for charging between different network operators. There may be several GMSC in a network, and they may be integrated with the MSC.

There are also databases connected to the switching network elements. The home location register (HLR) contains infor-mation about the end user and under which MSC it currently is registered. At each MSC there is a visitor location register (VLR) which contains information about all mobile stations that are currently in that MSC service area.

Authentication centre (AUC) contains information used for encryption and authorization.

Equipment identity register (EIR) stores information about the MS identity. It is used to control that a mobile station is not blocked.

3.3 Interfaces

The different interfaces between the network elements are named in figure 3.1. Starting from the MS side, first comes the Um interface. This is the radio interface between a mobile station and the BTS [5]. Each logical speech channel requires 16 kbit/s data rate. With error correction codes, burst management and encryption the used data rate is 33.8 kbit/s per channel.

The interface between the BTS and the BSC is named Abis. It uses standard T1 or E1 cables for interconnection. Four 16


Inside the equipment

kbit/s speech channels multiplexed into one 64 kbit/s chan-nel corresponds to one timeslot in the E1 or T1 link between the BTS and BSC. The job to transform the speech informa-tion to the correct format is done by the transcoding and rate adaption unit (TRAU). This is where the speech encoding and decoding functionality are situated. The Abis interface is defined in [6].

The A interface between BSC and MSC consists of 64 kbit/s PCM links on a E1 or T1 interconnection. The speech is here coded with a-law or µ-law PCM depending on if a European or American/Pacific system is used. More infor-mation about the A interface is found in [7].

3.4 Inside the equipment

The basic structure inside the switching network elements is shown in figure 3.2. The main components in the BSC, and MSC are a number of line interfaces (LIF), i.e. the physical connections to the other elements, a switching unit and a control system. There is also some kind of terminal equip-ment (TERM) for operation and maintenance.

Inside the BSC there is also a pool of cpu resources for speech transcoding and rate adaption in the TRAU module, available for use when connecting traffic channels between the MSC and BSC.

The BTS consists of a number of transceivers (TRX), which are multiplexed into the radio interface. The transceivers are accessed from the BSC via a transceiver radio interface switching traffic channels from the BSC to the correct trans-ceiver and vice versa.



FIGURE 3.2. Inside the switching elements.

TR X

TR I

C O N TR O L

TR X

LIF

LIF

TE RM

TR A U

C O N TR O L

MUX

LIF

LIF

TE RM

C O N TR O L

B SC

G M SC /M SC

BT S

O ther netw orks


CHAPTER 4 Speech coding

4.1 General

A general communication system can be split into a couple of modules, as in figure 4.1. The transmitter is modelled by a source encoder, channel encoder and modulator. The receiver can be modelled by a demodulator, channel decoder and source decoder as seen in . Between the source and des-tination side, there is the transmission media, called a chan-nel. Since most channels not are perfect, the channels will add some noise to the signal.

The following sections will concentrate on the features of the source encoder and decoder.

4.2 Human speech model

Since we are interested in compression of human speech , it is interesting to study how speech is produced.

Sounds are produced in two different ways. There are voiced sounds, all vowels for example, that are produced by the vibrating vocal cords at the glottis. There are also unvoiced sounds, like ‘p’, ‘t’, and ‘f’, which are the result of


Human speech model

FIGURE 4.1. General communication system.

air flow through a construction in the vocal tract. Note that consonants can also be voiced sounds like ‘b’, ‘d’ and ‘j’. Also some sounds are the result of a combination of these.

The excitation signal for these sounds is the vibration of the vocal cords. The frequency of the vibration does not vary greatly in time due to the physiology of the glottis, and can therefore be modelled using a slowly varying model.

The vocal tract is a mechanical system, which means that the vocal gestures are relatively slow. It can be modelled by a parametric filter, where the parameters will vary with time. The bandwidth for these filter parameters are lower than for the speech signal itself. This is called the short time station-arity of the vocal tract filter.

The human ear is also to be considered in the models. It is able to perceive signals between 20 Hz - 20 kHz. However, it is most responsive to frequencies between 200 and 5600 Hz which usually carries the most important information when it comes to human speech. Most telephone systems has a bandwidth limitation to the range of 300 to 3400 Hz, which will be possible without losing to much of the quality.

Another important aspect is masking, which means that one sound can be obscured by the presence of another. Masking

Informationsource

Sourceencoder

Channelencoder Modulator

Channel

DemodulatorChanneldecoder

Sourcedecoder

Informationdestination

Noise


Different codecs

can be done either as temporal masking or as frequency or spectral masking. Temporal masking means that signals with energy in frequencies close to each other can mask each other, if the time delay between the signals are short. Frequency masking means that a lower frequency can be masked by a simultaneous higher frequency. This can be used to distribute quantization noise to the masked fre-quency.

4.3 Different codecs

There are different types of speech codecs. The two main types of coders are waveform coders and vocoders (voice coders). There are also hybrid coders which combine the properties of those coders. Some properties of these codecs are shown in figure 4.2.

FIGURE 4.2. Comparison of compression ratio and speech quality of different codec categories.

Waveform coding is the process of describing the signal’s amplitude curve with a number of discrete values. This is basically done in three steps - sampling, quantization and coding. The quality of the signal will in general be very good but requires more bandwidth. Waveform coders tend to be more robust against unexpected input, like music, than vocoders.

Low

Excellent

G ood

Average

Hybrid codersW avefo rm coders

Vocoders

Speech quality

b itrate(kb it/s)2 4 8 16 32 64


Enhanced full rate codec

Vocoders use a totally different approach. They try to figure out which parameters were used to create the signal, given that it passed through a known filter model. The filter model in mind is of course a model of the human speech organs. Vocoders lose a bit of quality of the transferred signal, but will on the other hand use less bandwidth. The process of transmitting speech parameters instead of the speech can be compared to transmitting notes instead of the music itself.

Because of the two contradictionary demands of low band-width usage and high signal quality in cellular phone sys-tems, hybrid coders are used. The coders use a combination of parameterizing and waveform coding to achieve this. The bitrate can be reduced to levels under the 64 kbit/s PCM coding with good signal quality.

There are several possible speech coders for usage in cellu-lar phone systems (See also [8]):

• Full rate 13 kbit/s

• Enhanced full rate 12.2 kbit/s

• Half rate 5.60 kbit/s

• Adaptive multi rate 4.75-12.2 kbit/s

Next section will give a further study of the enhanced full rate (EFR) coder.

4.4 Enhanced full rate codec

The enhanced full rate codec is an Algebraic Code Excited Linear Prediction (ACELP) system. A simple description of the synthesis model can be found in figure 4.3.



FIGURE 4.3. CELP synthesis model

The excitation signal is constructed by adding the excitation vectors from an adaptive and a fixed codebook. The result is then filtered through the short-term synthesis filter to recon-struct the speech. To get the code book vectors, analysis-by-synthesis is used, in a procedure where the error between original speech and reconstructed speech is minimized.

The error minimization is done by filtering the error signal through a weighted perception filter, which masks the error by weighting it less in regions near the vocal tract reso-nances and more in regions away from them.

The codec encodes/decodes 20 ms frames of speech consist-ing of 260 samples at 8000 Hz. The samples are encoded with 13 bit uniform PCM. Encoded speech are delivered in 50 frames/s with 244 bits in each frame.

Other features than compression are often used in conjunc-tion with the speech codecs [9]. Techniques for comfort noise generation, voice activity detection (VAD) and discon-tinuous transmission (DTX) are integrated into the same unit, figure 4.4. The different parameters sent between the blocks of the codec are explained below.

1. Uncompressed speech samples.

2. The voice activity detector checks if the input signal con-tains speech.

3. Encoded speech parameters.

A dap tiv e co deb oo k

F ixedco deb oo k

L P sy n th esis P ost fil te rin g+



4. Background noise is evaluated and a silence descriptor (SID) frame is calculated. This frame is passed between the comfort noise module and the DTX handler.

5. Speech flag, indicates whether information bits are speech or silence descriptor information.

6. Speech information bits transferred over radio system.

7. A flag is set if a corrupt frame has been received.

8. The DTX handler gets to know whether the delivered frame is a SID frame or not.

9. The substitution module is notified if a frame is corrupt or lost.

Also there are parts not shown in the figure 4.4, responsible for AD/DA conversion on the MS side and conversion between a-law/µ-law PCM used in transmission media on the base station side and linear PCM used as input and out-put to the speech codec.

FIGURE 4.4. Parts of the EFR speech codec.

For a more detailed description of the mathematics behind the enhanced full rate codec the interested could have a look in [10]. Also check [11] for voice activity detection, [12] for discontinuous transmission and [13] for comfort noise gen-eration.

V oiceac tiv ityde tec to r

S peechen cod er

C o m fortno ice T Xfu n ctio ns

D T XC o ntrol

an d op era tio n

T ran sm it side R ece iv e sid e

D T XC on tro l

an d o p eratio n

S p eech fram e

su bsti tu tio n

Sp eechd eco d er

C om fo rt no ise R Xfu nction s

1

2

3

4

3

4

15

6

6

7

8

9

3

3

1

1


Speech encoding

4.5 Speech encoding

The encoding process is described visually in figure 4.5. The first step is to filter some unwanted low frequency com-ponents from the input signal.

The Linear Prediction (LP) coefficients are calculated twice per frame. The reason is to remove redundancy from the speech signal. The sampled speech signal is not stationary and therefore the predictor coefficients must be adapted to the changing statistics of the signal. This is done by consid-ering the signal stationary for a short time interval, called a frame of the speech signal. When using the enhanced full rate codec the frame length is 20 ms, but linear prediction calculations are done twice per frame, i.e. on a 10 ms basis. By minimizing the mean squared error of the error signal, an expression for the linear prediction coefficients in the form of p linear equations with p unknowns can be found. This system is then solved by using the Levinson-Durbin algo-rithm.

The LP coefficients are then to be quantizised before trans-mission. To further reduce the transmitted number of bits, the parameters are interpolated between the subframes.

Quantization and interpolation of linear prediction coeffi-cients is hard to do, because even small changes in the parameters may cause big changes in the power spectrum and possibly in an unstable synthesis filter. Therefore the parameters are transformed into Line Spectral Pairs (LSP) or Line Spectral Frequencies (LSF).

LSF are calculated only for the second and fourth 5 ms sub frame of a full 20 ms frame of speech, and interpolation is used to get the LSF parameters for the first and third sub-frame.


Speech encoding

To simplify the adaptive code book search, a sub-optimal lag is calculated directly from the weighted speech input. This will confine the closed-loop pitch search to a small number of values around the estimated lag value.

The following steps are then performed for every sub frame:

• First the target signal for the adaptive codebook search is calculated. This is done by subtracting the zero input response of the weighted synthesis filter from the weighted speech signal. The zero input response is the output of the filter due to past input, i.e. with a current input of zero.

• The impulse response of the weighted synthesis filter is calculated.

• The target signal and the impulse response of the weighted synthesis filter are then used to search around the open-loop pitch lag for the optimal pitch lag and gain.

• The adaptive codebook contribution to the target signal is calculated and removed from the target signal giving the target signal for the innovative codebook search.

• Finally filter memories are updated for use in the next subframe.


Speech encoding

FIGURE 4.5. Encoder.

fram

esu

bfra

me

Pre

-pro

cess

ing

LP

C a

naly

sis

(tw

ice

per

fram

e)O

pen-

loop

pit

ch s

earc

h(t

wic

e pe

r fr

ame)

Ada

ptiv

e co

debo

okse

arch

Inno

vati

ve c

odeb

ook

sear

chF

ilte

r m

emor

yup

date

Pre

-pro

cess

ing

win

dow

ing

and

auto

corr

elat

ion

R[]

Lev

inso

n-D

urbi

nR

[]->

A(z

)

A(z

) ->

LS

P

LS

Pqu

anti

zati

onL

SP

indi

ces

inte

rpol

atio

nfo

r th

e 4

subf

ram

esL

SP

-> Â

(z)

inte

rpol

atio

nfo

r th

e 4

subf

ram

esL

SP

-> A

(z)

s(n) A

(z)

com

pute

w

eigh

ted

spee

c(4

sub

fram

es)

find

open

-loo

p pi

tch

A(z

)

Â(z

)

h(n)

To

x(n)

x(n)

A(z

)

Â(z

)

h(n)

com

pute

tar

get

for

adap

tive

code

book

find

bes

t del

ayan

d ga

in

quan

tize

LT

P_g

ain

com

pute

ad

apti

veco

debo

okco

ntri

buti

on

com

pute

targ

et

for

inov

atio

n

code

inde

x

LT

Pga

in

inde

x

upda

te f

ilte

rm

emor

ies

for

next

sub

fram

e

fixe

dco

debo

okga

inqu

anti

zati

on

fixe

d co

debo

okga

in i

ndex

pitc

hin

dex

x 2(n

)

com

pute

impu

lse

resp

onse

find

bes

tin

nova

tion

com

pute

exit

atio

n


Speech decoding

4.6 Speech decoding

The decoder part, figure 4.6, is simpler than the encoding part.

For every frame the transmitted LSP indices are used to decode the LSP coefficients. These coefficients are interpo-lated to get coefficients for all four subframes. Finally the LSP coefficients are transformed back to the LP filter coeffi-cient domain to be used in the synthesizing filter recon-structing the speech.

The next five steps are performed for every subframe:

• The adaptive codebook vector is decoded.

• The adaptive codebook gain is decoded by using the received index to find the gain from the quantization table.

• The innovative codebook vector is decoded by using the received index to extract positions and amplitudes of the excitation pulses and find the algebraic code vector.

• The fixed codebook gain is decoded from the received index.

• Finally the speech is reconstructed by filtering of the excitation vectors through the synthesis filter.

The reconstructed speech signal has to be filtered through an adaptive postfilter and up-scaled before it is totally decoded.


Discontinuous Transmission Mode

FIGURE 4.6. Decoder.

4.7 Discontinuous Transmission Mode

To minimize interference in the air interface and to save power in the mobile station the radio transmitter in the mobile station can be turned off during pauses in speech. The technique is called discontinuous transmission mode [12]. During a normal phone conversation, the participants alternate so that, on the average, each direction of transmis-sion is occupied about 50% of the time.

For the DTX handler the following functions are needed:

• Voice activity detector on transmit side

• Evaluation of background noise on transmit side.

• Comfort noise generation on receive side.

The control of the DTX handler is indirectly done from the voice activity detector decision, see figure 4.4. The result from the voice activity detector is used to decide whether

fram e su b fram e

L S Pind ices

decod e L SP

interpo la tio nof L S P for th e

4 sub fram es

L S P -> Â (z )

p itchind ex

g ainsin dices

co d ein d ex

deco dead aptiv e

co deb oo k

deco dein no v ativeco deb oo k

d eco d eg a in s

co n struc texc itat io n p ost fil te r

po st-p ro cessing

syn th esisf ilte r

s n( ) s'ˆ n( )


Voice Activity Detection

the frame is to be passed to the transmitting radio subsystem or not. This has the effect that when the speaker stops talk-ing, the transmission is cut off. During the speech pause, transmission is resumed at regular intervals to send an updated silence descriptor frame, in order to make the lis-tener perceive the presence of background noise.

On the receiver side, the DTX handler receives frames from the radio subsystem:

• Good speech frames are passed directly to the speech decoder.

• Valid SID frames are used for comfort noise generation, see 4.10.

• Bad or lost frames are replaced by a substitution and muting procedure described in 4.9.

4.8 Voice Activity Detection

Voice activity detection [11] is used together with the dis-continuous transmission mode. The purpose is to provide a flag indicating whether a frame contains speech or not. The algorithm does this by comparing the energy of the input signal to a threshold value.

Mobile environments are often subject to a lot of back-ground noise, making the noise/speech ratio low. The speech signal is filtered to improve the noise/speech ratio, and the energy is calculated. For each frame the threshold value is adapted, taking into concern:

• Presence of information tones. DTMF tones should not be filtered out, while strong resonances from vehicles for example should be classified as noise.

• Periodic component in input signal. If the input signal contains stationary noise the threshold should be raised, however vowels also produce a stationary frequency


Voice Activity Detection

spectrum. This is detected by comparing adjacent long term predictor values.

• Stationary input signal. Spectral characteristics of the input signal is obtained from several frames to detect sta-tionary frequencies that can be removed in the adaptive filtering of the input signal.

The energy of the input signal is then compared to the threshold to get a boolean VAD decision. The final decision includes a hangover period to make sure enough frames are sent to be able to calculate useable SID frames.

The outline of the algorithm is described in figure 4.7. As can be seen the algorithm uses values from the encoder part as its input to minimize the computation needs.

FIGURE 4.7. Schematic overview of voice activity detection algorithm.

VADdecision

VADhangover

Periodicitydetection

Tonedetection

Predictorvalues

computation

Autocorrelationaveraging

Spectralcomparison

Thresholdadaption

Adapt. filteringand energy

computation

Autocorrelation

Lag values

Reflection

VAD flag

coefficients

vector


Substitution and muting

4.9 Substitution and muting

Substitution and muting is performed as a result of lost or invalid frames received by the radio subsystem [14]. Muting is performed to avoid generating annoying sounds as a result from the frame substitution.

Normal decoding of lost frames will generally result in very unpleasant noise effects. To improve sound quality, lost frames are replaced by a repetition or extrapolation of previ-ous good speech frames. For each frame being substituted, the output level is decreased resulting in silence if too many frames are lost.

For lost SID frames, the first lost frame is substituted by the last valid SID frame. Subsequent lost SID frames are also replaced but the signal level is decreased, until silence is achieved.

4.10 Comfort Noise

The speech normally transmitted will always contain some acoustic background noise. When the DTX cuts the radio transmission, a total silence would be inserted. This will be very annoying to the user, and speech may even be hardly intelligible.

To avoid this, a synthetic noise similar to the background noise on the transmit side, is generated on the receive side. Comfort noise parameters are estimated on the transmit side and sent in special frames called silence descriptor frames [13]. The SID frame is transmitted at the end of speech bursts and serves as an end of speech marker for the receive side. In order to update the comfort noise characteristics at the receive side, SID frames are transmitted at low, but regu-lar intervals also during speech pauses. This also serves the purpose of improving the measurement of the radio link quality by the radio subsystem.


Homing

4.11 Homing

Homing is the process of resetting the codec to a pre-defined state. To allow reset of remote codecs, special homing frames have been defined for both the coder and the encoder. The homing frames are needed to ensure that the local and the remote speech codecs are synchronized in order to transcode speech information correct.

When the codec receives a homing frame at its input, it is processed as normal, generating an output frame which con-tents is usually unknown. After successful completion of frame processing, the reset functions are invoked for all modules - codec, VAD, DTX and comfort nose generator, setting the internal variables to pre-defined values. When the next frame arrives at the input, the codec will start from its home state.

Values for internal variables are defined in [10].

4.12 Transmission parameters

The parameters transmitted from the encoder are the quan-tizised linear spectral pair parameters, adaptive codebook gain and pitch, fixed codebook gain and pitch.

From the encoder, a total of 244 bits/20 ms are delivered for each frame, corresponding to a bitrate of 12.2 kbit/s. These are packed by the transcoding and rate adaption unit into frames of 320 bits resulting in a bitrate of 16 kbit/s. The additional bits are for CRC, synchronization, frame tagging and speech flag indicating if the frame contains speech or SID data. The layout and contents of the TRAU frames are fully described in [16].

When no speech is detected and SID frames are transmitted, only parts of the frame need to be used for data transfer. The remaining bits are then set to a fixed bit pattern called the


Transmission parameters

SID code word. The parameters replaced by the SID code-word are the adaptive codebook gain and pitch and the fixed codebook gain and pitch.


CHAPTER 5 Analysis

5.1 TSS overview

5.1.1 Overview

With increased complexity and number of functions in cel-lular phone systems there is a need for more advanced sys-tems for test and verification. To meet these demands, the TSS has been developed by Ericsson. It consists of hardware and software simulating most parts in a PLMN to be able to put each part in the PLMN under as realistic tests as possi-ble.

TSS can be connected to different interfaces in the tele-phone network depending on what aspect is going to be tested. For example, it can be used to test the BSC, by con-necting to both sides of the BSC, simulating several BTS on one side of the BSC and one MSC on the other side of the BTS.

5.1.2 TSS architecture

The TSS architecture is based on two different platforms - a unix workstation and standard VME hardware, see figure 5.1.


Problems

The workstations provides TSS with a user friendly devel-opment and an execution environment with a common GUI and a test programming environment with a high level test program language. There are also compilers, editors and log tools available.

Test programs running on the workstation will then perform the tests, by controlling the applications and protocols run-ning on VME hardware.

FIGURE 5.1. TSS architecture overview

5.2 Problems

The TSS is only able to simulate the signalling part in the network. No checks are done that the physical connections for the calls simulated really are set up. Therefore the traffic channels remain untested. This is a problem for circuit switched networks like the GSM.

There exists similar systems today, however they suffer from several problems:

• Different systems for the GSM and Personal Digital cel-lular (PDC) mobile systems.

• They are more of 'hacks' than officially supported prod-ucts.

Ethernet E1/T1

VME

VME

Workstation

BSC


Use cases

• Lack of documentation.

• Troublesome installation and setup.

• Non standardized user interface.

• Not designed for testing with the transcoding and rate adaption unit installed. The unit is simply removed and a loop back is set up.

5.3 Use cases

As an important step, to understand the requirements for this tool, some questions have to be answered. How will it be connected to the system under test and what must it be able to do? To get the answer to this question, we have to look at the different use cases for the tool. A use case, or scenario, is a description of how the tool is going to be used, from the users point of view.

The use cases are based on the different ways of how a phone call can be initiated. It can be a call from a mobile station to a subscriber in the public switched telephone net-work, or a call from a mobile station to another mobile sta-tion. Also taken into consideration is the possibilities to use TSS to simulate different parts of the GSM network. This gives the opportunity to perform tests with either real hard-ware or with the TSS simulating selected parts.

Eight different use cases have been identified in table 5.1. It is also listed in the table if TSS is used to simulate parts of the network, and which interface the test tool is connected to.

The term point of interconnection (POI) is here used to point out the interface where the GSM network connects to other networks through a GMSC.


Use cases

TABLE 5.1. Identified use cases.

5.3.1 Use case 1

In this case, figure 5.2, we have a simulated BTS and a real MSC. Basic testing of the BSC with the TRA unit can be done by connecting the test tool only to the Abis interface and looping back the call, to the Abis interface in the MSC. This would simulate a MS to MS call. The basic use case would allow the test to generate idle pattern on the traffic channels to simulate idle channels without traffic.

5.3.2 Use case 2

This case is identical to use case 1 except that the test tool now also generate traffic frames and inserts them on the Abis interface. The call is set up using normal signalling from TSS. When receiving information about the physical channel allocated, the TSS test program tells the test tool to use this channel for transmitting generated traffic.

No. Use case MSC BTS Interface

1 idle pattern real simulated Abis

2 MS-MS real simulated Abis

3 MS-PSTN real simulated Abis+POI

4 MS - MS simulated real A

5 MS - PSTN simulated real A

6 idle pattern simulated simulated Abis

7 MS - MS simulated simulated Abis + A

8 MS - PSTN simulated simulated Abis + A


Use cases

FIGURE 5.2. Use case 1 and 2 with simulated BTS and real MSC. Case 1 with no traffic and case 2 with traffic frames.

5.3.3 Use case 3

In this case, figure 5.3, the BTS is simulated and there is a real MSC. The test tool is connected to the Abis interface and the POI interface. This simulates an MS to PSTN call. The call is set up using normal signalling from TSS. When receiving information about the physical channel allocated, the TSS test program tells the test tool to use this channel for transmitting generated traffic. The test tool connected to the MSCs point of interconnection is set up to terminate the traffic on the allocated channel.

FIGURE 5.3. Use case 3. MS to PSTN call with simulated BTS and real MSC.

5.3.4 Use case 4

In this case, figure 5.4, we have a real BTS and a simulated MSC. The test tool on the A interface is set up to generate traffic on specific channels. The test tool connected to the A

B SCR eal M S C

Sim ula tedB T S

A b is AU m P O I

T est to o l

B S CR eal M SC

S im u la tedB T S

A b is AU m PO I

T est to ol T est to o l


Use cases

interface is setup to loop back the traffic frames. This is nec-essary since this is not done in the simulated MSC. This setup will simulate a MS to MS call.

FIGURE 5.4. Use case 4. MS to MS call with real BTS and simulated MSC.

5.3.5 Use case 5

In this case, figure 5.5, we have a real BTS and a simulated MSC. The test tool on the Abis interface is set up to gener-ate traffic on specific channels. The test tool connected to the A interface is setup to terminate the traffic frames. This setup will simulate an MS to PSTN call.

FIGURE 5.5. Use case 5. MS to PSTN call with real BTS and simulated MSC.

5.3.6 Use case 6

In this case, figure 5.6, both the BTS and MSC are being simulated. The basic function is to generate idle frames in the test tool to simulate idle traffic channels.

B S CR ealB T S

A b is AU m P O I

T est to ol T est to ol

S im u la ted M S C

B SCS im ula ted

M SCR ealB T S

A b is AU m P O I

T est to o l T est to ol


Use cases

FIGURE 5.6. Use case 6. Simulated BTS and simulated MSC with no traffic.

5.3.7 Use case 7

In this case, figure 5.7, both the BTS and MSC are simu-lated. The test tool is connected to the Abis interface to gen-erate traffic frames. It is also connected to the A interface to loop back the traffic. This use case would simulate an MS to MS call.

FIGURE 5.7. Use case 7. MS to MS call with simulated BTS and MSC.

5.3.8 Use case 8

In this case, figure 5.8, both the BTS and MSC are being simulated. The test tool on the Abis interface is set up to generate traffic. The test tool on the A interface is setup to terminate the traffic. This use case would simulate an MS to PSTN call.

B SCS im u la tedB T S

A bis AU m PO I

T est too l

S im u la tedM SC

B SCSim u la ted

B T S

A b is AU m PO I

T est to ol

S im u la tedM SC

T est too l


Requirements

FIGURE 5.8. Use case 8. MS to PSTN call with simulated BTS and MSC.

5.4 Requirements

People from management, development, support and test have been interviewed and the following basic requirements for the system were found, table 5.2. The right column shows where in the design chapter, the requirement has been considered. This is also further described in the Ericsson internal document [1].

B S CS im u la ted

B T S

A bis AU m PO I

T est too l

S im u la tedM S C

T est to o l


Requirements

TABLE 5.2. Basic requirements of test system.

Requirement Design area

The traffic generator shall create correct frames to be sent through the BSC.

6.2.2

Generated traffic shall be inserted primary on the Abis interface and also secondary on the A interface.

6.2.16.2.26.2.46.3.16.3.2

Contents of generated frames shall be selecta-ble.

6.2.56.3.4

Control of the traffic generator shall be done from TSS.

6.2.76.3.3

Different speech coding algorithms shall be supported.

6.2.3

Each instance of the traffic generator function shall be identified by PCM-link, timeslot and subchannel.

6.2.56.2.7

TRAU/TRAB frame parameters shall be possible to set from TSS test programs.

6.2.26.2.56.2.7.5

Insertion of user defined frames shall be possible.

6.2.56.2.7.56.3.4

Insertion of an external generated signal shall be possible.

6.2.56.3.4

Configuration shall be possible to do dynami-cally.

6.2.7.7


Requirements


CHAPTER 6 Design

6.1 Proposed solution

The solution proposed here, is that the system is imple-mented as an add-on to the existing TSS system. The unit can be seen as a new feature adding value to the current product.

The hardware platform to be used for the system is a Motorola MVME2400 carrier board with the QPM/56 DSP PMC Board [15] from Blue Wave Systems with Motorola 56301 DSP.

The unit will be placed as a component in TSS connecting to one, or both of the A and Abis interfaces of the BSC, see figure 6.1. It consists of the hardware it is running on and a piece of software.

The design only covers the software running on VME hard-ware, not test programmes running on the workstation.

The details of the design and implementation are also elabo-rated in the Ericsson internal document [1].


Functional overview

FIGURE 6.1. Solution running in TSS hardware.

6.2 Functional overview

This section describes the function blocks in the system. The interfaces for connection to other systems are described in section 6.3. The different functional blocks are shown in figure 6.2.

FIGURE 6.2. Functional blocks in the test tool.

6.2.1 PCM Frame adaption

The PCM frame adaption module handles adaption of speech information to and from the frame format used on the A interface. This includes both a-law PCM coding for

Sign alT erm ina lC o n tro l T R A U

B S C

L ine

L ineA b is

A

T SS

T est too l

PM C D S P

V M E C arrie r B o ard

B o ard

PC M F ram eA d ap tion

T R A U /T R A BFram e A d ap tion

PC Mco n version

S peechco d ecs

T rafficG en erator

U I

A b isA

T S S

T est to ol

S ig na l in te rface

Sta tistics


Functional overview

European systems and µ-law PCM coding for American and Pacific systems.

6.2.2 TRAU/TRAB Frame adaption

Different TRA protocols can be supported by implementing these as separate modules. The modules must be able to assemble correct frames for the TRAU or TRAB transmit-ting them on the Abis interface.

For GSM, 40 byte frames are sent on 16 kbps subchannels which are multiplexed into a 64 kbps channel. Information about TRAU frames are found in [17] and [18]. For TDMA/PDC 160 byte frames, consisting of three 53 bytes individu-als, are transmitted over 64 kbps channels [19].

6.2.3 Speech codecs

Different speech codecs must be supported. Today mainly the full rate and enhanced full rate codecs are used. How-ever, in the future adaptive multirate might be of interest as well [8]. The design is made so that new codecs are easily added. The election of codec is made during setup of the traffic generator for a specific channel.

Depending on how well simulations need to be done it is possible to delimit the implementation of the speech codecs to only encode/decode speech, omitting functions for voice activity detection and discontinuous transmission. However existing codecs might also be used and adapted to the sys-tem.

It might also be possible to have a null codec module. That is a module that can be chosen just like any other codec but it does not do anything with the signal. This can be useful if one wants to insert an already encoded signal or to minimize the demands for cpu processing time.


Functional overview

6.2.4 PCM conversion

The speech codecs for GSM are normally defined for taking 13 bit linear PCM-coded speech as input. The traffic genera-tor therefore outputs a signal using this coding. A conver-sion module will be needed to send traffic to the A interface. On the A interface the speech is encoded according to CCITT G.711 8 bit a-law PCM in Europe and 8 bit µ-law for American and Pacific systems.

6.2.5 Traffic generator

There are several possible sources that might be used as input signal used for testing the traffic channel. Some inter-esting sources are:

• Natural speech through headset.

• Sampled signal read from file.

• Internally generated signals.

• User defined frames.

To be able to insert speech from a headset, speech will have to be recorded and sampled on an external workstation and streamed over the network. This will require extra software for recording and streaming the speech on an workstation to the test tool and is not part of this design, except for an inter-face for receiving the sampled speech information.

Insertion of user-defined frames might be useful if one wants to send DTMF tones through the system under test.

Se also section 6.3.4 for more information about inserting external signals. Some aspects on signals useful for testing purposes are also described in [20].

Common to all signal sources are that the generated signal passes through the traffic generator. It is the module respon-sible for producing traffic at the set-up rate on the correct


Functional overview

channels. It will also select the correct signal source for each channel.

During a normal conversation the line is only occupied by speech approximately 50% of the time. This can be simu-lated by implementing a model using distributions for calcu-lating the length of, and interval between each speech session, i.e. the number of frames filled with speech data and the number of idle frames.

The traffic generator also acts as the signal destination. Therefore it must be able to receive and terminate incoming traffic that has been generated either by itself or by another instance of the traffic generator. Terminating the traffic can be done either by simply dropping the information, record-ing it to file through the signal interface or comparing it to the source signal and sending any error messages back to TSS and to error logs.

6.2.6 Statistics

Statistics might be useful to determine the capacity of the system and to see where and when bottlenecks occur. It could collect information like:

• number of incoming/outgoing packets.

• number of idle/data packets.

• number of erroneous packets.

• number of specific frames.

Statistics would be reported to TSS on demand. This feature has not been investigated because it has low priority from the customer and it is not immediately needed.


Functional overview

6.2.7 User interface

The user interface is the part responsible for the communi-cation between TSS and the test tool. It shall be imple-mented using the TSS network interface[22] allowing communication to and from TSS test programs.

Some message primitives and their parameters that would be used are described in the following sections.

6.2.7.1 Setup traffic generator

This message is sent to the test tool from TSS test program to create and configure a traffic generator on a given traffic channel. Parameters are:

• PCM Link, timeslot, subchannel, speedTogether the PCM link number, timeslot, subchannel and speed identifies the physical traffic channel to be used.

• CodecUsed to indicate which speech codec to be used.

• Source interfaceUsed to specify which protocol that should be used when reading frames from the source channel. For example TRAU frames on Abis interface or 8 bit PCM on A inter-face.

• Destination interfaceUsed to specify which protocol that should be used when sending frames to the destination channel. For example TRAU frames on Abis interface or 8 bit PCM on A inter-face.

• Signal sourceUsed to specify where to get the source signal from. It could be generated internally or inserted through the sig-nal interface.

• ActionUsed to specify what to do with the received signal. It can be forwarded to an external source through the signal


Functional overview

interface, validated for correctness or simply just dropped.

6.2.7.2 Remove traffic generator

This message is sent to the test tool from TSS test program to remove a previously created traffic generator on a given traffic channel. Parameters are:


6.2.7.3 Start traffic generator

This message is sent from TSS to the test tool to activate traffic generation on the associated channel. Parameters are:


6.2.7.4 Stop traffic generator

This message is sent from TSS to the test tool to activate traffic generation on the associated channel. Parameters are:


6.2.7.5 Frame request

This message is sent from TSS test program to the test tool to insert a user defined frame on a traffic channel. Parame-ters are:



Communication interfaces

• Frame dataThe user defined data to be inserted. The length will vary depending on if it is a TRAU/TRAB on the Abis inter-face or speech frame on the A interface.

6.2.7.6 Status indication

This message is sent from the test tool to the TSS test pro-gram in order to signal an error condition. Parameters in the message are:


• Error codeSome unique identifier for this kind of error message.

6.2.7.7 Configuration

The final product should have configuration possibilities similar to those in the GPRS GSL [21]. This however has to be further investigated since it might involve other parts of the TSS and is therefore not be covered within this report.

6.3 Communication interfaces

6.3.1 A interface

This part of the test tool connects directly to the A interface on the BSC. The test tool shall use allocated physical chan-nels and fill them with traffic. It shall also listen to allocated channels and terminate incoming traffic.

6.3.2 Abis interface

This part of the test tool connects directly to the Abis inter-face on the BSC. The test tool will use allocated physical


Communication interfaces

channels and fill them with traffic. It shall also listen to allo-cated channels and terminate incoming traffic.

6.3.3 TSS Interface

This part of the test tool connects to the TSS test program. It uses the TSS network interface for communication with TSS. The messages sent are described in 6.2.7.

6.3.4 Signal interface

This interface shall be used if a signal is loaded from a file or if a signal is sampled and played through a headset. The input signal shall be encoded according to 13 bit linear PCM coding and is parsed as a stream of bytes.

The interface is implemented as a generic link, using the TSS network interface [22]. It will connect to a source, whose location is given either through the configuration or when the link is created.


Software implementation

6.4 Software implementation

FIGURE 6.3. Software modules running on hardware.

The user interface module is implemented to be run on the VME carrier board, and the other modules are implemented to be run on a DSP, figure 6.3. The TSS and external traffic generator can be run on their own boards or workstations.

This division makes it possible to use the TSS framework [23] for implementing the user interface, hiding DSP details from the user and increasing portability. The functions run-ning on the DSPs will be implemented in ANSI-C for porta-bility.

Each DSP on the PMC module will run one instance of the traffic generator manager and codec modules. For each channel handled by the DSP there will be one traffic genera-tor. The user interface module will be responsible for dis-

H ost C P U

D SP D riv er

SC 40 0 0 D riv er E SS I D riv er

P C I D riv er

T G M

T G T G T G

PC I In te rface

E SS I Inte rface

E T G

C o d ecs an d Fram e ad ap tion

Q PM D S P I fc

SC B us Ifc

Prox y

T G L ink

U I

D SP s o n PM C b o ard

S C B u s

T S S

S ign a l Inte rface

T S S Inter face

V M E C arrie r b o ard



tributing requests for DSP resources among the DSPs to reduce the load on each DSP.

Scalability is introduced in the meaning that it will be possi-ble to switch to another DSP board with more DSPs, thanks to the proxy in the user interface. Another feature is that it is possible to use only a limited number of DSPs on the PMC module, in order for the application to share the resources on the DSP board with other applications.

6.4.1 External traffic generator

The location of the external traffic generator (ETG), is inde-pendent of this implementation since it uses the signal inter-face for communication with the test tool. The basic idea of this module is that it shall deliver a bitstream representing the signal to be transmitted by the traffic generators.

The external traffic generator can be implemented as a sim-ple server reading a file and sending the contents to the test tool. It might also be possible to control this module from TSS. The exact details and features of this module are not investigated further.

6.4.2 Driver modules

The DSP-, PCI-, SC4000- and ESSI Driver modules are existing drivers from the DSP board manufacturer that are being used for low level board control. These will be used without modification.

6.4.3 Proxy module

Messages from TSS are routed through the proxy module, to the correct DSP. On the DSP the traffic generator manager is responsible for dispatching the message to the correct traffic generator. Messages are either management messages like



starting and stopping traffic generation or insertion of user defined data frames, for example frames containing DTMF signalling.

At start-up this module sets up the communication between the DSPs and the carrier board. It will load code into the DSPs and make them start execution. The code to be loaded into the DSPs shall be possible to choose through the system configuration.

Parts of the Proxy, the QPM DSP and SC4000 interfaces might be reused from existing implementation of the GPRS GSL layer, see [24] and [25].

6.4.4 Traffic generator links

This is a client link that will connect to an external traffic generator. It will handle incoming data from the external traffic generator and pack it into messages understandable by the traffic generator manager (TGM), to separate them from management messages.

It will also receive incoming data from the DSP side, through the associated traffic generator. Data in received messages will be extracted and forwarded to the external traffic generator.

Expected data format from the external traffic generator is 13 bit linear PCM encoded speech, but any signal could be inserted.

Note that it is not necessary for every traffic generator to be associated with one link, but a link is always associated with a traffic generator. This is because the link only exists for traffic generators using an external traffic generator.



6.4.5 Traffic generators

The purpose of this module is to generate a signal that can be transmitted. This module must be invoked on a regular basis - every 20 ms - to fill a timeslot on the PCM link. If there is no data to transmit, idle frames shall be generated. This means that the module has to implement at least part of the TRAU/TRAB finite state automata protocols as described in [26] and [27].

This module will also be responsible to decide what to do with incoming data. When the channel is set up and a traffic generator is associated with it, parameters must be provided to configure the traffic. It shall be possible just to drop incoming data, to compare them with the original generated signal or to forward them on the A interface or to the exter-nal traffic generator.

Validation of data can only be done when a known sequence of data bits is generated. Therefore the generator mechanism will take a bit pattern as input and use it for both generation and validation. In this way the generating and validating traffic generator can be remote (i.e not the same instance and not even running on the same board).

The traffic generators will use the codec and frame adaption library to pack and unpack data in correct frames.

6.4.6 Traffic generator manager

This module will contain the main loop in the DSP software. It will receive management messages from TSS and dis-patch them to the correct traffic generator. Typical there will be one traffic generator manager running on each DSP and several traffic generators, one traffic generator for each logi-cal channel to generate traffic on.



6.4.7 PCI Interface

This module will implement an interface for communication over the carrier boards internal PCI bus. It will be reused from the GPRS GSL protocol layer, see [24] and [25].

6.4.8 ESSI Interface

This module will implement an interface for switching of data to 16 kbps channels. It will be reused from the GPRS GSL protocol layer, see [24] and [25].

6.4.9 Codecs and frame adapters

This will basically be a library of functions used by the traf-fic generators. It will consist of functions as discussed in 6.2.1, 6.2.2, 6.2.3 and 6.2.4 to implement the interfaces in 6.3.

The implementation of the enhanced full rate speech codec follows the overview in figure 4.5 and figure 4.6. The detail design is described in [2] and is intended to be an introduc-tion to the source code.


CHAPTER 7 Implementation and Test

7.1 Implementation of test tool

The GPRS GSL protocol layer as developed by Enea Epact for Ericsson can be used as a base for implementation of the test tool.

There are several similarities between the functions of GPRS GSL and the test tool.

• They access the same type of hardware functions like the DSP and SC-bus.

• The user interface has a well known structure and format.

• Several modules for internal communication between different parts of the hardware can be reused with little or no modification.

• Documentation and personnel skilled with GPRS GSL exist.

The test system proposed in previous chapters is not imple-mented within the limits of this thesis due to lack of time. Further discussion which parts can be reused, need to be modified or implemented from scratch are described in [1].


Implementation of speech codec

7.2 Implementation of speech codec

As a part of this master thesis a part of the proposed system was implemented. The part chosen for implementation was the most commonly used speech codec - the GSM enhanced full rate codec.

The implementation of the speech codec was divided into two parts

• Making the codec using several channels.

• Making the coder run in the target environment.

7.2.1 Multichannel mode

From the basic implementation of the coder the possibility to use several channels in parallel was implemented. This was basically to provide several instances of the codecs internal state variables, one instance per channel.

7.2.2 DSP implementation

From the start everything was implemented in ANSI-C to achieve as much portability as possible. When entering the DSP environment, performance became the crucial prob-lem.

The most frequently used functions are basic operations like addition, subtraction and multiplication. This also implies composed functions like MAC and MSU. All these operations had to be implemented in assembler as a first step to achieve performance.

From Motorola there is a document [28] available, describ-ing this procedure. This document is for use with another compiler than the one used, but the basic ideas are still the same.


Tools

7.3 Tools

The tools used during development was Emacs and the Suite56 for Motorola DSP 566xx/DSP563xx, available from [29] and [30].

The suite contains tools for compiling, linking and assem-bling both C and assembler code. There are also modules for simulation and hardware debugging. The simulator uses the host machine to emulate all the internal functionality of the DSP. This is very useful for debugging. However, the simu-lator is very slow, about 1000 times slower than running on hardware!

One of the most valuable tool in the suite were definitely the profiler. From the reports generated by the profiler, it was possible to find the bottlenecks in the code.

There is another compiler available from Tasking which claims up to 40% smaller and more effective code [31]. The compiler was not available for use during development. A demo version of the product was tested for comparing per-formance to the Motorola compiler, see 7.4. The main rea-son for not using the Tasking compiler is that it is too expensive compared to todays needs.

7.4 Problems

7.4.1 Performance of generated code

One of the goals were to write as much code as possible in C in order to make the code more portable, however a lot of assembler code had to be written for performance reasons.

Some of the performance problems can be derived from the compiler used. The code generated is far from optimal.


Problems

The compiler does not generate any hardware loops. For every loop an external memory reference is used as a loop counter, updated and checked against another memory refer-ence. The DSP supports special hardware loops through the DO assembler statement. The DO statement will use internal registers for the loop counter, and does only require an over-head of one instruction.

Several NOP instructions can be found in the generated code. However, several of these NOPs can be avoided by rescheduling of other instructions.

The parallel instructions in the DSP are not used. Using par-allel moves can speed up the implementation significant, since data fetching can be done simultaneously as arithmetic operations are performed in the ALU. The flag -alo used at compilation with the Motorola compiler will enable the assembly language optimizer to enable use of parallel moves [32], but very few parallel moves are actually pro-duced.

In appendix A there is assembler code generated from both the Motorola and the Tasking compiler for one selected function. The original C function is included in appendix B. Comparing these files one can se that the Tasking compiler makes use of the DO and DOR instructions on several occa-sions. The Motorola compiler instead uses memory loca-tions to store the loop counters, loads them into the ALU, increase the value and store them back in memory.

Several of the most time consuming functions could not be compiled with the Tasking Compiler because of limitations in the demo version used. The table 7.1 above shows that a significant increase of speed/size would be reached by changing compiler. As a comparison the number of instruc-tions in the hand optimized functions are also included. The differences between the compilers are propably even more noticeable when compiling larger files.


Problems

TABLE 7.1. Number of instructions generated by

compiler1.

7.4.2 Size of generated code

As can be seen in table 7.1 the Motorola compiler does not optimize code very well. This also turned out to be a prob-lem when the code had to be fitted into the memory of the DSP. A tedious setup in the makefile for the project, made the binary fit into the memory of the DSP. This will proba-

FunctionTasking

advancedTasking

compatible MotorolaHand

optimized

RatioMotorola/Tasking

advanced

cor_h_x 124 120 155 106 1.25

autocorr 157 141 219 101 1.39

pred_lt6 103 100 125 57 1.21

Pitch_ol 171 180 227 -- 1.33

Pitch_f6 105 110 134 -- 1.28

Lag_max 94 102 175 83 1.86

convolve 48 62 91 52 1.89

Syn_filt 83 93 115 62 1.36

1. Tasking compiler in Motorola compatibale mode used the following flags:C-compiler: -Cacrs -M24xL -OAcefghijnoprswUvxyz -gn

Assembler: -Ogjmnprs -Rdrs -Jl -S -M24xLTasking compiler in advanced mode used the following flags:

C-compiler: -M24xL -OAcefghijnoprswUvxyz -gnAssembler: -Ogjmnprs -Rdrs -Jl -S -M24xL

Functions compiled with the Motorola Suite56 compiler used the following flags:C-compiler: -S -mx-memory -o -S-alo -finline-functions -fforce-addr

Assembler flags for the Motorola compiler are included in flags to the C-compiler.The Motorola compiler did not have any preset modes for compiling for speed or size, therefore only one mode utilizing both speed and size has been used, and compared to the Tasking Advanced mode.


Problems

bly become a problem in the future if other functions are to be fitted into the DSP as well.

7.4.3 Word length

The algorithm for the speech codec uses 16/32 bit calcula-tions. All 32 bit operations are performed with simulated 32 bit instructions using only 16 bit instruction. The target DSP has a 24 bit architecture, with possibility to perform opera-tion in sixteen bit arithmetic mode.

This gives rise to several problems:

• 32 bit numbers and 24 bit memory word lengthOne problem occurring when using the 16-bit arithmetic mode is when trying to read/write 32 bit of data from/to memory. A 32 bit word requires two 24 bit words in memory. When writing data from the ALU, the first 24 bits will be written to the lower address and the last eight bits will be written to the eight least significant bits in the next word. This means the 16 most significant bits are shifted eight bits to the right. The same problem occurs when trying to read data to the ALU. This problem is connected to the transfer of data between the DSP and host board memory. Data is set up to be transferred with 16 bits aligned to the right in each 24 bit data word and the leading bits are sign extended.

• SaturationSaturation of 16/32 bit data has to be done with special routines or with special code within the basic operations, since the built in saturation will work with 24 bits only.

7.4.4 Performance of individual routines

The current most time-consuming functions are presented in table 7.2. The most time-consuming part of the algorithm seems to be the search for the best code vector, i.e. deter-


Problems

mining the positions of the ten pulses within the current frame of speech, to build the adaptive codebook.

Noticeable at the end of the implementation phase was that some of the already optimized C-functions, i.e functions rewritten in assembler, once again appeared at the top of the profilers list of time-consuming functions. These functions had to be further optimized.

TABLE 7.2. Most time consuming functions.

Routine % cycles Description

Search_10i40_asm 19.2 Codevector search.

cor_h_x 7.9 Correlation calculation.

Vq_subvec 6.2 Quantization of 4D sub vector.

cor_h_asm 4.7 Correlation of impulse response.

Vq_subvec_s 4.6 Quantization of 4d sub vector with sign.

Chebps 4.2 Evaluates the Cheby-shev polynomial series

L_extract 3.8 Extract from 32 bit to two 16 bit words.

Mpy_32_16 3.6 Multiply a 16 bit inte-ger by a 32 bit.

L_mac_asm 3.2 Long multiply and accumulate.


Testing

7.5 Testing

The modules have been tested in several steps as implemen-tation proceeded.

7.5.1 Multichannel mode

For the first phase, making the coder work for multiple channels, top down testing was used. Since one of the results in the test process was that the code should work as before, but on a channel basis, existing and verified code could be used instead of stubs and skeletons. This saved a lot of time.

First the new data structures were introduced. Changes were introduced at the top level code and the sub level interfaces. Testing was done and the results verified. Then changes were introduced on the next code level and further testing was done. This was repeated until the code in the leaf nodes had been changed and tested.

When the multi-channel mode had been implemented on all levels in the code hierarchy, a 'system test' could be per-formed on the top level functions. This test would verify that each channel worked independently of each other.

For these tests special test sequences could be used [33]. Those are designed to verify the different parts of the speech coder implementation.

7.5.2 DSP implementation

The second phase of implementation, when parts were rewritten in assembler bottom up testing was used.

The choice of test method was simple because of the nature of the code to be implemented. The code were leaf functions


Improvements

in the bottom of the code hierarchy which made the test method a natural choice.

Since these tests involved testing sub functions of the speech codec, the test data in [33] could not be used directly. Instead those data were used to generate new test data, appropriate for the function to be tested.

Generation of test data could easily be done since the imple-mentation was compiled and tested for the Sun platform. Test data from [33] was used as input to the top level func-tions and then the input and output parameters to the func-tion being tested could be extracted and saved to file. These parameters could then be imported into the test programs running on the Motorola DSP.

7.6 Improvements

Performance has to be improved. This can be done by merg-ing some functions into one single block. The drawback is that some structure is lost, but a performance gain could be made since fewer loops might have to be done and the number of memory copies can be decreased. Another way to increase performance would be to implement more func-tions in assembler. This will decrease portability, increase development time and increase complexity of the code.

Another solution would be to let the speech compression algorithm run on the carrier board cpu, and only implement low level framing on the DSP. This would be possible to do without any changes in the design of the codec.

Performance gain would also probably be reached by using the Tasking compiler instead of the Motorola compiler.


Improvements


CHAPTER 8 Conclusions

8.1 Need of system

A need for the proposed test system exists since there are several weaknesses in today’s system - lack of documenta-tion and support, non-standardized installation and user interface. As can be seen in 5.3, there are several ways that the traffic channel can be set up resulting in a complex sys-tem where automatic testing is preferred.

There is enough knowledge to implement the system since it has many similarities with the GPRS GSL. As a total, the system would improve the quality of the tested products.

Implementation of the full system would also build up a new competence. This would be useful for development of new test systems, training of new personnel, customers and test case developers.

8.2 Implementation so far

Speech processing is a area where several standards for compression exist. Compression ratio and reconstructed speech quality are two contradictionary properties among the coders. In GSM there are millions of users requiring


Alternative solutions

good speech quality. This also means good compression is needed to be able to fit all traffic channels into the physical transmission media. However, this requires processing power, and this has also been noticed within the implemen-tation phase of this thesis project.

The speech processing functions for encoding and decoding speech are fully implemented. However, since they suffer from performance problems they are not useful for realtime testing as they are implemented today on current hardware. The basic problem seems to be the number of instructions that are generated by the compiler.

8.3 Alternative solutions

One way of increasing performance would be a transfer to the Tasking compiler environment. This has the benefit that all functions would be sped up, which would yield an over-all performance increase. Also the code size would be decreased. Most important of all is probably that the need for direct implementation of functions in assembler can be avoided.

Another way would be to use a more powerful processor for execution of the code. Either by selecting another DSP as the target, or redesigning the system to allow the speech codec run on the host board CPU instead of on the DSP. This would leave only the low level framing functions to be executed on the DSP.

The system proposed could also be implemented without the speech codec and the traffic generator could use predefined test sequences, inserting them into the GSM traffic channel. The test sequences could then be generated offline, with no realtime demands. In this way the full system, with the TRA installed, could be tested, overcoming the problems described in 5.2.


APPENDIX A Generated code examples

Code compiled with the Tasking Compiler1; DSP563xx/6xx demo C compiler v3.0 r1 SN????????-233 (c) 2001 TASKING, Inc.2; options: -Id:\dc563\include -M24xL -O3 -gn34 page 1325 opt nops,now109,op,norp, w139,opspeed,cache12867 org p,".ptext":8 FConvolve:9 lua (r7+9),r710 move r4,x:(r7-7)11 move r0,x:(r7-8)12 move #0,r613 move r1,x:(r7-5)14 tst a15 jle L916 do a1,L917 gmove #0,a18 move a0,x:(r7-4)19 move a1,x:(r7-3)20 move r6,x:(r7-6)21 move (r6)+22 move r6,x:(r7-2)23 move r6,b24 move #0,y025 move x:(r7-8),r626 tst b27 jle L10

Design and implementation of test tool for th

Code compiled with Motorola Suite561 section convolve_c2 opt so,nomd,noidw3 page 132,66,3,34 org p:5 global FConvolve6 FConvolve7 move #5,n68 move (r6)+n69 move ssh,x:(r6)+10 move #0,r011 move y0,x:(r6)+12 move y1,x:(r6)+13 move a1,y114 move r2,x:(r6)+15 move r7,x:(r6)+16 move b1,x:(r6+(-10))17 move x:(r6+(-12)),y018 jmp L2119 L1820 move #0,r021 move #>0,x022 move #0,x123 move x1,x:(r6+((-7)+1))24 move r0,b25 move x0,x:(r6+(-7))26 move r0,x:(r6+(-9))27 move x:(r6+(-8)),x028 cmp x0,b29 jgt L1930

e GSM traffic channel 65

Code compiled with the Tasking Compiler28 do b1,L1029 move r6,x:(r7)30 move x:(r6),b31 move x:(r7-6),a32 move y0,x:(r7-1)33 sub y0,a34 move x:(r7-7),r335 move a1,n336 move x:(r3+n3),x037 move x:(r7-3),a38 move x:(r7-4),a039 jsr FL_mac40 move a0,x:(r7-4)41 move a1,x:(r7-3)42 move x:(r7),r643 move (r6)+44 move x:(r7-1),r345 move (r3)+46 move r3,y047 L10:void a, b, x0, y0, n3, r3, r648 move x:(r7-3),a49 move x:(r7-4),a050 move #>3,b51 jsr FL_shl52 asr #16,a,a53 move x:(r7-5),r654 move a0,x:(r6)+55 move r6,x:(r7-5)56 move x:(r7-2),r657 L9: void a, a0, b, x0, y0, n3, r3, r658 lua (r7-9),r759 rts6061 extern FL_mac, FL_shl6263 global FConvolve6465 local L9, L106667 calls "Convolve", "L_mac", "L_shl"6869 end

66 Design and implementatio

Code compiled with Motorola Suite5631 move y1,r732 L1733 move x:(r6+(-10)),b34 move x:(r6+(-9)),x035 move x:(r6+(-8)),a36 sub x0,a37 add a,b38 move b1,r239 move x:(r2),r240 move r2,x:(r6)+41 move x:(r6+((-8)+1)),a42 move x:(r6+(-8)),a043 move x:(r7)+,b44 jsr FL_mac45 move a0,x046 move a1,x147 move (r6)-48 move x1,x:(r6+((-7)+1))49 move x0,x:(r6+(-7))50 move x:(r6+(-9)),r051 move (r0)+52 move r0,b53 move r0,x:(r6+(-9))54 move x:(r6+(-8)),x055 cmp x0,b56 jle L175758 L1959 move x:(r6+((-7)+1)),a60 move x:(r6+(-7)),a061 move #>3,b62 jsr FL_shl63 move a0,x064 move a1,x165 move x1,x:(r6+((-7)+1))66 move x0,x:(r6+(-7))67 move x:(r6+(-11)),b68 move x:(r6+(-8)),x069 move x:(r6+((-7)+1)),a70 move x:(r6+(-7)),a071 add x0,b72 move b1,r273 move #>16,b74 tst b75 jeq L2276 rep b177 asr a

n of test tool for the GSM traffic channel

Code compiled with the Tasking Compiler

Design and implementation of test tool for the

Code compiled with Motorola Suite5678 L2279 move x0,r080 move a0,x:(r2)81 move (r0)+82 L2183 move r0,b84 cmp y0,b85 move r0,x:(r6+(-8))86 jlt L1887 move #(-5),n688 move (r6)-89 move x:(r6)-,r790 move x:(r6)-,r291 move x:(r6)-,y192 move x:(r6),y093 move (r6)-94 move x:(r6),ssh95 move (r6)+n696 rts979899 endsec100

GSM traffic channel 67

68 Design and implementatio
n of test tool for the GSM traffic channel

APPENDIX B Original C-code

Original C-function

/***************************************************************** * * FUNCTION: Convolve * * PURPOSE: * Perform the convolution between two vectors x[] and h[] and * write the result in the vector y[]. All vectors are of length L * and only the first L samples of the convolution are computed. * * DESCRIPTION: * The convolution is given by * * y[n] = sum_{i=0}^{n} x[i] h[n-i], n=0,...,L-1 * ****************************************************************/

#include "typedef.h"#include "basic_op.h"

void Convolve (Word16 x[], /* (i) : input vector */Word16 h[], /* (i) : impulse response */Word16 y[], /* (o) : output vector */Word16 L /* (i) : vector size */

){

Design and implementation of test tool for the GSM traffic channel 69

Word16 i, n;Word32 s;

for (n = 0; n < L; n++){

s = 0;for (i = 0; i <= n; i++){

s = L_mac (s, x[i], h[n - i]);}s = L_shl (s, 3);y[n] = extract_h (s);

}return;

}

70 Design and implementation of test tool for the GSM traffic channel

References

[1] Ericsson, “Implementation proposal for Load generation on GSM speech channel “, 2001.

[2] Ericsson, “Description TSS 2000 TRAUTiGer GSM EFR speech codec”, 2002.

[3] Studentlitteratur, Ericsson, Telia, “Att förstå telekommunikation 1", 1996, ISBN 9144378017.

[4] Studentlitteratur, Ericsson, Telia, “Att förstå telekommunikation 2", 1998, ISBN 9144278114.

[5] ETSI, “Digital cellular telecommunications system (Phase 2+); Mobile Station - Base Station System (MS - BSS) interface; General aspects and principles”, GSM 04.01 version 8.0.0, release 1999.

[6] ETSI, “Digital cellular telecommunications system (Phase 2+); Base Station Controller - Base Transceiver Station (BSC - BTS) interface; General aspects”, GSM 08.51 version 8.0.0, release 1999.

[7] ETSI, “Digital cellular telecommunications system (Phase 2+); Base Station System - Mobile-services Switching Centre (BSS - MSC) interface; General aspects”, GSM 08.01 version 8.0.0, release 1999.


[8] ETSI, “Universal Mobile Telecommunications System (UMTS); Speech Codec List for GSM and UMTS”, 3GPP TS 26.103 version 4.1.0 Release 4.

[9] ETSI, “Digital cellular telecommunications system (Phase 2+); Enhanced Full Rate (EFR) speech processing functions; General description”, 3GPP TS 06.51 version 8.2.0 Release 1999.

[10] ETSI, “Digital cellular telecommunications system (Phase 2+); Enhanced Full Rate (EFR) speech transcoding”, GSM 06.60 version 8.0.1 Release 1999.

[11] ETSI, “Digital cellular telecommunications system (Phase 2+); Voice Activity Detector (VAD) for Enhanced Full Rate (EFR) speech traffic channels”, GSM 06.82 version 8.0.1 Release 1999.

[12] ETSI, “Digital cellular telecommunications system (Phase 2+); Discontinuous Transmission (DTX) for Enhanced Full Rate (EFR) speech traffic channels”, GSM 06.81 version 8.0.1 Release 1999.

[13] ETSI, “Digital cellular telecommunications system (Phase 2+); Comfort noise aspects for Enhanced Full Rate (EFR) speech traffic channels”, GSM 06.62 version 8.0.1 Release 1999.

[14] ETSI, “Digital cellular telecommunications system (Phase 2+); Substitution and muting of lost frames for Enhanced Full Rate (EFR) traffic channels”, GSM 06.61 version 8.0.1 Release 1999.

[15] Blue Wave Systems, “QPM/56 Quad DSP56301 PCI Mezzanine Cars User Documentation”, 1998.

[16] Ericsson, “IWD Remote Transcoder Procedure General Description”, 16/155 19-HSC 103 12 Uen.

[17] ETSI, “Digital cellular telecommunications system (Phase 2+); In-band control of remote transcoders and rate adaptors for full rate traffic channels”, GSM 08.60 version 7.2.1 release 1998.

[18] Ericsson, “IWD Remote Transcoder Procedures for 16 kbps submultiplexing”, 15/155 19-HSC 103 12 Uen, Rev A.


[19] Ericsson, “PDC TRAU-96 Function Specification”, 155 17-1/CNA 117 30 Uen.

[20] ETSI, “Digital cellular telecommunications system (Phase 2+); Full rate speech; Transcoding”, GSM 06.10 version 8.0.2 release 1999.

[21] Ericsson, “IWD GSL Software Unit”, 15/155 19-CRL 113 112 Uen.

[22] Ericsson, “TSS2000 Network Traffic Interface”, 5/155 19-CRL 113 112 Uen.

[23] Ericsson, “TSS2000 Protocol Framework”, 17/155 19-CRL 113 112 Uen.

[24] Ericsson, “IP for GSL in project TSS Mercury”, 5/159 41 -FCP 103 1797 Uen.

[25] Ericsson, “Description GSL Software Unit”, 1551-CAL 1201 698 Uen.

[26] Ericsson, “IWD Remote Transcoder Procedure for Submultiplexing 16kbps”, 15/155 19-HSC 103 12 Uen.

[27] Ericsson, “IWD Remote Transcoder Procedures, General description”, 16/155 19-HSC 103 12 Uen, Rev A.

[28] Motorola, “Semiconductor Application Note: Efficient compilation of bit-exact applications for DSP563xx”, AN1772/D Rev 0 11/98, 1998.

[29] Motorola, “DSP56xxx Software Development Tools v3.0”, http://www.motorola.com/ http://e-www.motorola.com/webapp/sps/site/prod_summary.jsp?code=DSP56301&nodeId=01M98596#boards, Jan 2002.

[30] Metrowerks, “Suite56 for Motorola DSP 566xx/DSP563xx”, http://www.metrowerks.com/embedded/suite56, Jan 2002.

[31] Tasking, “DSP56xxx Software Development Tools v3.0”, http://www.tasking.com/products/DSP56xxx/index.html, Jan 2002.

[32] Motorola, “Motorola DSP56300 Family Optimizing C compiler Users manual”.


[33] ETSI, “Digital cellular telecommunications system (Phase 2+); Test sequences for the GSM Enhanced Full Rate (EFR) speech codec”, 3GPP TS 06.54 version 8.2.0 Release 1999.

[34] ETSI, “Digital cellular telecommunications system (Phase 2+); Abbreviations and acronyms”, GSM 01.04 version 8.0.0 release 1999.


Glossary

Further abbreviations can be found in [34].

Abbrevations

ACELPAlgebraic Code Excited Linear Prediction

ALU Arithmetic Logical Unit

AMR Adaptive Multi Rate

AUC Authentication Centre

BSC Base Station Controller

BSS Base Station System

BTS Base Transceiver Station

DSP Digital Signal Processor

DTX Discontinuous Transmission mode

DTMF Dual Tone Multi-Frequency (signalling)

EFR Enhanced Full Rate


EIR Equipment Identity Register

ETG External Traffic Generator

ETSI European Telecommunications Standards Institute

FR Full Rate

GMSC Gateway MSC

GPRS General Packet Radio Services

GSM Global System Mobile communications

GSL GSM Signalling Layer

HR Half Rate

HLR Home Location Register

LIF Line InterFace

LP Linear Prediction

LSF Line Spectral Frequencies

LSP Line Spectral Pairs

MAC Multiply and ACcumulate

MS Mobile Station

MSC Mobile Switching Center

MSU Multiply and SUbtract

NOP No OPeration

PCM Pulse Code Modulated


PDC Personal Digital Cellular

PLMN Public Land Mobile Network

PMC PCI Mezzanine Card

POI Point Of Interconnection

PSTN Public Switched Telephone Network

RX Receive

SID SIlence Descriptor

SUT System Under Test

TGM Traffic Generator Manager

TRAB Transcoding and Rate Adaption Board

TRAU Transcoding and Rate Adaption Unit

TSS Test and Simulation Solutions

TX Transmit

UMTS Universal Mobile Telecommunications System

VAD Voice Activity Detection

VLR Visitor Location Register

VME Versa Modular Eurocard bus


Terminology

A Interface between MSC and other telephone net-works.

Abis Interface between BSC and BTS.

Codec Coder decoder.

E1 Structured PCM connection at 2.048 Mbit/s with 30 timeslots.

ESSI Enhanced Synchronous Serial Interface. Serial interface on DSP towards the SC-bus.

frame Time interval of 20 ms corresponding to the time segmentation of the codec, also used as short term traffic frame

SID-codewordBit pattern for labelling traffic frames as SID frames.

SID-frameFrame characterized by the SID codeword. It con-veys information on the acoustic background noise. SID frames are transmitted when no speech infor-mation is available.

SC-bus Time division multiplexed serial bus used for com-munication between DSP board and LIF board.

T1 Structured PCM connection at 1.544 Mbit/s with 24 time slots.

Um Air Interface between MS and BTS.

VocoderVoice coder.


Index

Numerics16-bit arithmetic 58

24-bit architecture 58AA 10, 46

Abis 9, 32, 46ACELP 16

AD/DA 18

adaptive code book 20

adaptive codebook 17, 22

adaptive filtering 25

adaptive multirate 16, 41a-law 40, 42

ALU 56

ANSI-C 54

assembler 54, 56, 60

AUC 9

authorization 9Bbackground load 3

background noise 23, 24, 26

bandwidth 9, 14, 16

Blue Wave Systems 39

bottom up 60BSC 8

BTS 8

buCcococococococoDdadededidodrDDEEeaEEenenE

Design and implementation of a test tool for

rst management 9

dec 4

mfort noise generation 23

mmunication system 13

mpetence 63mpiler 64

nfiguration 37, 47

nversation 23, 43

tabases 9

coder 22mo 55

scontinous transmission 23

cumentation 31, 53, 63

ivers 49

SP 39, 48

TMF 24, 42, 50

1 9

r 14

FR 16

IR 9

coding 19cryption 8, 9

nea Epact 3

the GSM traffic channel 79

Ericsson Radio Network Center 3

error logs 43

error minimization 17

ESSI 49

ETG 49external signal 42

external traffic generator 49, 50

Ffilter memories 20

fixed codebook 17, 22

frame 19, 24, 26, 27, 37, 40, 41framework 48

GGateway MSC 7

generate 32

generic link 47

glottis 13GMSC 7, 9

GPRS 3

GSL 46, 50, 63

GSM 7

Hhalf rate 16handover 8

hardware 39, 53

hardware loops 56

headset 42

HLR 9

homing 27human speech 13

hybrid coders 15

Iidle pattern 32

impulse response 20

innovative codebook 20, 22installation 31, 63

instructions 64

interface 29, 40

interference 23

inLLlibLLLLLMmmMMMmmmNnenoNnuOopovPpapapaPCPCPDpepePLpoprPS

80 Design and implemen

terpolation 19

evinson-Durbin 19

rary 52

ine Spectral Frequencies 19ine Spectral Pairs 19

P coefficients 19

SF 19

SP 19, 22

asking 14essage primitives 44

otorola 39, 55

S 7

SC 7

u-law 41, 42

ultichannel 54, 60uting 24, 26

twork interface 44

ise 26

OP 56

ll codec 41

timize 57

erhead 56

rallel 56

rallel moves 56rameters 27

I 52

M 47

C 30, 41

rception 14, 17

rformance 54, 61, 64MN 7

rtability 48

ofiling 59

TN 7

tation of a test tool for the GSM traffic channel

Qquality 16, 63

quantization 15, 19

Rredundancy 19requirements 31, 36

reset 27

Ssaturation 58

SC4000 49, 50, 53

scalability 49scenario 3

signal source 43

silence 26

simulator 4, 31, 55

solution 39

speech codec 15, 41, 54statistics 43

substitution 24, 26

support 30, 63

synchronization 27

TT1 9Tasking 55

TDMA 41

test 29, 60

test data 60, 61

test program 47

test sequences 64TGM 50

threshold 24

top down 60

TRA 41

traffic channel 3

traffic generator 42traffic generator manager 49, 50

transceiver 10

TRAU 10

TSS 29, 47

UUunususVVvaVVvovovovovoWww

Design and implementation of a test tool for

m 9

voiced sounds 13

e cases 31er interface 31, 48

AD 25

lidation 51

LR 9

ME 48cal cords 13

cal tract 14

coders 15

ice activity detection 23, 24

iced sounds 13

ave form coders 15

ord length 58

the GSM traffic channel 81

82 Design and implemen
tation of a test tool for the GSM traffic channel

På svenska

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under en längre tid från publiceringsdatum under förutsättning att inga extra-ordinära omständigheter uppstår.Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns det lösningar av teknisk och adminis-trativ art.Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart.För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/

In English

The publishers will keep this document online on the Internet - or its possible replacement - for a considerable time from the date of publication barring exceptional circumstances.The online availability of the document implies a permanent permission for anyone to read, to download, to print out single copies for your own use and to use it unchanged for any non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional on the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility.According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement.For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its WWW home page: http://www.ep.liu.se/

© Theo Öjerteg

institutionen för systemteknik - diva portal18557/fulltext01.pdfinstitutionen för systemteknik 581...

Documents