x cem user guide

xCEM Quick Start And Debug Guide

Document number: UMT/BTS/DJD/025388 Document issue: 02.01/ EN Document status: Standard Date: 01/Sept/2008

Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization

Copyright 2007-2008 Alcatel-Lucent, All Rights Reserved

Printed in France

UNCONTROLLED COPY: The master of this document is stored on an electronic database and is “write protected”; it may be altered only by authorized persons. While copies may be printed, it is not recommended. Viewing of the master electronically ensures access to the current issue. Any hardcopies taken must be regarded as uncontrolled copies.

ALCATEL-LUCENT CONFIDENTIAL: The information contained in this document is the property of Alcatel-Lucent. Except as expressly authorized in writing by Alcatel-Lucent, the holder shall keep all information contained herein confidential, shall disclose the information only to its employees with a need to know, and shall protect the information from disclosure and dissemination to third parties. Except as expressly authorized in writing by Alcatel-Lucent, the holder is granted no rights to use the information contained herein. If you have received this document in error, please notify the sender and destroy it immediately.

without notice. Networks assumes no responsibility for errors that might appear in t.All other brand and product



UMT/BTS/DJD/025388 02.01/ EN Standard 01/Sept/2008 /46

PUBLICATION HISTORY

September 1 st, 2008

Issue 02.01 / EN

Minor document format modifications

August 1, 2008

Issue 02.00 / EN

Standard release

Adding slave IMT command

July 31, 2008

Issue 01.02 / EN, Preliminary

Adding CDM Tool and XCLA post-processing tool information

July 30, 2008

Issue 01.01 / EN, Preliminary

Creation F.Bonnet




CONTENTS

1. INTRODUCTION............................................................................................................................5

1.1. OBJECT....................................................................................................................................5

1.2. SCOPE OF THIS DOCUMENT .......................................................................................................5

1.3. AUDIENCE FOR THIS DOCUMENT ................................................................................................5

2. RELATED DOCUMENTS .................................. ............................................................................5

2.1. APPLICABLE DOCUMENTS ..........................................................................................................5

2.2. REFERENCE DOCUMENTS..........................................................................................................5

3. XCEM OVERVIEW.........................................................................................................................6

3.1. XCEM EXTERNAL INTERFACES DESCRIPTION.............................................................................6

3.2. TOP LEVEL SOFTWARE ARCHITECTURE AND INTERNAL ITF..........................................................7

3.3. XCEM HARDWARE ARCHITECTURE.............................................................................................8

3.4. XCEM CONFIGURATIONS & TARGET CAPACITY ..........................................................................9

3.5. XCEM SW IMAGE DESCRIPTION – FILE SYSTEM......................................................................10

3.6. BEHAVIOR UPON SW DOWNLOADING .......................................................................................11

3.7. FACEPLATE DEBUG PORT DESCRIPTION ...................................................................................11

3.7.1 Debug cable ..................................................................................................................12 3.7.2 Cable schema ...............................................................................................................12

3.8. XCEM ROADMAP ....................................................................................................................12

4. HOW TO…...................................................................................................................................12

4.1. …CONNECT TO THE XCEM FRONT PANEL ................................................................................12

4.2. …CONNECT TO THE XCEM FROM THE MASTER BOARD .............................................................13

4.2.1 From XCCM Boards......................................................................................................13 4.2.2 From (i)CCM Boards .....................................................................................................13

4.3. …TRANSFER FILES FROM / TO THE XCEM................................................................................13

4.4. …RUN RTC TOOLS ................................................................................................................14

4.5. …DISABLE / ENABLE THE LOADER ............................................................................................14

4.6. …ACTIVE PARTITION PROTECTION BYPASS...............................................................................14

4.7. INSTALL A NEW XCEM SOFTWARE ...........................................................................................15

4.7.1 To inactive FFS .............................................................................................................15 4.7.2 To active FFS................................................................................................................16

4.8. …GET THE XCEM SOFTWARE MARKING...................................................................................16

4.9. …CHECK THE XCEM HWREF................................................................................................18

4.10. …GET / SET THE IP ADDRESS (TEMPORARY)............................................................................19

4.10.1 GetTing the ICU IP address ..........................................................................................19 4.10.2 SetTing the ICU IP address (Temporary) .....................................................................20

4.11. …SET THE ICU IP ADDRESS (PERMANENTLY) ..........................................................................20

4.11.1 Modifying the ICU IP address (PQ2).............................................................................20




4.11.2 Modifying the subnet mask (ICU)..................................................................................22 4.12. …SET THE BBU IP ADDRESS (PERMANENTLY) .........................................................................22

4.13. …RESET THE BOARD ..............................................................................................................23

4.14. …SWAP ACTIVE/PASSIVE PARTITIONS ......................................................................................23

4.15. …GET EEC LOGS ..................................................................................................................23

4.16. …GET THE IMT......................................................................................................................24

4.17. …ENABLE / DISABLE SOME TRACES .........................................................................................24

4.17.1 Traces redirection on the console.................................................................................24 4.17.2 PQ2 (ICU) – MCTL Tracing / debugging.......................................................................24 4.17.3 PQ3 (BBU) – CECTL/CECTL L1Tracing ......................................................................29 4.17.3.1 CECTL L1 tracing ......................................................................................................29 4.17.3.2 CECTL tracing/debugging .........................................................................................31 4.17.4 Decoding CECTL traces ...............................................................................................32

5. WHAT LOGS TO ATTACH TO A CR? ....................... ................................................................33

5.1. NO CLUE ABOUT TRACES TO BE PROVIDED?.............................................................................33

5.2. SPECIFIC TRACES TO BE LOGGED ON XCEM (BASICS) ..............................................................34

5.2.1 DWL issue.....................................................................................................................34 5.2.2 SLOAM issue ................................................................................................................34 5.2.3 NBAP checks output by CallP.......................................................................................34 5.2.4 CE related issues with XCEM .......................................................................................34 5.2.4.1 OneChip UL/DL Control messages ...........................................................................34

6. CELL DIAGNOSTIC MONITOR ............................ ......................................................................34

6.1.1 CDM version usage.......................................................................................................35 6.1.2 Using CDM tool .............................................................................................................36 6.1.2.1 Connecting to XCEM .................................................................................................36 6.1.2.2 Launching CDM tool ..................................................................................................36 6.1.3 Post-Processing CDM log .............................................................................................40 6.1.3.1 XCLA Installation .......................................................................................................40 6.1.3.2 Launching XCLA........................................................................................................41

7. ABBREVIATIONS AND DEFINITIONS...................... .................................................................42

7.1. ABBREVIATIONS ......................................................................................................................42

7.2. DEFINITIONS...........................................................................................................................43

8. ANNEX: XCEM CALLP MENU DETAILS..................... ..............................................................44




1. INTRODUCTION

1.1. OBJECT

This document is a quick start guide for the xCEM.

This digital module within the iBTS is in charge of SLOAM management, part of call processing and all L1 processing.

The xCEM is the next generation of Channel Element Module board for Alcatel-Lucent macro Node-B. The xCEM is an enhanced version of the legacy iCEM2.

The board hardware is inherited from the former Lucent UCU3 and adapted to fit with all the legacy iBTS interfaces.

1.2. SCOPE OF THIS DOCUMENT

This document provides basic info in order to help any one dealing with xCEM such as starting-up the board, flashing, logging traces and debugging as well.

This board was first introduced on UA05.2 node-B software version.

