GPEH 101?

Iztok Saje
E-mail: iztok.saje@mobitel.si
EUGAP, 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

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

 
 
 
 
 
 
 
 
 
 
 by
    
 
C: Cell
interferers. Here is the action!

















is




  interfered


 
 
 
 
 
 
 
 
 
 
 

 

 

 

 several

 






























































  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  When terminal enters border region




















  










  

 

 

 

 

 

 

 

 

 C

 

 

 

 

 C

 






























  






  

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  we get events: terminal sends RRC




















A









  



  

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  measurement report.





















  



Terminals









  

 

 

 B

 

 

 

 

 

 

 

 

 

 

 

 






























  



  

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  send them also when they want





















  












  

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  change in the Active Set.
























A





  




 















  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 





















  










  

 

 

 

 

 

 

 

 

 

 

 

 

 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 floors 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 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 (low
EcIo with good RSCP) on cell border.
Too many graphs to look: warning for bad cells, KPI files.

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 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 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 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 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 traffic 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).