Full iris recognition Text 01

download Full iris recognition Text 01

of 94

Transcript of Full iris recognition Text 01

  • 7/29/2019 Full iris recognition Text 01

    1/94

    Institutionen fr 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 HGSKOLANLINKPINGS UNIVERSITET

    Department of Electrical engineering Linkpings tekniska hgskolaLinkping University Linkpings UniversitetS-581 83 Linkping 581 83 Linkping

  • 7/29/2019 Full iris recognition Text 01

    2/94

  • 7/29/2019 Full iris recognition Text 01

    3/94

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

    Examensarbete utfrt i datatransmissionvid Linkpings Tekniska Hgskola av

    Theo jerteg

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

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

    Linkping 2002-06-04

  • 7/29/2019 Full iris recognition Text 01

    4/94

  • 7/29/2019 Full iris recognition Text 01

    5/94

    Avdelning, Institution

    Division, Department

    Institutionen fr Systemteknik581 83 LINKPING

    Datum

    Date2002-06-04

    SprkLanguage RapporttypReport category ISBN

    Svenska/SwedishX Engelska/English

    LicentiatavhandlingX Examensarbete

    ISRN LITH-ISY-EX-3169-2002

    C-uppsats

    D-uppsats

    Serietitel och serienummer

    Title of series, numberingISSN

    vrig rapport_____

    URL fr elektronisk version

    http://www.ep.liu.se/exjobb/isy/2002/3169/

    Titel

    Title

    Design och implementation av ett testverktyg fr GSM talkanal.

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

    Frfattare

    AuthorTheo jerteg

    SammanfattningAbstractTodays systems for telecommunication are getting more and more complex. Automatic testing isrequired to guarantee quality of the systems produced. An actual example is the introduction ofGPRS traffic in the GSM network nodes. This thesis investigates the need and demands for such anautomatic testing of the traffic channels in the GSM system. A solution intended to be a part of theEricsson TSS is proposed. One problem to be solved is that todays tools for testing do not supporttesting of speech channels with the speech transcoder unit installed. As part of the investigation, aspeech 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, andgives 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.

    Nyckelord

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

  • 7/29/2019 Full iris recognition Text 01

    6/94

  • 7/29/2019 Full iris recognition Text 01

    7/94

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

    Contents

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

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

    2.1 Background . . . . . . . . . . . . . . . . . . . . . . . 3

    2.2 Assignment . . . . . . . . . . . . . . . . . . . . . . . 4

    2.3 Limitations . . . . . . . . . . . . . . . . . . . . . . . . 5

    2.4 Purpose of this report . . . . . . . . . . . . . . . 5

    2.5 Reading instructions . . . . . . . . . . . . . . . . 5

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

    3.1 Telecommunication overview. . . . . . . . . 7

    3.2 Networking elements. . . . . . . . . . . . . . . . 7

    3.3 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . 9

    3.4 Inside the equipment. . . . . . . . . . . . . . . 10

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

    4.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . 13

    4.2 Human speech model . . . . . . . . . . . . . . 13

    4.3 Different codecs. . . . . . . . . . . . . . . . . . . 15

    4.4 Enhanced full rate codec . . . . . . . . . . . 16

    4.5 Speech encoding. . . . . . . . . . . . . . . . . . 19

    4.6 Speech decoding . . . . . . . . . . . . . . . . . . 22

  • 7/29/2019 Full iris recognition Text 01

    8/94

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

    4.7 Discontinuous Transmission Mode . . . 23

    4.8 Voice Activity Detection . . . . . . . . . . . . 24

    4.9 Substitution and muting . . . . . . . . . . . . 26

    4.10Comfort Noise . . . . . . . . . . . . . . . . . . . . 264.11Homing . . . . . . . . . . . . . . . . . . . . . . . . . . 27

    4.12Transmission parameters . . . . . . . . . . . 27

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

    5.1 TSS overview . . . . . . . . . . . . . . . . . . . . . 295.1.1 Overview . . . . . . . . . . . . . . . . . . . . 29

    5.1.2 TSS architecture . . . . . . . . . . . . . . 29

    5.2 Problems. . . . . . . . . . . . . . . . . . . . . . . . . 30

    5.3 Use cases . . . . . . . . . . . . . . . . . . . . . . . . 315.3.1 Use case 1. . . . . . . . . . . . . . . . . . . 32

    5.3.2 Use case 2. . . . . . . . . . . . . . . . . . . 325.3.3 Use case 3. . . . . . . . . . . . . . . . . . . 33

    5.3.4 Use case 4. . . . . . . . . . . . . . . . . . . 33

    5.3.5 Use case 5. . . . . . . . . . . . . . . . . . . 34

    5.3.6 Use case 6. . . . . . . . . . . . . . . . . . . 34

    5.3.7 Use case 7. . . . . . . . . . . . . . . . . . . 355.3.8 Use case 8. . . . . . . . . . . . . . . . . . . 35

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

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

    6.1 Proposed solution . . . . . . . . . . . . . . . . . 39

    6.2 Functional overview . . . . . . . . . . . . . . . 406.2.1 PCM Frame adaption. . . . . . . . . . . 40

    6.2.2 TRAU/TRAB Frame adaption. . . . . 416.2.3 Speech codecs . . . . . . . . . . . . . . . 41

    6.2.4 PCM conversion. . . . . . . . . . . . . . . 426.2.5 Traffic generator . . . . . . . . . . . . . . . 42

    6.2.6 Statistics . . . . . . . . . . . . . . . . . . . . 43

    6.2.7 User interface . . . . . . . . . . . . . . . . 44

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

    6.3.2 Abis interface . . . . . . . . . . . . . . . . . 46

  • 7/29/2019 Full iris recognition Text 01

    9/94

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

    6.3.3 TSS Interface . . . . . . . . . . . . . . . . .47

    6.3.4 Signal interface. . . . . . . . . . . . . . . .47

    6.4 Software implementation. . . . . . . . . . . . 48

    6.4.1 External traffic generator . . . . . . . . 496.4.2 Driver modules . . . . . . . . . . . . . . . . 49

    6.4.3 Proxy module . . . . . . . . . . . . . . . . .49

    6.4.4 Traffic generator links . . . . . . . . . . .50

    6.4.5 Traffic generators . . . . . . . . . . . . . . 51

    6.4.6 Traffic generator manager . . . . . . . 51

    6.4.7 PCI Interface. . . . . . . . . . . . . . . . . .52

    6.4.8 ESSI Interface . . . . . . . . . . . . . . . . 52

    6.4.9 Codecs and frame adapters . . . . . .52

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

    7.1 Implementation of test tool . . . . . . . . . . 53

    7.2 Implementation of speech codec . . . . .547.2.1 Multichannel mode . . . . . . . . . . . . .54

    7.2.2 DSP implementation. . . . . . . . . . . .54

    7.3 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

    7.4 Problems . . . . . . . . . . . . . . . . . . . . . . . . . 557.4.1 Performance of generated code . . . 557.4.2 Size of generated code. . . . . . . . . .57

    7.4.3 Word length . . . . . . . . . . . . . . . . . . 58

    7.4.4 Performance of individual routines . 58

    7.5 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . .607.5.1 Multichannel mode . . . . . . . . . . . . .60

    7.5.2 DSP implementation. . . . . . . . . . . .60

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

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

    8.1 Need of system . . . . . . . . . . . . . . . . . . . .63

    8.2 Implementation so far . . . . . . . . . . . . . . 63

    8.3 Alternative solutions . . . . . . . . . . . . . . . 64

  • 7/29/2019 Full iris recognition Text 01

    10/94

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

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

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

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

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

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

  • 7/29/2019 Full iris recognition Text 01

    11/94

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

    CHAPTER 1 Preface

    Thanks to all people at Enea Epact and Ericsson who have

    been answering my questions and helping with whatever

    problem Ive 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.

    Linkping 2002-06-04

    Theo jerteg

  • 7/29/2019 Full iris recognition Text 01

    12/94

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

  • 7/29/2019 Full iris recognition Text 01

    13/94

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

    CHAPTER 2 Introduction

    2.1 Background

    This master thesis work was done as part of the programme

    for Computer Science and Engineering at Linkping 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.

  • 7/29/2019 Full iris recognition Text 01

    14/94

    Assignment

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

    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 thistool. 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.

  • 7/29/2019 Full iris recognition Text 01

    15/94

    Limitations

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

    2.3 Limitations

    Only the speech encoding and decoding functions will be

    implemented since this is an area where there is not enoughknowledge 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.

  • 7/29/2019 Full iris recognition Text 01

    16/94

    Reading instructions

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

    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.

  • 7/29/2019 Full iris recognition Text 01

    17/94

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

    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.

  • 7/29/2019 Full iris recognition Text 01

    18/94

    Networking elements

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

    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 tothe 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 CP S TN

    Other

    PLM N

    A U C EIR

    H L R

    V LR V L R

    B S C

    M S C M SC

    B T S

    B T S

    B T S M S

    A

    Abis

    U m

  • 7/29/2019 Full iris recognition Text 01

    19/94

    Interfaces

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

    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 networkelements. 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 comesthe 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

  • 7/29/2019 Full iris recognition Text 01

    20/94

    Inside the equipment

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

    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 areaccessed from the BSC via a transceiver radio interface

    switching traffic channels from the BSC to the correct trans-

    ceiver and vice versa.

  • 7/29/2019 Full iris recognition Text 01

    21/94

    Inside the equipment

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

    FIGURE 3.2. Inside the switching elements.

    T R X

    T R I

    C O N T R O L

    T R X

    L IF

    L IF

    T E R M

    T R A U

    C O N T R O L

    M

    UX

    L IF

    L IF

    T E R M

    C O N T R O L

    B SC

    GM SC/M SC

    BT S

    Other networks

  • 7/29/2019 Full iris recognition Text 01

    22/94

    Inside the equipment

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

  • 7/29/2019 Full iris recognition Text 01

    23/94

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

    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

  • 7/29/2019 Full iris recognition Text 01

    24/94

    Human speech model

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

    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

  • 7/29/2019 Full iris recognition Text 01

    25/94

    Different codecs

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

    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 maintypes 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 signalsamplitude 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.

    Lo w

    Excellent

    Good

    Average

    Hybrid codersWaveform coders

    Vocoders

    Speech qual ity

    bitrate(kbit/s)2 4 8 16 32 64

  • 7/29/2019 Full iris recognition Text 01

    26/94

    Enhanced full rate codec

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

    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. Thebitrate 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 ExcitedLinear Prediction (ACELP) system. A simple description of

    the synthesis model can be found in figure 4.3.

  • 7/29/2019 Full iris recognition Text 01

    27/94

    Enhanced full rate codec

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

    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 isthen 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 comfortnoise 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.

    Adapt ive codebook

    Fixedcodebook

    L P s yn th es is P os t f il te rin g+

  • 7/29/2019 Full iris recognition Text 01

    28/94

    Enhanced full rate codec

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

    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 arespeech 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 oice

    activity

    detector

    Speechencoder

    Com fo r tnoice TXfunct ions

    D TXControl

    an doperation

    Transm it side R ece ive side

    D T XControl

    andoperat ion

    Speechframe

    substitution

    Speechdecoder

    Com fo r tnoise RXfunct ions

    1

    2

    3

    4

    3

    4

    15

    6

    6

    7

    8

    9

    3

    3

    1

    1

  • 7/29/2019 Full iris recognition Text 01

    29/94

    Speech encoding

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

    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 fullrate 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

    ofp linear equations withp 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.

  • 7/29/2019 Full iris recognition Text 01

    30/94

    Speech encoding

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

    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 iscalculated. 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 iscalculated.

    The target signal and the impulse response of theweighted 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 iscalculated and removed from the target signal giving the

    target signal for the innovative codebook search.

    Finally filter memories are updated for use in the nextsubframe.

  • 7/29/2019 Full iris recognition Text 01

    31/94

    Speech encoding

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

    FIGURE 4.5. Encoder.

    frame

    subframe

    Pre-processing

    LPC

    analysis

    (twiceperframe)

    Open-looppi

    tchsearch

    (twiceper

    frame)

    Adaptivecodebo

    ok

    search

    Innovativecodebook

    search

    Filtermemory

    upda

    te

    Pre-processing

    windowi

    ng

    and

    autocorrela

    tion

    R[]

    Levinson-

    Durbin

    R[]->

    A(

    z)

    A(z)->L

    SP

    LSP

    quantization

    LSP

    indices

    interpolation

    forthe4

    subframes

    LSP->

    (z)

    interpolation

    forthe4

    subframes

    LSP->

    A(z)

    s(n) A

    (z)

    compute

    weighted

    speec

    (4subfram

    es)

    find

    open-loopp

    itch

    A(z)

    (z)

    h(n)

    To

    x(n)

    x(n)

    A(z)

    (z)

    h(n)

    computetarget

    foradaptive

    codebook

    findbestdelay

    andgain

    quantize

    LTP

    _gain

    compute

    adaptive

    codebook

    contribution

    computetarget

    forinovation

    code

    index

    LTP

    gain

    index

    update

    filter

    memoriesfor

    nextsub

    frame

    fixe

    d

    codebook

    gain

    quantiz

    ation

    fixedcod

    ebook

    gainin

    dex

    pitch

    index

    x2

    (n)

    compute

    impulse

    response

    findbest

    innovation

    comp

    ute

    exitat

    ion

  • 7/29/2019 Full iris recognition Text 01

    32/94

    Speech decoding

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

    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 thereceived index to find the gain from the quantization

    table.

    The innovative codebook vector is decoded by using thereceived index to extract positions and amplitudes of the

    excitation pulses and find the algebraic code vector.

    The fixed codebook gain is decoded from the receivedindex.

    Finally the speech is reconstructed by filtering of theexcitation 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.

  • 7/29/2019 Full iris recognition Text 01

    33/94

    Discontinuous Transmission Mode

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

    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 sub fram e

    LS Pindices

    decode LSP

    interpolationof LSP for the

    4 subframes

    LS P -> (z )

    pitchindex

    gainsindices

    codeindex

    decodeadapt ive

    codebook

    decodeinnovative

    codebook

    decodegains

    const ructexcitation

    post filter

    post -processing

    synthesisfilter

    s n( ) s' n( )

  • 7/29/2019 Full iris recognition Text 01

    34/94

    Voice Activity Detection

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

    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 speechdecoder.

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

    Bad or lost frames are replaced by a substitution andmuting 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 aflag 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 notbe filtered out, while strong resonances from vehicles for

    example should be classified as noise.

    Periodic component in input signal. If the input signalcontains stationary noise the threshold should be raised,

    however vowels also produce a stationary frequency

  • 7/29/2019 Full iris recognition Text 01

    35/94

    Voice Activity Detection

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

    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. Ascan 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 activitydetection algorithm.

    VAD

    decisionVAD

    hangover

    Periodicity

    detection

    Tonedetection

    Predictorvalues

    computation

    Autocorrelation

    averaging

    Spectralcomparison

    Threshold

    adaption

    Adapt. filtering

    and energycomputation

    Autocorrelation

    Lag values

    Reflection

    VAD flag

    coefficients

    vector

  • 7/29/2019 Full iris recognition Text 01

    36/94

    Substitution and muting

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

    4.9 Substitution and muting

    Substitution and muting is performed as a result of lost or

    invalid frames received by the radio subsystem [14]. Mutingis 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.

  • 7/29/2019 Full iris recognition Text 01

    37/94

    Homing

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

    4.11 Homing

    Homing is the process of resetting the codec to a pre-defined

    state. To allow reset of remote codecs, special homingframes 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 allmodules - 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

  • 7/29/2019 Full iris recognition Text 01

    38/94

    Transmission parameters

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

    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.

  • 7/29/2019 Full iris recognition Text 01

    39/94

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

    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 hardwareand 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.

  • 7/29/2019 Full iris recognition Text 01

    40/94

    Problems

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

    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

  • 7/29/2019 Full iris recognition Text 01

    41/94

    Use cases

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

    Lack of documentation.

    Troublesome installation and setup.

    Non standardized user interface.

    Not designed for testing with the transcoding and rateadaption 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 ableto 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 connectedto.

    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.

  • 7/29/2019 Full iris recognition Text 01

    42/94

    Use cases

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

    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 signallingfrom 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 Abis2 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

  • 7/29/2019 Full iris recognition Text 01

    43/94

    Use cases

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

    FIGURE 5.2. Use case 1 and 2 with simulated BTS andreal MSC. Case 1 with no traffic and case 2 with trafficframes.

    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 simulatedBTS 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 SCRea l

    M S CSimulated

    B TS

    A bis AU m P O I

    Test tool

    B S CReal

    M SCSimulated

    B TS

    A bis AU m PO I

    T est tool T est too l

  • 7/29/2019 Full iris recognition Text 01

    44/94

    Use cases

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

    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 BTSand 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 CRea l

    B T S

    A bis AU m P O I

    T est tool T est tool

    Simulated

    M SC

    B SCSimulated

    M SCRea l

    B T S

    A bis AU m P O I

    T est too l Test tool

  • 7/29/2019 Full iris recognition Text 01

    45/94

    Use cases

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

    FIGURE 5.6. Use case 6. Simulated BTS and simulatedMSC 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 simulatedBTS 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 SCSimulated

    B TS

    A bis AU m PO I

    Test tool

    Simulated

    M SC

    B SCSimulated

    B TS

    A bis AU m PO I

    Test tool

    Simulated

    M SC

    Test tool

  • 7/29/2019 Full iris recognition Text 01

    46/94

    Requirements

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

    FIGURE 5.8. Use case 8. MS to PSTN call with simulatedBTS 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 CSimulated

    B TS

    A bis AU m PO I

    Test tool

    Simulated

    M S C

    Test tool

  • 7/29/2019 Full iris recognition Text 01

    47/94

    Requirements

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

    TABLE 5.2. Basic requirements of test system.

    RequirementDesign

    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.1

    6.2.2

    6.2.4

    6.3.1

    6.3.2

    Contents of generated frames shall be selecta-

    ble.

    6.2.5

    6.3.4Control of the traffic generator shall be done

    from TSS.

    6.2.7

    6.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.5

    6.2.7

    TRAU/TRAB frame parameters shall be

    possible to set from TSS test programs.

    6.2.2

    6.2.56.2.7.5

    Insertion of user defined frames shall be

    possible.

    6.2.5

    6.2.7.5

    6.3.4

    Insertion of an external generated signal shall

    be possible.

    6.2.5

    6.3.4

    Configuration shall be possible to do dynami-

    cally.

    6.2.7.7

  • 7/29/2019 Full iris recognition Text 01

    48/94

    Requirements

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

  • 7/29/2019 Full iris recognition Text 01

    49/94

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

    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].

  • 7/29/2019 Full iris recognition Text 01

    50/94

    Functional overview

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

    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

    SignalTerminalC on tro l T RA U

    B S C

    Line

    Line

    Abis

    A

    T SS

    Test tool

    PM C D SP

    VME Carr ie r Boa rd

    Board

    PCM Frame

    Adapt ion

    T R A U / T R A B

    Frame Adapt ion

    PC Mconversion

    Speechcodecs

    TrafficGenerator

    U I

    AbisA

    T S S

    Test tool

    Signal interface

    Statistics

  • 7/29/2019 Full iris recognition Text 01

    51/94

    Functional overview

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

    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. Howeverexisting 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.

  • 7/29/2019 Full iris recognition Text 01

    52/94

    Functional overview

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

    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

  • 7/29/2019 Full iris recognition Text 01

    53/94

    Functional overview

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

    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 anotherinstance 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.

  • 7/29/2019 Full iris recognition Text 01

    54/94

    Functional overview

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

    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 programto 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

  • 7/29/2019 Full iris recognition Text 01

    55/94

    Functional overview

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

    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:

    PCM Link, timeslot, subchannel, speedTogether the PCM link number, timeslot, subchannel and

    speed identifies the physical traffic channel to be used.

    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:

    PCM Link, timeslot, subchannel, speedTogether the PCM link number, timeslot, subchannel and

    speed identifies the physical traffic channel to be used.

    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:

    PCM Link, timeslot, subchannel, speedTogether the PCM link number, timeslot, subchannel and

    speed identifies the physical traffic channel to be used.

    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:

    PCM Link, timeslot, subchannel, speedTogether the PCM link number, timeslot, subchannel and

    speed identifies the physical traffic channel to be used.

  • 7/29/2019 Full iris recognition Text 01

    56/94

    Communication interfaces

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

    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:

    PCM Link, timeslot, subchannel, speedTogether the PCM link number, timeslot, subchannel and

    speed identifies the physical traffic channel to be used.

    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 ofthe 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

  • 7/29/2019 Full iris recognition Text 01

    57/94

    Communication interfaces

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

    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 fileor 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.

  • 7/29/2019 Full iris recognition Text 01

    58/94

    Software implementation

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

    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-

    Host CPU

    DS P D r ive r

    SC 4000 D river E SS I D river

    PCI Driver

    T G M

    T G TG T G

    PCI Interface

    ESSI Interface

    ETG

    Codecs andFrame adapt ion

    QPM DSP Ifc

    SCBus Ifc

    Proxy

    TG Link

    U I

    DSPs on PM C board

    S C B u s

    TS S

    Signal Interface

    TSS Interface

    VM E Carrier board

  • 7/29/2019 Full iris recognition Text 01

    59/94

    Software implementation

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

    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 fromTSS. 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 usedwithout 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

  • 7/29/2019 Full iris recognition Text 01

    60/94

    Software implementation

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

    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.

  • 7/29/2019 Full iris recognition Text 01

    61/94

    Software implementation

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

    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 regularbasis - 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 providedto 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 validatingtraffic 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.

  • 7/29/2019 Full iris recognition Text 01

    62/94

    Software implementation

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

    6.4.7 PCI Interface

    This module will implement an interface for communication

    over the carrier boards internal PCI bus. It will be reusedfrom 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.

  • 7/29/2019 Full iris recognition Text 01

    63/94

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

    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 theDSP and SC-bus.

    The user interface has a well known structure and format.

    Several modules for internal communication betweendifferent 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].

  • 7/29/2019 Full iris recognition Text 01

    64/94

    Implementation of speech codec

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

    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 wasthe 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 operationshad 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.

  • 7/29/2019 Full iris recognition Text 01

    65/94

    Tools

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

    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.

  • 7/29/2019 Full iris recognition Text 01

    66/94

    Problems

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

    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 internalregisters for the loop counter, and does only require an over-

    head of one instruction.

    Several NOP instructions can be found in the generatedcode. However, several of these NOPs can be avoided byrescheduling 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 usedat 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 boththe 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.

  • 7/29/2019 Full iris recognition Text 01

    67/94

    Problems

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

    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 notoptimize 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 -M24xL

    Tasking compiler in advanced mode used the following flags:

    C-compiler: -M24xL -OAcefghijnoprswUvxyz -gn

    Assembler: -Ogjmnprs -Rdrs -Jl -S -M24xL

    Functions compiled with the Motorola Suite56 compiler used the followingflags:

    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 forspeed or size, therefore only one mode utilizing both speed and size has beenused, and compared to the Tasking Advanced mode.

  • 7/29/2019 Full iris recognition Text 01

    68/94

    Problems

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

    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 writin