1.3. AUDIENCE FOR THIS DOCUMENT

This document is dedicated to each team or people working with xCEM module.

2. RELATED DOCUMENTS

2.1. APPLICABLE DOCUMENTS

[A1] N/A

2.2. REFERENCE DOCUMENTS

[R1] Livelink 6900203 (ex-Lucent doc) U4146 UMTS Channel Unit xCEM

[R2] UMT/BTS/DD/021738 xCEM introduction in iBTS Functional Spec - UA5.1

[R3] UMT/BTS/DD/00371 UMTS OMC-B-NodeB Interface Data Model

Description (MOD)

[R4] UMT/BTS/DD/020537 iBTS BBU load allocation algorithm

[R5] UMT/BTS/APP/000037 BCS RTCTOOLS MMI

[R6] UMT/BTS/DD/012438 xCEM BCS High Level Design

[R7] Livelink 8835320 (ex-Lucent doc) UMTS CDM User’s Guide




3. XCEM OVERVIEW

3.1. XCEM EXTERNAL INTERFACES DESCRIPTION

The xCEM board (i.e. the ucu3n board) fits into the iBTS as shown by the figure below.

Figure 1: iBTS high level functional view

Interface 1 ITF-1 represents the Iub signaling link used to transport the dedicated part of the 3Gpp NBAP protocol. On BTS side ITF-1 is terminated in the xCEM itself. The CCP is hence managed at the xCEM level. Internally the iBTS CCM software configures and operates the xCEM module through ITF-2 and ITF-3. Interface 2 ITF-2 is used internally by the CCM Call processing software to forward incoming NBAP common configuration messages to the xCEM Call processing software. (e.g. Cell Setup, CTCH Setup or Radio Link Setup). ITF-2 is also used by the xCEM to forward incoming NBAP dedicated messages to the CCM Call processing software. (e.g. Radio Link Addition or Reconfiguration). Interface 3 ITF-3 is used internally by the CCM OAM software to manage the xCEM board. (i.e. board configuration, start up, fault management). This is the usual interface between a slave board and the CCM.

NBCP

RNC

CCM Call Processing

Software

iBTS CCM OAM

Software

CCM NBAP router

CCP

U-plane

NBAP-c flow

NBAP-d flow

TRM Software TRM

Software

ucu3n

xCEM

ITF-2

ITF-2

ITF-1

ITF-3




3.2. TOP LEVEL SOFTWARE ARCHITECTURE AND INTERNAL I TF

The xCEM top-level software architecture consists of three main components:

• Platform OAM, which is inherited from ex NT SLOAM / Platform software

• Modem Controller, which implements the 3GPP NBAP-d functionality

• CE Controller, which implements the Layers L1 and L2 of the UTRAN

The figure below depicts the top-level architecture of the xCEM.

Figure 1: xCEM functional view

Interface 4

SLOAM software uses ITF-4 in order to provide the NBAP-d Call Processing software with all necessary configuration parameters. ITF-4 is also used for fault reporting.

Interface 9

ITF-9 provides SLOAM with the mean to setup and release internal needed AAL5 PVCs (for inter board SMSG connections) as well as the external AAL5 PVC supporting the SSCOP connection associated to the CCP. This external SSCOP connection is setup, maintained and tear-down by the ASU layer.

Modem controller (MCTL)

OAM Platform (MCTL)

ITF-1

ITF-2

ITF-4

ITF-3

NT Platform

SLOAM

ITF-9

CE controller (CECTL)

Channel element (OneChip Plus )

CCP

NBAP-d

ATM driver

[RNC]

[CCM OAM] [CCM Callp, TRM]

ATMConn

SSCOP

ASU

xCEM




ITF-9 also provides SLOAM with the mean to configure internal AAL2’ PVCs used to transport the data streams (i.e. the different Frame Protocols instances) internally (i.e. between the CCM board and the xCEM modules).

3.3. XCEM HARDWARE ARCHITECTURE

The xCEM board mainly consists of

� 2 PowerQUICCs

� 1 Master Controller: PowerQUICC2 (MPC8347) ICU-like

� 1 Slave Controller: PowerQUICC3 (MPC8555) BBU-like

� 4 OneChips ASIC Channel Element supporting conventional Release 99 traffic

� 1 programmable baseband processor OneChipPlus Channel Element supporting Release 5 HSDPA and Release 6 HSUPA and made of one DSP + 3 FPGA (A, B&C)

� HSSPC-II ASIC supporting the HSSL backplane connection

� 1 combiner FPGA supporting mainly interface functions with OneChip ASICs and HSSPC-II ASIC

Detailed hardware breakdown structure hereafter.




3.4. XCEM CONFIGURATIONS & TARGET CAPACITY

XCEM capacity is based on iCEM Capacity Model




– 6 cells per hBBU, 6 cells per eBBU, and max 6 cells per xCEM, either 1c6s or 2c3s

– Max 3 ways Softer HO among up to 6 sectors

– HSDPA and HSUPA are on the same xCEM board for a given cell

Rules

1. If a Cell is HSDPA and EDCH, both, HSDPA and EDC H for this cell shall be managed by the same xCEM

2. HSDPA and EDCH parts of all cells of the same ca rrier shall be managed by the same type of CEM (either xCEM or iCEM)

Restrictions at Introduction :

• Max. 2 xCEM modules per iBTS in UA05.2 and 3 xCEM in UA06.0

• HSPA resources for one Carrier to be provided by same xCEM board

1 Carrier cannot be distributed across xCEM boards

Inter-board communication required for such distribution pending Customer requirements (post UA06)

Supported Configurations for a given Carrier

In case of mixed configurations (NodeB equipped with iCEMs & xCEMs):

• xCEM preferably used to support HSDPA+HSUPA

• for a given carrier, HSDPA/HSUPA traffic either all on iCEM(s) or all on xCEM(s)

3.5. XCEM SW IMAGE DESCRIPTION – FILE SYSTEM

On the contrary of xCCM board, XCEM board is working on a VX works-based OS.

However, L1 SW elements differ compared to CEM legacy boards since they are inherited from the former Lucent UCU3. L1 binaries are mostly in a zipped file format.

The PL XCEM is made of 20 files that must be flashed in the FFS partition.

Here is the whole list:




bistsxcempq2.bists.fbin

bootl2xcem.fbin

bootl3xcem.fbin.zl � the bootL3 contains the bootboot EL

uc_CallP_xcem.fbin.zl

uc_Dwl_xcem.fbin.zl

xcem_cmdfile � similar to nodeB File0, dedicated to xCEM PQ2 usage

cectlpackage.txt � idem for xCEM PQ3 usage (L1 part)

cectl.vx, cectl.mod, cectlespd.gz, cectlespc.gz � PQ3 ELs

cectlcfpg.gz � combiner FPGA EL

cectlcfpgP0.gz* � former P0 board combiner FPGA EL

cectldspa.gz, cectlfpga.gz, cectlfpgb.gz, cectlfpgc.gz � OneChip+ ELs

cectlocbs.gz, cectloccc.gz, cectloccd.gz � OneChip ELs

* This file is useless since P0 board no longer exits. It could be removed from the PL content for buffer usage optimization and for flashing timing improvement at the factory.

3.6. BEHAVIOR UPON SW DOWNLOADING

Upon upgrade, all files described in chapter 3.1.5 are downloaded into the PQ2 area. Then a procedure is triggered between both PQ2 (ICU-like) and PQ3 (BBU-like) allowing the PQ3 to retrieve all the files dedicated to it (ie: cectl*.* files).

