gpeh

GPEH 101?Iztok Saje

E-mail: [email protected], Kuala Lumpur, May 2008

Agenda

• offtopic (reflection from a year ago)• introduction• parsing GPEH• missing neighbors• what is going on?• RRC and NBAP• where are problems?• conclusion

Slovenija20 273 km2, 2 000 000 population.Slovene nation speaking Slovene language.North-West part of former Yugoslavia, now in EU (using Euro).Capital is Ljubljana with 300 000 inhabitants.Borders with Italy, Austria, Hungary and Croatia.

46.6 km of coast inAdriatic sea. 25 %of Slovenija is almostunpopulated (Alps,forests). Economy com-parable with Portugaland Greece.

Mobitel

Slovenija: 4 operators, 3 GSM networks, MVNOs

• we dominate with 70 % market share• BSS06B, UTRAN P5 (commercial since 2003)

Telekom Slovenija group:

• mobile in Gibraltar and Kosovo• some fix operators and ISPs in the region

Common LA

Already reported. Dual access and MSCs in pool.

• decrease in signaling (battery, CP load)• better paging due to less LAU/RAU• no overload in NE failure

Works fine, no problems with terminals

• One vendor does not support it

driver for layered core.

Introduction

Main UTRAN optimization:

• handover relations• antennas• pcpich, rest on default values

later:

• cell personalization• active use of RET (few times per day)

Data

STS is dead (just for main KPIs)

• we need correlated events• we need traces

But: once we have all data available

• it is too much• we do not see anything (again)

Statistics

A cell reports (via counters):

• one call in bad signal strength position• one failed handover from this cell• one dropped call

This is quite reasonable:

• bad SS call tried handover to save connection,• H/O failed and call was dropped.

and no action is needed.

Reality

This assumption may be completely wrong,there might be three different calls:

• bad SS was not bad enough to drop call• failed handover to good cell• dropped call in perfect radio conditions.

Which indicates we have to take some action.

• we can not learn from counters.

Especially with GPRS/EDGE/HSPA there is no way to haveenough counters

• so we need to take another path.

Event based data

Traditionally, statistics are based on counters

• some traces for debugging and test cases

Beside BSC/RNC:

• Protocol analyzer gives us IuB or Abis traces• it is fine if encryption is not there• we do not have BSC/RNC internal state

We capture all signaling in Core network

• but BSS/UTRAN is overkill

Separate box?

Why do we need protocol analyzers?

• IuB and Abis terminate on BSC or RNC

We need full tracing in the node itself

• together with internal node state.

Whole protocol analyzer industry is based on BSC/RNC ven-dors overlooking simple fact:

• processors today can handle it• Ethernet can handle it while X.25 used to be bottleneck

So, give me whole network trace! Ericsson did it.And we still need IuB protocol analyzer in rare cases.

GPEH

Optional feature - OSS is a must to activate

• select events (we take cca half of them)• select percentage of calls (we take them all)• select time (from morning till evening, every day)

Runs on every MP: one file each 15 minutes

• no harm: stops in overload, restart

A lot of work:

• adding cells, deleting cells

Viewing

There is decoder in OSS

• for small files only• very slow, not effective• not command line (last one in P1.5)

We use it just to test new releases

• and to write CSRs

Try it: like UETR and CTR

Parsing

Alex has very good description of GPEH file.

• easy to write own decoder, a lot of operators did it

Binary format: each record takes number of bits.One PC, two RNCs, 15 minutes of data processed in 3 minutes

• handover support files• drops• CE monitoring (we trace only one cell per Node-B)• full trace

Once per day: summaries, sorting of calls, indexing

RRC, NBAP

It can be activated:

• MO RncFunction, gpehDataLevel = 1

Direct asn.1 format, like on IuB

• Wireshark for NBAP• http://lionet.info/asn1c for RRC (faster)

Generates a lot of data, so we filter

Troubleshooting

With few weeks of complete traces we can do a lot:

• analyzing customer complains to details (TEMS Visualiza-tion)

• comparing TEMS data as seen from RNC• analyzing every dropped call in the cell

And, of course

• trying to correlate events beyond data offered by counters

(GSM example: SS/Q/TA correlation)With a single purpose - make network better!

• optimization of existing cells• learning about mistakes in planning

Analyzing dropsMuch more details as statistics:

