1 / 26

Design and implementation of the operation and maintenance software for a new GSM transcoder

Design and implementation of the operation and maintenance software for a new GSM transcoder. Author: Paavo Markkola Supervisor: Professor Raimo Kantola Instructor: M.Sc. Juha Pajuvirta. General Information. Thesis written at Nokia networks during 2004 – 2005. Contents.

lahela
Download Presentation

Design and implementation of the operation and maintenance software for a new GSM transcoder

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Design and implementation of the operation and maintenance software for a new GSM transcoder Author: Paavo Markkola Supervisor: Professor Raimo Kantola Instructor: M.Sc. Juha Pajuvirta

  2. General Information • Thesis written at Nokia networks during 2004 – 2005

  3. Contents • Objectives of the thesis • Methodology • Transcoders in GSM networks • Nokia transcoders • Operation and maintenance software • Implementation • Test bench • Conclusions

  4. Objectives of the thesis • To design and implement the operation and maintenance (O&M) software for the Nokia third generation GSM transcoder and submultiplexer (TCSM3i). • TCSM3i hardware is based on the current, second generation transcoder and submultiplexer (TCSM2). • TCSM2 O&M software can be used as the basis for the TCSM3i O&M software. • This work is about the changes required to the TCSM2 O&M software so that it can be used with the TCSM3i hardware.

  5. Methodology • Nokia software development procedure • Requirement specification • The changes needed to the O&M software from TCSM2 level • Implementation specification • Describes the principles how the feature is to be implemented • Implementation • Changes to code in assembler, PLM and C languages • Testing the that the implementation works

  6. Transcoders in GSM networks (1) • The GSM system features several codecs that are used in order to reduce the number of bits transferred over the radio interface • On the network side these codecs are implemented in Transcoding and Rate Adaptation Unit (TRAU) • The purpose of the TRAU is to • Transcode speech between the standard 64 kb/s PCM format and the encoded formats used on the GSM radio interface • Perform rate adaptation for data calls between 64 kb/s and limited bit rates on the radio interface • Speech codecs • Full Rate (FR) 16 kb/s • Half Rate (HR) 8 kb/s • Enhanced Full Rate (EFR) 16 kb/s • Adaptive Multirate (AMR) 16 kb/s • Bits rates for data calls • GSM data 9.6 kb/s • GSM data 14.4 kb/s • High Speed Circuit Switched Data (HSCSD) allows more than one channel to be used for the same connection, max 40 – 50 kb/s • Every call in a GSM network must eventually go through TRAU

  7. Um A BSS NSS MS BTS TRAU MSC/VLR GMSC BSC PSTN Gb GPRS Packet Core SGSN GGSN Data Networks Transcoders in GSM networks (2) • TRAU is part of the Base Station Subsystem (BSS) although it is usually located next MSC • TRAU operates on physical level and does not handle GSM signaling • TRAU can be integrated with a submultiplexer • Four 16 kb/s, or eight 8 kb/s, channels can be submultiplexed in to one 64 kb/s channel • The closer to the MSC the TRAU is located the better utilization of the transmission capacity

  8. Nokia Transcoders (1) • Transcoder and submultiplexer (TCSM) • Submultiplexer is fully intergraded to the device • Based on the Nokia DX200 platform • Three generations of transcoders • The first generation transcoder is obsolete and no longer supported • The current transcoder product is TCSM2 • The new transcoder, TCSM3i, does not directly replace TCSM2, instead it provides an alternative solution • Always located in between BSC and MSC, and can be considered as an internal part of the BSC • Digital Signal Processors (DSP) are used to implement the TRAU functionality • Exchange Terminals (ET) provide PCM lines (either E1 or T1) towards BSC and MSC • Provides one PCM line towards BSC (Ater interface) and four (with full rate channels) or seven (with half rate channels) PCM lines towards MSC (A interface)

  9. Nokia transcoders (2), TCSM2 • TCSM2 consist of four different plug-in units • Transcoder controller plug-in unit (TRCO) • Controls the operation of the transcoder • Transcoder plug-in unit (TR12/16) • Incorporates 12 (ANSI) or 16 (ETSI) on board DSPs • Two plug-in units required per A interface PCM line • Exchange terminals plug-in units (ET2E/A) • Implements two E1 or T1 PCM lines • Power source plug-in unit (PCS1) • All plug-in units except the power source require software • Full rate capacity is 120 (ETSI) or 95 (ANSI) channels • Eight units in can be equipped to a cabinet • Cabinet capacity is 960/768 channels TCSM2

  10. Nokia Transcoders (3), TCSM3i • Consist of only one plug-in unit, TR3E/A • Motherboard is based on the TRCO plug-in unit • Daughter board consist of 6 (ANSI) or 7 (ETSI) DSPs. • DSPs have six cores each capable of handling three traffic channels • Does not support half rate • ET16 plug-in units provide PCM lines for several TCSM3i units • External clocks provide synchronization • TCSM3i cartridge holds 16 TR3E/A units and six cartridges can be equipped to TCSM3i cabinet TCSM3i

  11. Nokia Transcoders (4), Why TCSM3i? • The main reason to develop TCSM3i is to accommodate the transcoding capacity to the capacity of the new high capacity BSCs • One TCSM3i cabinet replaces several TCSM2 cabinets • Another reason is to upgrade the DSP platform • Capacity of the DSPs in TCSM2 is limited

  12. Operation and Maintenance Software • Runs on the controlling unit; TRCO in TCSM2 or TR3E/A motherboard in TCSM3i • Built for 16-bit 186 type processors with 1 MB memory range • Stored to flash memory in the controlling unit and the maximum size is 512 kB • TCSM2 also has a ROM version which ensures that the flash version is up-to-date • The responsibilities of the O&M software are • making sure that the software modules used by the transcoder are up-to-date, • loading devices with appropriate software modules, • supervising the operation of the transcoder, • performing diagnostics on the transcoder unit, • configuring the transcoder and maintaining configuration data, and • implementing local and remote interfaces to the transcoder. • Built around the Nokia proprietary operating system called PECTUS • Functionality implemented with a number of PECTUS processes with defined purposes and responsibilities • Processes communicate with each other by sending messages • BSC – TCSM communication is also based on messages

  13. Implementation, Hardware Changes • Host processor is different Intel 80186EB @ 16 MHz  AMD Am186ER @ 50 MHz • Instruction set is the same • Boot procedure is different • Boots from flash instead of ROM as in TCSM2 • Must also copy itself from flash to RAM  execution continues from RAM • Submultiplexer implemented with a Field Programmable Gate Array (FPGA) device • Needs to be loaded and configured • Storage flash memory is different • Size increased from 512 kB to 8 MB, but bank size decreased from 256 kB to 64 kB • DSP code loading memory is used to load DSPs • Banked to 64 kB pages with total size 512 kB • The DSP block and the interface to it are completely different • Use of High-Level Data Link Control (HDLC) channels to external devices (ET and clock units) depends on the location of the TR3E/A plug-in unit • Units have different roles • Internal clock replaced with cabinet level external clocks • Only cabinet head master can control external clocks • Exchange terminals have 16 units instead of just two • Only cartridge master (Ater and A interface) and masters (A interface) have control over exchange terminals

  14. Implementation, Boot Procedure • Two phased boot procedure • In the first phase boots from flash • Copy everything from flash to RAM • Using only host processor’s registers • The first phase completed when I/O pin is turned by software • Memory configuration is altered • Next instruction is fetched from the same address in RAM • Flash and DSP code loading memories are now mapped to 64 kB areas after 256 kB data memory • Second phase then initializes hardware devices flash FFFFFH UCS 80000H RAM LCS 00000H RAM FFFFFH UCS 80000H Flash and DSP MCS 40000H Data LCS 00000H

  15. Implementation, FPGA Configuration • The FPGA device must be configured during boot – otherwise the plug-in unit won’t work • The device is loaded with a code stored to flash • Loading proceeds with five software controlled I/O pins • Proceeds one bit at a time • The size of the FPGA code is about 5 million bits

  16. Implementation, HDLC channels • HDLC channel is connected to a time slot in a PCM line • Link Access Protocol – channel D (LAPD) protocol is used on top of HDLC channels to established links to other systems • TCSM2 has five HDLC channels; one to BSC (16 kb/s) and four to ET plug-in units (64 kb/s) • TCSM3i has four channels but their usage depends on the role of the unit • All units have BSC connection • Cabinet head master has two connections to the external clocks • Cartridge master has two connections ET plug-in units (Ater and A interfaces • Master has one connection to ET plug-in unit (A interface) • HDLC channel configuration needs an update; PCM time slot etc. • For simplicity LAPD process tries to establish all four links • Only links using a working HDLC channel can get up • LAPD process must also be able to send messages through proper link according to their destination

  17. Implementation, Flash Manager • Needs to control all accesses to banked memories • flash and DSP code loading memory • Totally redesigned • Cannot handle operations that cross page boundaries • Page size is reduced from 256 kB to 64 kB • Flash interface is different as the flash device is different • Flash operations • Read – reads a number of words from flash • Write – programs a number of words to flash • Blank – erases (sets bits high) a number words in flash • Checksum – calculates checksum over an area in flash • Search – searches for a user defined string in flash • Flash sector size increased from 32 kB to 64 kB • Equal size flash buffer is required for flash write operations • 64 kB out of 256 kB data memory is too much  moved to DSP code loading memory • Write operations are not allowed when DSPs are being loaded

  18. Implementation, Software Downloading • The O&M software loads all used software modules from BSC during restart • Compares modules to see whether software update is necessary • The user can also upload modules from PC through the serial port with kermit protocol • TR3E/A plug-in unit is useless if the O&M or FPGA modules on flash are corrupted • Cannot rely on ROM module anymore • Update procedure must be safe • Due to the slow connection (16 kb/s) download takes several minutes for each software module • Needs a temporary location in flash for downloaded modules • If download successful then copy software to primary location • In TCSM2 the software update process has its own flash interface • Flash manager interface needed

  19. Implementation, DSP Management • DSP supervision proceeds as in TCSM2 but the interface to the DSP block is different • Only one 16-bit message register per DSP core • Three channels must use the same register • Problematic as DSP cores have interrupts disabled in 125 µs periods • To minimize worst case delay the protocol must make consecutive writes to different registers • Channel failures cause restart of the corresponding DSP core • If the channel is in the first core then the whole DSP must be restarted • DSP load procedure is also different • Software is first copied from flash to DSP code loading memory • Hardware logic loads the DSPs • Once complete the host processors is interrupted • All PCM lines connected the transcoder may use different codec • In TCSM3i one software can implement all codecs and features • TCSM2 has several softwares due to the limitations of the DSPs • In TCSM3i the same software must be loaded to all DSPs as no combination DSPs matches one PCM

  20. Implementation, ET Management • In principle ET management works as before • Less ET plug-in units • More ET units • The capacity of the control link to an ET16 plug-in unit is 64 kb/s • Delays are needed otherwise the link is overflowed • ET16 plug-in units must be loaded • Software is much larger than in TCSM2  takes more time • Needs message interface to flash manager • Not all TCSM3i units have ET plug-in units in their control • One ET16 plug-in unit provides Ater interface PCM line for all units in a TCSM3i cartridge • One ET16 plug-in unit provides A interface PCM lines for four TCSM3i units • TR3E/A might be swapped  must recognize in which role configuration in flash was lat used • If the TCSM3i does not control any ET16 plug-in units then ET managements goes idle

  21. Implementation, Diagnostics • Some of the tests require changes due to the new hardware • Read/write test for DSP code loading memory • Flash manager must do this • It is not possible to set loops in ET units as the TCSM3i units may not have control over their ET units • Loop in the submultiplexer part • External clocks must be tested • Clock units can perform their own diagnostics • Flash test calculates checksums from code memory • Changed to calculate checksum from storage flash as well

  22. Implementation, Synchronization • Internal clock unit has been replaced with two external clock units • Common for the whole TCSM3i cabinet • Working and spare units • Cabinet head master is the only TCSM3i unit with the control links to the clock units • Head master is the second TCSM3i in the first cartridge of the cabinet • The responsibilities of the head master include • Supervision – supervises the clock units once every 30 seconds • Configuration – forwards user defined configuration to the clock units • Diagnostics – forwards diagnostics request from the user to the clock units • Alarms – informs BSC of the alarms sent by the clock units

  23. Implementation, User Interfaces • User can connect to the transcoder locally through serial port or remotely from BSC through a message interface • The serial port is the host processors internal serial port • Driver needs an update as host processors are different • The user interface consist of Man-Machine Interface (MMI) style commands • Several commands require minor updates as they reflect the hardware configuration

  24. Test Bench • One TR3E/A plug-in unit and a cartridge • ETSI and ANSI daughter boards • Two ET16 plug-in units • Prototypes • Two external clock units • Power source • PRTA plug-in unit • Provides service terminal interface to PECTUS • New software has to be burned to a flash chip

  25. Conclusions • New hardware – lots of difficult problems • Lot more work than expected • Including several small things that needed changes • At the moment seems quite stable

  26. Questions?

More Related