This process avoids the need of handling both PQ2 and PQ3 upgrade area from a pure CCM point of view. So, from the outside, there is no change compared to legacy CEM boards.

3.7. FACEPLATE DEBUG PORT DESCRIPTION

To allow direct xCEM access for debugging purpose, 2 Ethernet port are available on the front plate:

1. One for ICU-like interface (PQ2), similar to legacy CEM boards; RTC menu and CallP menu are available.

However, some of the RTC commands are not available due to the architecture inherited from the UCU3.

PQ2 ICU connector provide also a synchronization clock for lab test purpose with same features as the legacy ICEM.

2. One for BBU-like interface (PQ3), to get PQ3 crash records, CE traces, and all other L1 stuff…

These two ports can be used from a PCONS or an Ethernet connection. So you may need 2 different IP addresses for this board!




– for PCONS settings please refer to chapter 4.2

3.7.1 DEBUG CABLE

In order to connect simultaneously both connection to the xCEM (Ethernet and physical connection; ie: PCONS), we may need Y cable:

BTS debug ports RJ 45 LAN (whatever ICU or BBU) SubD9 or RJ45 annex port

3.7.2 CABLE SCHEMA

3.8. XCEM ROADMAP

Step 1: UA5.1: BBU management is iCEM-like, 2 xCEM max within a cabinet, + mixity supported. For further details, please refer to [R2]

Step 2: UA6.0: mBBU,

4. HOW TO…

4.1. …CONNECT TO THE XCEM FRONT PANEL

You can connect to the board via the Debug ports of the front panel:

• By opening a Telnet session with the xCEM IP address (Debug address) ICU and or BBU depending on front panel connector to be used,

• OR by opening a PCONS session (RS232) with the following settings:

PCONS settings ( ICU on the left and BBU on the right)

Microsoft Word

Document




Notice that with a PCONS you can take control of the xCEM when BIST starts

4.2. …CONNECT TO THE XCEM FROM THE MASTER BOARD

4.2.1 FROM XCCM BOARDS

Start BCI and type:

> pltf/msg/DBTable

DBTable gives the internal IP address (PQ2 one) of the xCEM board.

Exit BCI and from the xCCM open a Telnet session on the slave with its IP address:

> exit

xCCM-root-/> telnet 192.168.13. 1 (for instance)

this will allow xCCM to access PQ2 XCEM processor

From the xcem board, type rtc>ip>dis to return to the xCCM

To access PQ3 xCEM Processor (BBU), replace ”.1” with “.2” in the PQ2 address indicated in the DBTable.

4.2.2 FROM (I)CCM BOARDS

Check the logical slot number of the xCEM board from the (i)CCM menu:

>emo>bts or

>RT>FLR>DWL>PCRMS

Then go to following (i)CCM menu to connect to the xCEM board:

>RT>ip>con “XCEM slot”

this will allow xCCM to access PQ2 XCEM processor

From the xcem board, type rtc>ip>dis to return to the xCCM

To access PQ3 xCEM Processor (BBU) add “space bar”+”2” to the same command

4.3. …TRANSFER FILES FROM / TO THE XCEM

You can transfer files from/to the xCEM board by opening a FTP client (no Login nor password required) on the xCEM ICU (PQ2) IP address (external Debug address).

The transfer must be done in bin mode.

After transferring, enter “bye” to quit.




4.4. …RUN RTC TOOLS

Open a Telnet/Pcons session on the xCEM and type RT to enter RTC menu:

For command list, please refer to [R5]

4.5. …DISABLE / ENABLE THE LOADER

The Loader is enabled by default.

To disable it, enter RTC menu and type:

>RTC/mim/mrw 302 3

Then, reset the board.

To re-enable the loader type:

>RTC/mim/mrw 302 0

Then, reset the board once again.

4.6. …ACTIVE PARTITION PROTECTION BYPASS

The active partition (/active)is in the nominal way protected for writing also for root user, so In order to bypass this protection a command is existing. As it can be dangerous to have this partition writable it is not consider as normal to work with this mode. Before, you may have to know which partition is the active one.

if active partition is ffs0, command to change active partition writable is under RTC prompt : >RTC/mim/mfw 3 0

after making change in the active partition reset the board




4.7. INSTALL A NEW XCEM SOFTWARE

4.7.1 TO INACTIVE FFS

Downloading SW to inactive FFS Comment 1 Telnet IP@ board 2 RTC>FM>P (print) display FFS and choose FFS not enable then 3 RTC>MIM>MRW 302 3 disabling the board loader then 4 FTP @IP board run ftp from directory where binary files are located 5 login: � no login 6 pwd: � no password 7 ftp> bin � binary mode chosen for binary files transfer 8 ftp> cd /ffs0 or cd /ffs1 according to line #2 9 ftp> ls or dir � display binary files already in

10 ftp> prompt �

allow all files downloading upfront from the current directory location without any file checking

11 ftp> mput * �

run all files transfer to the target in one shot (20 files are to be downloaded into xCEM )

12 � to select the files to be transfered, skip line command #10

13 � then type mput * � and y or n � 14 � or mput "file name" � and y or n �

15 ftp> dir �

listing files transfered to the target, � check length & marking

16 ftp>cd /bootl2_0 or cd /bootl2_0 according to line #2 17 ftp>mput "bootl2 binary file name" � 18 ftp> bye �

19 Telnet IP@ board

20 RTC>FM>P (print)

to check if inactive FFS is valid or not and also if "next to boot" is enabled

21 RTC>FM>valid "inactive ffs"

to be done, depending on cmd line #20 outcome, enable '"valid"

22 RTC>FM>a "inactive ffs"

to be done, depending on cmd line #20 outcome, enable "next to boot"

23 RTC>OS>RESET board reset and restart on former inactive FFS




4.7.2 TO ACTIVE FFS

This operation is quite tricky and needs to be handled carefully. An issue may leads not to recover the board after resetting.

Downloading SW to active FFS Comment 1 Telnet IP@ board

2 RTC>FM>P (print) display FFS and choose FFS not enable

then

3 RTC>MIM>MRW 302 3 disabling the board loader

4 RTC>MIM>MFW 3 0 allowing writing in active FFS

5 FTP @IP board run ftp from directory where binary files are

located 6 login: � no login

7 pwd: � no password

8 ftp> bin � binary mode chosen for binary files transfer

9 ftp> cd /ffs0 or cd /ffs1 according to line #2

10 ftp> ls or dir � display binary files already in

11 ftp> prompt � allow all files downloading upfront from the current

directory location without any file checking

12 ftp> mput * � run all files transfer to the target in one shot (20

files are to be downloaded into xCEM )

13 � to select the files to be transfered, skip line command #10

14 � then type mput * � and y or n �

15 � or mput "file name" � and y or n �

16 ftp> dir � listing files transfered to the target, � check

length & marking

17 ftp>cd /bootl2_0 or cd /bootl2_0 according to line #2

18 ftp>mput "bootl2 binary file name" �

19 ftp> bye �

20 RTC>OS>RESET board reset and restart on former inactive FFS

4.8. …GET THE XCEM SOFTWARE MARKING

First, check the active partition:

Welcome to XCEM board

History management activated (ESC+h for Help)

XCEM-RTC_TOOLS>fm

XCEM-RTC_TOOLS/FM>p

Flash File System State ...

Flash 0 (/ffs0)

Valid : YES




Current : NO

Probed : YES