061214 RNC11 RNC31 opisA-DCH REM 1 10 HS cell change after A-DCH removalGSM T CELLC 11 5 timer T cellcGSM T RELOC 43 46 timer T relocMEAS INTER 0 1 Measurement control failureO&M 0 30 cell lockRELCONOFF 7 23 ReleaseConnOffsetOther RLC 224 210 RLC-ostaloRLC retransmition 727 842 max RLC retr.RLC timer 1364 1195 lostRL other 181 162 RL failure, ni IuBSHO ADD 394 668SHO DEL 138 198SHO REPL 26 79UNSPECIFIED 2903 3216

Composite event

Everything we need:

• Who dropped (IMSI, we can link to IMEI via CDR)• RAB used (separate drops per RAB)• Where (cells in active set)

Why (reason)

• additional information (cells, GSM cell etc.)

And we can look previous events as well.

ReleaseConnOffset

There should be no drops due to undefined neighbors.Each time phone reports 1a event:

• detected cells (defined, but not in monitored list)• undefined cells (not defined)

First optimization step.

NeighborsWe use RRC traces for years (since P2.1)INTERNAL_SOHO_DS_MISSING_NEIGHBOURUE_CONTEXT 955 RNC_MODULE_ID 9 RNC31EVENT_TRIGGER EVENT_1CSCRAMBLING_CODE_CELL_1 373SCRAMBLING_CODE_CELL_2 42SCRAMBLING_CODE_CELL_3 1023CPICH_EC_NO_CELL_1 33CPICH_EC_NO_CELL_2 30CPICH_EC_NO_CELL_3 127RSCP_CELL_1 24RSCP_CELL_2 21RSCP_CELL_3 255SCRAMBLING_CODE_TRIGGER_CELL 0CPICH_EC_NO_TRIGGER_CELL 18RSCP_TRIGGER_CELL 16SCRAMBLING_CODE_ADDITIONAL_CELL1 1023CPICH_EC_NO_ADDITIONAL_CELL1 127RSCP_ADDITIONAL_CELL1 255

Postprocessing

We have CI in active set since P4.Decode missing cell from scrambling code (based on propercode planning).Take one report for call (we’ve seen 170 reports in one call).Add weight based on distance, signal strength.Limit is 31 neighbors: but this indicates antenna problems andmissing sites.

Three cell areasA: Cell is interfered by co-site cells. Easy to control.B: Cell is dominant. There is no interference. We only generateinterference.C: Cell is interfered by several interferers. Here is the action!

��

��

��

��

A

B

C C

CA

A

When terminal enters border regionwe get events: terminal sends RRCmeasurement report. Terminalssend them also when they wantchange in the Active Set.

Antennas

We want to

• minimize soft handover region• keep good handovers despite cell breathing• keep good coverage• take care of users in upper floors of the buildings.

based on RRC measurements, we look at RSCP/EcNo whennew cell is requested

• per relation just RSCP• cosited cells (strong signal, interference)• cells on site border

AKOTNI: cell in the city, good neighborsLMVRH: rural, highway

Graphs

All RRC measurements for specific events are taken.RSCP/EcIo values are counted for every cell.So, graphs show number of events reporting given RSCP/EcIo,thus giving indication of coverage (low RSCP) and quality (lowEcIo with good RSCP) on cell border.Too many graphs to look: warning for bad cells, KPI files.

Antenna downtiltBefore and after

Cosite events

Other cells

LMVRHB others

SHO RSCP

LMVRHB sho

AKOTNIC gsmWhere we make handovers to BSS?

based on last RRC measurement report with RSCP

But there is more:

Removal of unnecessary relations

• new cell never becomes strongest in active set• unnecessary third leg in SHO region

We are getting good input for antenna planning:

• excessive soft handover region• pilot pollution and bad overlapping• overshooting (far away neighbors reported)• unexpected coverage (not seen in prediction tool)

NBAP

Gives us round trip time at call setup (RACH).

• not available in standard GPEH events

We can analyze distance distribution per service

• calls are randomly distributed• IRAT CR on cell border (indoor)• LAU on LA border (and attach)

EcNo distribution is not Gaussian

• average is meaningless• we observe 25, 50, 75 percentiles

EcNo per serviceCell on LA border

Distance

OvershootingNo calls: removed from BSS BA-list far away

Positioning

Nothing for positioning based services, but essential data forUTRAN antenna optimization.

• GPEH, RRC, W–CDMA

We use GPS (W–CDMA)

• satellites with cesium clocks• RX measures time-difference of arrival (TDOA)• position is calculated• NPAP round trip time not used in this example

