GPEH 101?

Iztok Saje E-mail: iztok.saje@mobitel.si EUGAP, Kuala Lumpur, May 2008

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

Slovenija
20 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 in Adriatic sea. 25 % of Slovenija is almost unpopulated (Alps, forests). Economy comparable with Portugal and 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 x 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 ne, 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 have enough 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 ne 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 vendors 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 le 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 les 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 le. 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 les 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 lter

Troubleshooting
With few weeks of complete traces we can do a lot: analyzing customer complains to details (TEMS Visualization) 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 drops
Much more details as statistics:
061214 A-DCH REM GSM T CELLC GSM T RELOC MEAS INTER O&M RELCONOFF Other RLC RLC retransmition RLC timer RL other SHO ADD SHO DEL SHO REPL UNSPECIFIED RNC11 1 11 43 0 0 7 224 727 1364 181 394 138 26 2903 RNC31 10 5 46 1 30 23 210 842 1195 162 668 198 79 3216 opis HS cell change after A-DCH removal timer T cellc timer T reloc Measurement control failure cell lock ReleaseConnOffset RLC-ostalo max RLC retr. lost RL failure, ni IuB

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 undened neighbors. Each time phone reports 1a event: detected cells (dened, but not in monitored list) undened cells (not dened) First optimization step.

Neighbors
We use RRC traces for years (since P2.1)
INTERNAL_SOHO_DS_MISSING_NEIGHBOUR UE_CONTEXT 955 RNC_MODULE_ID 9 RNC31 EVENT_TRIGGER EVENT_1C SCRAMBLING_CODE_CELL_1 373 SCRAMBLING_CODE_CELL_2 42 SCRAMBLING_CODE_CELL_3 1023 CPICH_EC_NO_CELL_1 33 CPICH_EC_NO_CELL_2 30 CPICH_EC_NO_CELL_3 127 RSCP_CELL_1 24 RSCP_CELL_2 21 RSCP_CELL_3 255 SCRAMBLING_CODE_TRIGGER_CELL 0 CPICH_EC_NO_TRIGGER_CELL 18 RSCP_TRIGGER_CELL 16 SCRAMBLING_CODE_ADDITIONAL_CELL1 1023 CPICH_EC_NO_ADDITIONAL_CELL1 127 RSCP_ADDITIONAL_CELL1 255

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

Three cell areas

A: Cell is interfered by co-site cells. Easy to control. B: Cell is dominant. There is no interference. We only generate interference. interfered by several C: Cell interferers. Here is the action! is C C When terminal enters border region we get events: terminal sends RRC A measurement report. Terminals B send them also when they want A change in the Active Set.
C A

Antennas
We want to minimize soft handover region keep good handovers despite cell breathing keep good coverage take care of users in upper oors of the buildings.

based on RRC measurements, we look at RSCP/EcNo when new cell is requested per relation just RSCP cosited cells (strong signal, interference) cells on site border AKOTNI: cell in the city, good neighbors LMVRH: rural, highway

Graphs
All RRC measurements for specic 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 (low EcIo with good RSCP) on cell border. Too many graphs to look: warning for bad cells, KPI les.

Antenna downtilt
Before and after

Cosite events

Other cells

LMVRHB others

SHO RSCP

LMVRHB sho

AKOTNIC gsm
Where 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 service

Cell on LA border

Distance

Overshooting
No calls: removed from BSS BA-list far away

Positioning
Nothing for positioning based services, but essential data for UTRAN antenna optimization. GPEH, RRC, WCDMA We use GPS (WCDMA) satellites with cesium clocks RX measures time-difference of arrival (TDOA) position is calculated NPAP round trip time not used in this example

RRC events
We 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 }

SFNSFN
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

Sync
If UTRAN NodeB are in sync (like IS95), we can easily get location where two hyperbolas intersect. GPS uses three hyperbolas, but we are on the ground Multilateration: where hyperbolas intersect? 3GPP: Location Measurement Unit, overkill

Software LMU
We have millions of RRC measurements. Those reporting 4 or more sites carry additional information. we can calculate offsets/delays between sites.

Data validation
Only RRC with 4 or more sites reported are taken. Errors in reporting: faulty terminals, unstable rst 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 rst 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 linearization) One measurement with three sites: two eq, two unknowns (x,y of 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 sites Take 50 different RRC measurements, each having at least 4 out of 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 taken Software LMU works sub-chip accuracy (we use 1/10 of chip) values stable for a week or more we detected difference in cosited 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 least 3 sites is known. Kalman ltering 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 pollution area) Driving home from Chinese restaurant Nothing done for almost a year (time)

Home area
locations: 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 Ljubljana Finish the work: get trafc maps for different RABs. antennas, indoor Get more data with parameter changes Optimize antennas and power based on real measurements.

Literature:
3GPP specs to understand SFNSFN TDOA positioning: a lot of articles, PhD (Finland, Spain), math: done for GPS SW LMU: basic math, solving of nonlinear multivariable equations no articles found so far As promised: Nothing for positioning based services, but essential data for 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).