Next To Boot: NO

FlashType : UMTS

File System : EFS

Flash 1 (/ffs1)

Valid : YES

Current : YES � FFS1 is the current active partition

Probed : NO

Next To Boot: YES

FlashType : UMTS

File System : EFS

Flash 3 (/data)

Valid : NO

Current : NO

Probed : NO

Next To Boot: NO

FlashType : UMTS

File System : EFS

Then to display markings, go to:

XCEM-RTC_TOOLS/FIMA>PLM -ffs1 (or ffs0 for the other partition)

File name : /ffs1/bistsxcempq2.bists.fbin

PL number 1 : BISTXCEMPQ2 V00A02 E03 21/0 2/2008

15:07:30

File name : /ffs1/bootl2xcem.fbin

PL number 2 : MB_BOOTL2XCEM V05_01 E09 18/1 0/2007

19:16:27

File name : /ffs1/bootl3xcem.fbin.zl

PL number 3 : MB_BOOTAUTOL3_XCEM 060006 E59 2/0 7/2008

12:42:39

File name : /ffs1/cectl.mod

File name : /ffs1/cectl.vx

File name : /ffs1/cectlcfpg.gz

File name : /ffs1/cectlcfpgP0.gz �useless for xCEM256 (used by old xcem128)

File name : /ffs1/cectldspa.gz




File name : /ffs1/cectlespc.gz

File name : /ffs1/cectlespd.gz

File name : /ffs1/cectlfpga.gz

File name : /ffs1/cectlfpgb.gz

File name : /ffs1/cectlfpgc.gz

File name : /ffs1/cectlocbs.gz

File name : /ffs1/cectloccc.gz

File name : /ffs1/cectloccd.gz

File name : /ffs1/cectlpackage.txt

File name : /ffs1/uc_CallP_xcem.fbin.zl

PL number 4 : CALLP_UC 060006 E59 2/0 7/2008

12:41:26

File name : /ffs1/uc_Dwl_xcem.fbin.zl

PL number 5 : DWL_UC 060006 E59 2/0 7/2008

12:41:56

File name : /ffs1/xcem_cmdfile

4.9. …CHECK THE XCEM HWREF

To check the hardware reference go to the following RTC menu:

XCEM-RTC_TOOLS/MIM>mrr 101

BE CAREFUL FOR THIS RECORD!!

KEEP IN MIND THAT THE TYPE AND SUBTYPE ARE CODED IN 2 BYTES

AND DEFINED AS FOLLOWING:

TYPE SUBTYPE BYTE 1 & BYTE 2 (16 bits) with

type = bits MSB 15-4 and subtype = bits LSB 3-0 !!

FRU type : (type subtype byte 1) 0x5

FRU subtype : (type subtype byte 2) 0x60

FRU application : 0x2

So the HWREF of the xCEM256 must be 0x560

If it is not the case , you may change it this way:

XCEM-RTC_TOOLS/MIM>mrw 101 � enable to write the HWREF









FRU type : (type subtype byte 1) 0x6

New value > 0x5

FRU subtype : (type subtype byte 2) 0x5

New value > 0x60


New value >

Reading back






FRU type : (type subtype byte 1) 0x 5

FRU subtype : (type subtype byte 2) 0x 60


4.10. …GET / SET THE IP ADDRESS (TEMPORARY)

4.10.1 GETTING THE ICU IP ADDRESS

To get the IP address of the board, open a Telnet/Pcons session on the xCEM (from CCM) and type:

XCEM-RTC_TOOLS/ETH>sh

Ethernet driver Statistics (pEthCtrl : 0x07497fa4) :

Ethernet is "tsec0" on TSEC0

Flash IP address: 135.120.152.183 Stac k IP

address: 135.120.152.183

Flash IP mask : 255.255.0.0 Stack IP mask :

255.255.0.0

Ethernet(MAC) address : 00:60:1d:94:7d:40

This address is the IP address of the ICU (PQ2)




4.10.2 SETTING THE ICU IP ADDRESS (TEMPORARY)

To set the IP address of the board, , open a Telnet/Pcons session on the xCEM (from CCM) and type:

From the previous example, type:

XCEM-RTC_TOOLS/ETH>IPset

IP address > 135.120.152.184

Reading back, you should get:

XCEM-RTC_TOOLS/ETH>sh

Ethernet driver Statistics (pEthCtrl : 0x07497fa4) :

Ethernet is "tsec0" on TSEC0

Flash IP address: 135.120.152.183 Stac k IP

address: 135.120.152.184

Flash IP mask : 255.255.0.0 Stack IP mask :

255.255.0.0

Ethernet(MAC) address : 00:60:1d:94:7d:40

This is a temporary address that will be lost after the next reset .

4.11. …SET THE ICU IP ADDRESS (PERMANENTLY)

Way of modifying the debug IP address (ICU – PQ2) or subnet mask of the BTS is given by the RTC menu:

4.11.1 MODIFYING THE ICU IP ADDRESS (PQ2)

From a CCM telnet, connect to the xCEM board as described in chapter 4.2. Then, follow the procedure below:

On xCEM board go to RTC menu; ETH submenu Nwc by typing the command as follow:

XCEM-RTC_TOOLS/ETH>NW

Here under information displayed consequently

The current configuration (1) in MIM is :

Subnet mask : 255.255.000.000

Ethernet address : 00:60:1D:94:7D:40

IP address : 135.120.152.183

The current configuration in flash is :




Subnet mask : 255.255.000.000

Ethernet address : 00:60:1D:94:7D:40

IP address : 135.120.152.183

Which source configuration do you want to use ? (default MIM

configuration 1)

1) MIM Network Conf1.

2) MIM Network Conf2 (CCM or iCCM only).

3) Flash Network.

4) Copy between devices.

5) Quit.

Your choice [1/2/3/4/5] >

� Enter “1”

Change IP address: yes

IP address : www.xxx.yyy.zzz �� enter the expected address

Change EThernet address: no

Change Subnet mask address: yes

Subnet mask address: 255.255.0.0

Change Network Configuration in: 1 (MIM Network Conf1.)

The IP address is now update within the MIM, second step consists in updating the flash memory accordingly.

XCEM-RTC_TOOLS/ETH>NW

Which source configuration do you want to use ? (default MIM

configuration 1)

1) MIM Network Conf1.

2) MIM Network Conf2 (CCM or iCCM only).

3) Flash Network.

4) Copy between devices.

5) Quit.

Your choice [1/2/3/4/5] >

� Enter “4”

� Enter “1” (MIM Network Conf1.)

� Enter “3“ (Flash)




Then disconnect the xCEM from the CCM and try a connection upfront to the faceplate (ICU connector)

4.11.2 MODIFYING THE SUBNET MASK (ICU)

Way of proceeding is the same than the way of changing the IP address (4.11.1) but the mask is to be changed instead of the IP address.

4.12. …SET THE BBU IP ADDRESS (PERMANENTLY)

Why setting an IP address on BBU area can be useful? Having an IP address on BBU part enable you to capture CE control traces needed for the investigation purpose as well as getting PQ3 crash records too.

Set an IP address, you first need to access to the PQ3 SW console (in ethernet mode, serial mode is too slow). For setting the Ethernet interface, you need to change the bootline and reboot. To proceed, you need a serial link connection to PQ3 SW console from xCEM front panel. (for Hyper Terminal setting refers to chapter 4.1)

Once, the connection is open, change parameters as follow (in red font below)

CECTL1-1-> bootChange