RRC eventsWe get measurement reports together with 1a/1b/1c . . . events

• tm: TDOA between two cells in chips (easy to measure)

cellSynchronisationInfo {modeSpecificInfo fdd : {

countC-SFN-Frame-difference {countC-SFN-High 0,off 5

},tm 6146 }},

modeSpecificInfo fdd : {primaryCPICH-Info {

primaryScramblingCode 44},cpich-Ec-N0 39,cpich-RSCP 30 }

SFN–SFN

2560 chips in a timeslot.We need only “tm” part if we look into sub-TS part only

• 512 selected, gives +/- 19 km.

tcell: 256 bits offset on cosited cells.

• we use tcell 0,2,4,6• can be compensated for odd tcell

SyncIf UTRAN Node–B are in sync (like IS–95), we can easily getlocation where two hyperbolas intersect.

• GPS uses three hyperbolas, but we are on the ground• Multilateration: where hyperbolas intersect?

3GPP: Location Measurement Unit, overkill

Software LMUWe have millions of RRC measurements.Those reporting 4 or more sites carry additional information.

• we can calculate offsets/delays between sites.

Data validationOnly RRC with 4 or more sites reported are taken.Errors in reporting:

• faulty terminals,• unstable first measurement after change: partly old, partly

new

Average tAB is good initial guess.

Coordinates

Gauss-Krueger is used, of course.Gauss made it for radio people:

• angles and distances are valid• gunners were first users.

One chip is 78 m long.We know locations of antennas.Based on initial guess, we take only DIFFERENT points.

Math 1

set of equations like: c =√

a2 + b2

We can not use linear methods (but there are ways for lineari-zation)One measurement with three sites: two eq, two unknowns (x,yof terminal)Three measurements with 4 sites each: 9 eq with 9 unknowns

• coordinates of terminals (3*2 unknowns)• delay for three sites (1*3)

We use more points (and they MUST be different)

• increased accuracy• a lot of math articles, not an easy problem

Math 2

Function loc error:

• one RRC, given location X,Y and delay for all sites• calculate sum of squared distance errors for all sites

Function where (Newton interpolation)

• guess RRC location where loc error is minimal

Functions to select site delay for 1 to 6 sites

• where sum of loc error for all points are minimal.

Start with initial site offset/delay from data validation.

Small case

6 selected sitesTake 50 different RRC measurements, each having at least 4 outof 6 sites.

• select reference site

check all possible offsets and seek minimum error:

• synchronized, we have 5 offsets.

Calculate again all points of interest.

• good to test formulas, GPEH parser etc.

Results

One day of GPEH recorded RRCs takenSoftware LMU works

• sub-chip accuracy (we use 1/10 of chip)• values stable for a week or more• we detected difference in co–sited cells with different cable

length

Node-B restart:

• based on stats: if all cells are down, recalculate delay again.

In sync

Once we know delays between Node-B:

• location of every valid RRC measurement report with at le-ast 3 sites is known.

• Kalman filtering on moving mobiles• multipath etc: wrong delays

Accuracy: 66 % in within 100 m error is good estimate.Also: RAB, RSCP, EcIo . . .

• drops with reasons• handovers to GSM• packet data speeds

Iztok

Top problem: +/- in long formulas

• case done manually for known locations

First positive results on small area

• Walking dog around my home (nicely located in pilot pol-lution area)

• Driving home from Chinese restaurant

Nothing done for almost a year (time)

Home arealocations: left lower point of name

Result

Future work

Just imagine: every call, every measurement report is located

• if three sites reported, but that is where we care

Sync whole LjubljanaFinish the work: get traffic maps for different RABs.

• antennas, indoor

Get more data with parameter changesOptimize antennas and power based on real measurements.

Literature:

3GPP specs to understand SFN–SFNTDOA positioning: a lot of articles, PhD (Finland, Spain), math:done for GPSSW LMU: basic math, solving of nonlinear multivariable equa-tions

• no articles found so far

As promised:

• Nothing for positioning based services, but essential datafor UTRAN antenna optimization.

Conclusion

GPEH gives full visibility of network

• perfect for automatic optimization• optimizers tune algorithms, not parameters• antennas and parameters can be tuned dynamically.

There are commercial tools, but:

• do we really understand what they do?

SW is not complex: it is huge amount of data.Thanks to Ericsson for not closing GPEH (like RTED).

Documents

gpeh