'.' = clear field; '-' = go to previous field; ^D = quit

boot device : ram0

processor number : 0

host name :

file name : /ram0/BNJ103

inet on ethernet (e) : 172.18.223.46:ffff0000 # IP address and mask

inet on backplane (b):

host inet (h) : 172.18.255.121 # host IP for remote FS access (optional)

gateway inet (g) : enter the gateway IP address

user (u) : user

ftp password (pw) (blank = use rsh): password

flags (f) : 0x8

target name (tn) :

startup script (s) : /ram0/cectl_debug.txt

other (o) :

Global Lab Flag : 0x81

Local Lab Flag : 0x81




Then, reboot the PQ3 SW with >reboot, you are now in a position to open an Ethernet connection on the PQ3. As a reminder, you can also access to PQ3 via xCCM or legacy CCM (refers to chapter 4.2)

4.13. …RESET THE BOARD

RTC menu is available to reset the xCEM board at prompt ‘>’ of RTC menu type command: > os/reset

4.14. …SWAP ACTIVE/PASSIVE PARTITIONS

You must first disable the loader in order to prevent downloading any unexpected SW from the CCM board.

In the RTC menu prompt ‘>’ type command below to display the FFS state > FM/P

then, enter

> FM/act “passive ffs”

then reboot the BTS using the command > RTC/os/reset.

To check that the active was changed after rebooting, use command RTC>FM>P

4.15. …GET EEC LOGS

The EEC (Enhanced Error Collector) provides useful services:

• Fatal error and reboot,

• Memory supervision,

• CPU load supervision,

• User data collection for debug,

• Session user data archiving,

• User data decoding,

• Traceback decoding tool.

The EEC is a “snapshot” of the data, states, frames stacks,…of an application or a part of it. This is a DEBUG tool, and NOT a trace tool.

3 last trap events can be saved.

RTC>EEC>

You can display the last trap reason or the full log depending on the command line you will enter. Type “h”, to display the list of commands available.




Remark: EEC logs are dumped in the IMT during the IMT generation.

4.16. …GET THE IMT

The full IMT is launch from a XCCM or legacy CCM telnet session. However you may collect IMT for xCEM only.

First of all, open a telnet session on the xCEM, then

When prompting:

Enter $$$ to get the menu >

Type “imt ”, then “zap”, and set parameters below:

XCEM-IMT_MAIN/ZAP> SetDomain DOMAIN_ALL

XCEM-IMT_MAIN/ZAP> SetLevel LEVEL_ALL

XCEM-IMT_MAIN/ZAP> ShowSetValues

Then

XCEM-IMT_MAIN/ZAP>get. The IMT now gathers all xCEM info (FLR, EEC etc…)

4.17. …ENABLE / DISABLE SOME TRACES

4.17.1 TRACES REDIRECTION ON THE CONSOLE

By default the output of configured and default traces is a circular buffer. Here is a way to redirect traces to the telnet console, syntax is as follow under RTC ‘>’ prompt:

> rtc/flr/output 0 3

> rtc /flr/output 1 0



All these commands can be put in the dialog_appli file in order to be automatically executed at startup of the board.

4.17.2 PQ2 (ICU) – MCTL TRACING / DEBUGGING

XCEM RTC menu is similar to CEM legacy one

Start RTC and type:

> trace

The lf command gives the trace list:

1: OAM STARTUP

3: OAM GENERIC




4: OAM SPECIFIC

5: FPGA ALARMS

10: UBM_UCU

11: UBM_BASE

12: UBM_CCC

13: UBM_DCC

14: UBM_NBAP

15: UBM_PM

16: UBM_CP

17: UBM_OAM

21: Dwl

27: Data Link & Physical Layer

28: Protocols

29: Services

30: File System

31: Drivers

To activate the NbapManager (14) traces (for example) type:

/traces>act 14

To disable a trace, use the des command:

/traces>des 14

Once activated, you must also actibvate sub mask of the function

/traces>act 14

The list of mask available for every functionis achievable by typing lm command and function number:

XCEM-RTC_TOOLS/TRACES>lm

Enter FctNB >14

Mask used for function 14:

1: NBAPR

2: NBAP_C1MSG

3: NBAP_C2MSG

4: NBAP_CHECK

As a reminder, here below the useful commands to be used for XCEM investigation purpose:




ITF1/2/4 tracing

MCTL tracing provides hexdumps of all messages received on ITF1/2/4 stored in its own FLR

Currently needs to be activated via RTC TRACE menu:

RTC TRACE ACT 31

RTC TRACE CM 31 7

RTC TRACE CT 31 153

By default trace output is written to RAM FLR only. To activate console output use RTC

FLR OUT 0 3

CALLP trace functions

RTC/TRACE/LF

12: UBM_CCC

13: UBM_DCC

14: UBM_NBAP

15: UBM_PM

16: UBM_CP

17: UBM_OAM

Trace functions are activated via

RTC TRACE ACT xxx

where xxx is the function number

Additionally the trace mask and trace number needs to be activated

CALLP CCC traces

CCC is the common channel controller of CALLP

All cell and common channel procedures are handled by this subsystem

RTC/TRACE/LM 12

1: CCC_CC

2: CCC_CELL

4: CCC_PSB

5: CCC_SCCPCH

6: CCC_PRACH

8: CCC_HSDPA

9: CCC_HSUPA

10: CCC_RSSI

Trace masks are activated via RTC TRACE CM 12 xxx where xxx is the mask number

Trace numbers need to be activated, too.

RTC TRACE CT 12 64+12*xxx+3 for info level

RTC TRACE CT 12 64+12*xxx+4 for debug level

CCC_CC: general output for cell related procedures

CCC_CELL: general output for CELL specific procedures




CCC_PSB: detailed output for cell setup and system information update procedures

CCC_SCCPCH: detailed output for FACH part of common transport channel setup procedures

CCC_PRACH: detailed output for RACH part of common transport channel procedures

CCC_HSDPA: detailed output for HSDPA PSCR procedure

CCC_HSUPA: detailed output HSUPA PSCR procedure

CCC_RSSI: detailed output TRM_RSSI processing

CALLP DCC traces

DCC is the dedicated channel controller of CALLP

All dedicated channel procedures are handled by this subsystem (R99 and HSxPA)

RTC/TRACE/LM 13

1: DCC_CTR

2: DCC_UCX

3: DCC_BID

4: DCC_RLS

5: DCC_HSD

6: DCC_HSU

7: DCC_SRV

Trace masks are activated via RTC TRACE CM 13 xxx where xxx is the mask number




DCC_CTR: t.b.d

DCC_UCX: UE context related output

DCC_BID: binding tables (transport bearer) related output

DCC_RLS: radio link set related output

DCC_HSD: HSDPA related output

DCC_HSU: HSUPA related output

DCC_SRV: output common used services in DCC

NBAP Router

NBAP router is the central point for sending/receiving messages on ITF1 and ITF2

Provides decoded message output for ITF1 and ITF2

RTC/TRACE/LM 14

1: NBAPR

2: NBAP_C1MSG

3: NBAP_C2MSG

4: NBAP_CHECK




Trace masks are activated via

RTC TRACE CM 14 xxx

where xxx is the mask number




NBAPR: short output on message types received and sent

NBAP_C1MSG: decoded output of all transaction oriented NBAP messages (most messages are transaction oriented)

NBAP_C2MSG: decoded output of all transaction less NBAP messages, e.g. Audit, measurement reports,…

NBAP_CHECK: useful if decoding of any message fails. NBAP router checks all messages for correctness as defined in NBAP specification (semantic and conditional checks).

Iub Connection Manager

Manages setup and teardown of AAL2 channels

RTC/TRACE/LM 16

4: IUBCM

Trace masks are activated via

RTC TRACE CM 16 xxx


Trace numbers need to be activated, too. RTC TRACE CT 16 64+12*xxx+3 for info level


Helpful in case of problems with AAL2 channel setup

OAM Abstraction Layer (OAL)

OAL is the counterpart of SLOAM on ITF4; it provides OAM framework for NBAP-d

RTC/TRACE/LM 17

1: AO_MCTL

2: AO_CECTL

3: AO_CELL

Trace masks are activated via RTC TRACE CM 17 xxx


Trace numbers need to be activated, too. RTC TRACE CT 17 64+12*xxx+3 for info level


AO_MCTL: decoded output of all messages sent and received on ITF4

AO_CECTL: manages the CECTL on OAM level (CECTL state, CE states, CECTL alarms), provides OAM parameters to CECTL




AO_CELL: provides logical cell related OAM parameter for NBAP-d

CALLP menu

CALLP provides a submenu in RTC menu for printing internal information

Not a standard RTC menu yet. Refers to Annex for details

RTC/CALLP

The Root Menu

-------------

1) CBC Controller Menu

2) ABS Menu

3) Callprocessing UDCs

q) Exit this menu

CCC Information/Cell Hich Code Information

a. CCC information

Dumps which local cells are configured

Dumps the scheduler mode

Dumps HSDPA and HSUPA MIM parameters for all cells

b. Cell Hich Code Information

Dump the HSUPA HICH codes allocated for a cell

Cell Information

Dumps cell specific information like:

– Parameters from cell setup

– BTS delay calibration data

– Basic common transport channel configuration

– Basic physical shared channel configuration

Cell System Information

Dumps system information specific data

For each system information blocks the type, repetition, segment type, segment position and raw data is dumped

Resulting segment combination and scheduling table is also printed

4.17.3 PQ3 (BBU) – CECTL/CECTL L1TRACING

4.17.3.1 CECTL L1 TRACING

CE driver provides a set of commands for controlling the trace output

.ceHelp‘ gives an overview of supported trace units and commands:




ubm_TRACE_CE_STATE 69/off for CE driver itself in u plink &

downlink

ubm_TRACE_OC_CE_UL_CTRL 194/off (-1) for OC contro l stuff in uplink

ubm_TRACE_OC_CE_DL_CTRL 209/off (-1) for OC contro l stuff in

downlink

ubm_TRACE_OC_CE_UL_TRFC 193/off (-1) for OC payloa d stuff in uplink

ubm_TRACE_OC_CE_DL_TRFC 208/off (-1) for OC payloa d stuff in

downlink

ubm_TRACE_OC_CE_I_WANT 195/off (-1) for OC I want requests in

uplink

ubm_TRACE_OC_CE_TX_ACK 196/off (-1) for OC acknowl edged downlink

(ctrl & traffic) stuff in uplink

ubm_TRACE_OC_CE_EVENT 197/off (-1) for OC & OC+ eve nts uplink

ubm_TRACE_OCP_CE_UL_CTRL 210/off (-1) for HSDPA con trol stuff in

uplink

ubm_TRACE_OCP_CE_DL_CTRL 211/off (-1) for HSDPA c ontrol stuff in

downlink

ubm_TRACE_OCP_CE_ACK_NACK 214/off (-1) for HSDPA a ck/nack in uplink

ubm_TRACE_OCP_CE_CQI 213/off (-1) for HSDPA c qi in uplink

ubm_TRACE_OCP_CE_DL_TRIG 212/off (-1) for HSDPA d l-trigger in uplink

ubm_TRACE_OCP_CE_DL_TRFC 215/off (-1) for HSDPA p ayload in downlink

ubm_TRACE_OCP_CE_UL_TRFC 238/off (-1) for E-DCH p ayload in uplink

ubm_TRACE_OCP_CE_UL_DPCCH 239/off (-1) for E-DCH c ontrol in uplink

ubm_TRACE_OCP_CE_UL_DPDCH 240/off (-1) for E-DCH c ontrol in uplink

ubm_TRACE_OCP_CE_UL_EC_IO 284/off (-1) for E-DCH E c/Io in uplink

ubm_TRACE_OCP_CE_UL_TXPOW 285/off (-1) for E-DCH T c power ctrl in

uplink

ubm_TRACE_OCP_CE_UL_PBRMR 287/off (-1) for E-DCH P rovided Bit Rate

Measurement Report

ubm_TRACE_OCP_CE_DL_AGCH 242/off (-1) for E-DCH c ontrol in downlink

ubm_TRACE_OCP_CE_DL_RGCH 243/off (-1) for E-DCH c ontrol in downlink

ceTraceOn/ceTraceOff turns on/off tracing for a trace unit

‚ceTraceCnt unit,cnt‘ allows tracing of ‚cnt‘ messages for this unit

‚ce_ctrlTraceOff msgId‘ turns off tracing for a specific OC message type

‚ce_ctrlTraceOn msgId‘ turns on tracing for a specific OC message type

‚ce_ctrlTraceOnAllOn()‘ reenables tracing for all OC message types




4.17.3.2 CECTL TRACING/DEBUGGING

Tracing control on CECTL is different to MCTL. Control via menus is available, but usually command line is used.

4 levels of trace output are defined: ERROR, WARNING, INFO and DEBUG.

By default errors and warnings are forwarded to MCTL and stored in FLR

INFO and DEBUG level can be switched on to log to the serial console or telnet session

Forwarding of INFO and DEBUG level trace to MCTL is also supported (will be stored in PSG trace FLR)

Command ubm_TLShow on CECTL console displays a list of all trace units available

Trace units are identified by numbers. Most important trace units are:

48: UCU_RM

50: UCU_MGR

51: UCU_CDL

52: UCU_COMMON

53: UCU_DCH

55: UCU_PSB

56: UCU_RACH

65: UCU_FP

146: UCU_HSDPA

148: UCU_HSD

244: UCU_HSUPA

245: UCU_HSU

Command ‚ubm_modify_trace 0,unit,level‘ (unit is the trace unit, level is 3 for INFO, 4 for DEBUG) is used for switching on traces‚ ubm_modify_trace 0,unit,2‘ switches off tracing

UCU manager is a central objects for CECTL. It loads the CEs, routes messages to BBRs from CALLP and CE …

UCU_RM, UCU_MGR and UCU_COMMON trace units control tracing for this unit. You should always turn this on

Use ‚cpif_hex_trace=0‘ to turn off CPIF message hexdumps

Basic debug commands :

ucuHsTracesOn 1 to log msg bet L1 and PQ3

aalShow 1 ‘ prints ATM channel configuration data and ATM channel statistics (aalShowStats on older loads, no configuration data available on older loads)

ucuMgrDump ‘ dumps ucuManager related data like CE configuration state and existing BBRs

cellDump ‘ prints cell related configuration data on CECTL

ucuHelp ‘ provides an overview about debug commands on CECTL (not complete)




showcectlao ‘ dumps CECTL relevant OAM parameters. CECTLAO is the counterpart of AO-CECTL on CECTL and provides similar information as the AO-CECTL menu on MCTL

hsSchedHelp ‘ dumps an overview about HS scheduler debug commands

hsSchedData n ‘ dumps global parameters used by HS scheduler like cellIndex, cpich power, t_cell, max_tx_power …‚n ‘ goes from 0 to 5 and defines the scheduler instance

hsSchedCeInfo n ‘ dump CE info and SCCH code info for HS scheduler ‚n‘

hsSchedMib n ‘ dumps OAM parameters used by HS scheduler ‚n

Debug information on FP level is available on CECTL via the fpDump ‘ command;

fpDumpHelp ‘ gives an overview about available debug output. FP statistics are helpful for analyzing problems on FP level

CECTL1-1-> fpDumpHelp

List of all R99 downlink statistics: 5

List of all R99 uplink statistics: 6

List of all HSDPA statistics: 8

List of all EDCH statistics: 12

FP statistics show information about channel type, control/data frames received or sent, frames received too early/late, CRC errors, etc…

4.17.4 DECODING CECTL TRACES

This chapter will help in understanding severity of issue, which part of L1 is concerned, and the description of the error code

If a CE trap occurred, then you should find the string 'handleCeFailure() ', and the cause (TIMEOUT, RESP_STATUS, STATUS IND). The lines just before this contain details on the cause.

Example:

WARNING DchBbr(0x116e040,RNTI=0): rxCeRlDeletionRes pNormal(): OC status=UCUC_CE_CC_NOT_READY,

msg=0xe, ucu_cc_id=0x36

WARNING *** UBM WARNING *** File:/vobs/ubtssw_ucu/u cu3/control/callprocess/cectl/src/DchBbr.cc

line:1059 ***

WARNING CeMgrOc(0x1b88b68): handleCeFailure(): ce_id=1; cause=STATUS RESP

In this example, a CE trap was caused because CE 1 (a OneChip device) replied with failed status UCUC_CE_CC_NOT_READY to a RlDeletion request.

If you are not looking for a CE trap, then search for the string 'sev '(for Severity)

Example:

2008-05-23 05:31:44:660 47A786B1 WAR: 000 21:02:2 3, UCU8 [05-23 05:31:44Z] 0x744f44 UCU_CP

: 1122 !W WARNING UcuMgr(0x1241ed0,RN TI=0): handleCeErrorReport(): ce=3:

ce_id=3, sev=0x1, type=0x2217, sfn=0xcc, event=0x0, occ=0x1

ce_id=3 �� OC #3 sev=0x1 �� Call fatal type=0x2217 �� error code




Severity definition table

CE_id definition table

Error code definition

For error meaning, please refer to OneChip and OneChip plus message catalog here below

OneChip message catalog

OneChip Plus message catalog (it may appear with a .dll extension, note that you get .zip files, so rename it as *.zip)

5. WHAT LOGS TO ATTACH TO A CR?

Information provided below may help whenever there are no obvious traces to be logged from the user point of view.

5.1. NO CLUE ABOUT TRACES TO BE PROVIDED?

If ever you have no idea/clue about which part of the SW application involved in the issue, you will find here after the log package description to provide within a new CR:

IMT log via CCM or xCCM

On xCEM:

- FLR 0 to 4 (cmd : all)

Severity (sev)

CE fatal 0

Call fatal 1

Warning 2

E-DCH fatal (OneChip Plus only) 3

CE or E-DCH fatal (OneChip Plus only) 4

CE_id

OneChip #0 (ASIC OC) 0

OneChip #1 1

OneChip #2 2

OneChip #3 3

OneChip plus (DSP + FPGAs) 4




- FLR 7 (cmd D 7 1000000)

- FLR 8 (cmd: D 7 1000000)

- PQ3 crash record (connection to PQ3 mandatory either by CCM or Ethernet port): “crDump 1000”

5.2. SPECIFIC TRACES TO BE LOGGED ON XCEM (BASICS)

5.2.1 DWL ISSUE

RTC_TOOLS/FLR>d 4 (Included in package §5.2.2)

Trace 21: DWL

5.2.2 SLOAM ISSUE

1: OAM STARTUP

3: OAM GENERIC

4: OAM SPECIFIC

5.2.3 NBAP CHECKS OUTPUT BY CALLP

ACT 14 CM 14 1 CM 14 4 CT 14 79 CT 14 80 CT 14 115 CT 14 116

5.2.4 CE RELATED ISSUES WITH XCEM

PQ SW <-> CE logs are needed to start most investigations.

5.2.4.1 ONECHIP UL/DL CONTROL MESSAGES

You must activate CE trace before establishing the call with:

ceTraceOn 194 ceTraceOn 209

6. CELL DIAGNOSTIC MONITOR

Since the xCEM architecture is inherited from exLucent UCU board, Visual BBS and DSPTool cannot be used with xCEM board. Another tool is to be used then: The Cell Diagnostic Monitor (CDM)

The CDM consists of measurement probes on the UMTS Node B, and software running on a dedicated Personal Computer (CDM-PC).

The CDM provides the user with a real-time window into the operation of the Alcatel-Lucent Node B.




CDM is a tool that provides graphic real-time radio interface performance monitoring. It can be used to gather experience with and optimize the UMTS air interface and as input for simulations of new algorithms.

The CDM has the capability of displaying real-time plots and/or tables of average values describing the performance of the radio interface (input values as well as outcome of algorithms).

The performance of an air-interface connection to a selectable (test) UE can be evaluated with respect to:

– Uplink signal quality

– Uplink data throughput

– Inner and outer loop power control (uplink and downlink)

– Transmit power

– Rake finger data

– HSDPA performance

– HSUPA performance

It is possible for the user to specify a specific UE to be traced. CDM can be used to trace up to two calls per Node B simultaneously with no relation to sectors or carriers. While CDM is active the normal operation of the Node B is not significantly influenced, i.e. normal call processing as well OCNS users may be active at the same time but CP delays will be increased due to the additional messages in the system. The RF situation in each of the sectors of the Node B can be evaluated by monitoring:

– Received total wideband power

– Transmitted carrier power

– Aggregate overload control

Performance data is logged by the CDM in binary format. The CDM provides a file browser to convert the binary file into ASCII format so that complex post processing of the data can be performed for diagnostic and test purposes using external post processing and data analysis tools. This would also include the correlation with Uu information collected by a test UE.

The CDM also provides a playback functionality of binary log files for off-line data visualization and analysis

6.1. CDM VERSION USAGE

Pay attention to the fact that CDM is strongly dependant on the XCEM module SW. this means that any CDM tool version is not compatible to anyone of the xCEM version. Take care to check if the version you plan to use is compatible with the xCEM SW version. To do so, please got to the following link:

http://sdc.de.lucent.com/

Enter “cdm” on the top left box on the webpage and click on “GO” to reach the CDM web page server (see below)




Then CDM server will open

Short info

This column indicates the xCEM version matching the CDMx version in the previous column “Load name”.

Warning: “higher” doesn’t mean the next xCEM version to come will be compatible. it depends how deep the new code will be change (ie: new radio feature, new interface…). However, we consider by default, there will be only minor change to come. This is the reason why the CDM version is supposed to be compatible with the current xCEM version and higher

Image file

To get the CDM tool software (SDC account is mandatory)

Docu:

To get the CDM release letter (SDC account is mandatory)

6.2. USING CDM TOOL

6.2.1 CONNECTING TO XCEM

There are two way of connecting to xCEM: Either upfront to the xCEM front panel (ICU port) with Ethernet connection or thru the CCM board.

6.2.2 LAUNCHING CDM TOOL

You can first have a look to [R7] and also have some tips here below.

Launch CDM, the window here below is then displayed:




Click on “SetUp”,� Connections_traces

Click on “new” here above

Then the following window is opening,

Enter a name for your xCEM,

Enter the IP address of the Target (XCEM or CCM if remote connection is selected)

Click on “OK”

Next step is the selection of the traces to be activated

To be checked for a connection thru the CCM board

Service category




For each Service category (displayed in the top right combo box), select the trace groups you may need to log. (Basically, select all trace groups per category)

Then click on “OK”




Now save your configuration on your PC as follow

The file extension will be *.cdm

Now you are in a position to launch traces logging by clicking on the “green traffic light” in the main CDM command bar.

A new window is opening. Just specify the output filename for your logs and click on “Start” button.




Now CDM is running and logging.

For further details please refer to [R7]

6.3. POST-PROCESSING CDM LOG

CDM output file is not in a readable format. To help analyzing this log file, a internal tool was developed: XCLA.

The XCLA input file format is a text file. So, first action is to convert the CDM *.log file into a *.txt file?

Open the CDM logfile tool as follow:

Then, in the next window, click on “Option” button and select all “call measurement” options, all “cell measurement” options, and all HSDPA call options.

Make sure “Time relive to first data” is selected too and click on “OK”,then to get the file in a txt format, click on the “Convert ”button to get it.

Now your CDM log can be post-processed using XCLA.

6.3.1 XCLA INSTALLATION

Since XCLA is a Python SW language-based tool. Make sure to get Python SW language installed on your PC.

Then Install XCLA from http://umts-eye/index.php under UIIV Radio France/xCEM Tools.

Unzip the package on your PC




6.3.2 LAUNCHING XCLA

To launch XCLA, just open XCLA.xls and enable macros

Path of Python executables must be the XCLA directory

Select all analysis you may want to (ie: R99, HSDPA, HSUPA, Cell meas….) and Click on “Launch” button.

A new window will open in order to browse and select the CDM file.txt to be post-processed.

Output file format is similar to “Pere Denis” tool one.




7. ABBREVIATIONS AND DEFINITIONS

7.1. ABBREVIATIONS

AAL2 ATM Adaptation Layer 2 (Data)

AAL5 ATM Adaptation Layer 5 (Sign)

BCI Base Command Interpreter

BBU Base Band Unit

BLER Block Error Rate

CCM Core & Control Module

CCP Communication Control Port

CEM Channel Element Module

CP Control Plane (signaling)

CQI Channel Quality Indicator (HSDPA)

CW Continuous Wave

DL Down Link

DLU See MIB

DPCCH Dedicated Physical Control Channel

DPCH Dedicated Physical Channel

DPDCH Dedicated Physical Data Channel

Fc UMTS Chip frequency = 3.84MHz

FRS Feature Requirements Specification

HSDPA High Speed Downlink Packet Access

HW Hardware

I&C Installation and Commissioning

IMA Inverse Multiplexing ATM

IMT iBTS Maintenance Toolkit

LEC Linux Error Collector

MIB Management Information Base (also called DLU)

MIM EEPROM located on a BTS board which stores all the permanent parameters of the board (ex: IP address, active Flash File System…).

NBAP Node-B Application Part

NFS Network File System

OC Asic OneChip

OC+ OneChip Plus made of one DSP and 3 FPGAs




OAM Operations, Administration, and Maintenance

OMCB Operation Maintenance Center – BTS

OS Operating System (ie: VxWorks, Linux)

RAB Radio Access Bearer

RF Radio Frequency

RRC Radio Resource Control

RSCP Received Signal Code Power

RSSI Received Signal Strength Indicator

RTWP Received Total Wideband Power (RSSI)

SHO Soft Handover

SRB Signalling Radio Bearer

STM-1 Synchronous Transport Module –1

SW Software

TIL Local Installation Terminal

UMTS Universal Mobile Telecommunications System

UTRAN Universal Terrestrial Radio Access Network

xCCM eXtended Core and Controller Module

xCEM eXtended Channel Element Module

7.2. DEFINITIONS




8. ANNEX: XCEM CALLP MENU DETAILS

RTC/CALLP The Root Menu ------------- 1) CBC Controller Menu 2) ABS Menu 3) Callprocessing UDCs q) Exit this menu

In ABS menu OAL data can be printed

Internal data for AO_CECTL, AO_MCTL and AO_CELL is available here

Press 2 on CALLP root menu to enter ABS menu ABS Menu

-------------

4) aAOCECtl

5) aAOCell

6) aAOMCtl

3) Callprocessing UDCs

q) Exit this menu

AO-CECTL maintains CECTL state/alarm and CECTL relevant OAM parameters

Menu allows to display BBU information, CE state information, cell delays AAL2 PVC configuration

Press 4 on ABS menu to enter AO-CECTL menu aAOCECtl

-------------

2) aAOCECtl-01

q) Exit this menu

aAOCECtl -01

-------------

4) show internal attributes

5) show pending fault list

q) Exit this menu

AO-CELL maintains logical cell specific OAM parameters like admin state, op state, MIM parameters, …

Press 5 on ABS menu to enter AO-CECTL menu aAOCELL

-------------




2) aAOCELL-01

3) aAOCELL-02

4) aAOCELL-03

q) Exit this menu

aAOCELL-01

-------------



q) Exit this menu

AO-MCTL maintains global OAM parameters like admin state, op state. Stores most of parametes available on ITF4

Press 6 on ABS menu to enter AO-CECTL menu aAOMCTL

-------------

2) aAOMCTL-01

q) Exit this menu

aAOMCTL-01

-------------



q) Exit this menu

In Callprocessing menu information about the different subsystems can be printed

CCC subsystem provides a lot of information on common channel, DCC statistics can be printed

Press 3 on CALLP root menu to enter Callprocessing menu Callprocessing UDCs

-------------

1) Dedicated Channel Control Menu

2) Show IUBCM internals

5) Common Channel Control Menu

q) Exit this menu

Most valuable info here is DCC statistics

Press 1 on Callprocessing UDCs menu to enter Dedidcated Channel Control menu Dedicated Channel Control Menu

-------------

3) Statistic Menu

q) Exit this menu

Statistic Menu

-------------

1) Initialize statistic

2) Trace statistic

q) Exit this menu




Press 2 on Callprocessing UDCs menu to display IUBCM internals

Information about CCC, Cells and System Information can be printed here

Press 5 on Callprocessing UDCs menu to enter Common Channel Control menu Common Channel Control Menu

-------------

1) Show CCC Information

2) Show Cell Information

3) Show Cell System Information

4) Show Cell Hich Code Information

7) Select Cell

q) Exit this menu

Use ‚Select Cell‘ menu to select the cell for which information will be displayed (for items 2, 3 and 4)

NBAP Interface allows switching off NBAP conditional checks.

Useful in case testing is blocked by an invalid encoded NBAP message (or a bug in the NBAP checks)

If NBAP checks are switched correct functionlaty is not guaranteed as vital information may be missing

Press 6 on Callprocessing UDCs menu to enter NBAP interface menu NBAP Interface menu

-------------

1) Conditional Checks [ON]

q) Exit this menu

Pressing 1 in NBAP interface menu toggles conditional checks state (on/off)

�� END OF DOCUMENT

x cem user guide

Documents

cd ffs1 ftp

alcatellucent written authorization

mim network conf1

mim network conf2

pq3 crash records

0x60 fru application

xcem quick start

file checking run