E/// GPEH question

[nicodrey]

Hi guys,

I have seen several documents on E/// GPEH showing study of RSCP vs distance or EcN0 vs distance.
Is there anybody that can explain me how to do such study please, I mean which GPEH events to activate, which field to look at and how to use and merge the information in order to get this kind of study. ( I exclude from my question all the part related to how to technically parse the info )

More generaly I am interested in how to use GPEH to troubleshoot. So if you guys have some practical example on how you use it, I am very interested.

Hope my request is clear enough.

Thanks guys


Cheers.

[nicodrey]

Dear experts,

Anyone able to help me?
Can't find the propagationdelay field in any of the gpeh event?

Thanks

Cheers

[sonerss]

Hi

you can reach the propagationdelay values in moshell


Dear experts,

Anyone able to help me?
Can't find the propagationdelay field in any of the gpeh event?

Thanks

Cheers

[nicodrey]

Actually I finally found the propagationdelay field thanks to 3GPP TS 25.433.
You can get the propagationDelay in the GPEH event 128 NBAP-RADIO-LINK-SETUP.

Then getting also GPEH event 8 RRC-MEASUREMENT-REPORT allow to get cpich-Ec-N0 and cpich-RSCP. This info is identified by scrambling code.

Finally, the key to link the information between PropagationDelay and EcN0 and RSCP measured is the Ue-context field in the two events.

This kind of study need some post processing work to arrive to the final result... Still working on it... But at least It seems that finally I am on the good way to understand how this kind of study are done...

Hope it will save some time for some guys interresting in this kind of study.

Cheers

[keanchan]

in W10 release, E******* introduced a new event INTERNAL_RES_CPICH_ECNO which contains the propagation delay during call setup.

459 INTERNAL_RES_CPICH_ECNO
The event shall be triggered periodically based on RES measurement periodicity. Additionally it shall be triggered at call set up.
Common parameters (1)
EVENT_PARAM_SOURCE_CONF
EVENT_PARAM_C_ID_SERV_HSDSCH_CELL
EVENT_PARAM_IMSI
EVENT_PARAM_SOURCE_CONNECTION_PROPERTIES
EVENT_PARAM_PROPAGATION_DELAY
EVENT_PARAM_SCRAMBLING_CODE_CELL_1
EVENT_PARAM_SCRAMBLING_CODE_CELL_2
EVENT_PARAM_SCRAMBLING_CODE_CELL_3
EVENT_PARAM_SCRAMBLING_CODE_CELL_4
EVENT_PARAM_CPICH_EC_NO_CELL_1
EVENT_PARAM_CPICH_EC_NO_CELL_2
EVENT_PARAM_CPICH_EC_NO_CELL_3
EVENT_PARAM_CPICH_EC_NO_CELL_4
EVENT_PARAM_RSCP_CELL_1
EVENT_PARAM_RSCP_CELL_2
EVENT_PARAM_RSCP_CELL_3
EVENT_PARAM_RSCP_CELL_4
.........

This event however will only be available if the MRR recording is active for the cells.

[electron]

in W10 release, E******* introduced a new event INTERNAL_RES_CPICH_ECNO which contains the propagation delay during call setup.

459 INTERNAL_RES_CPICH_ECNO
The event shall be triggered periodically based on RES measurement periodicity. Additionally it shall be triggered at call set up.
Common parameters (1)
EVENT_PARAM_SOURCE_CONF
EVENT_PARAM_C_ID_SERV_HSDSCH_CELL
EVENT_PARAM_IMSI
EVENT_PARAM_SOURCE_CONNECTION_PROPERTIES
EVENT_PARAM_PROPAGATION_DELAY
EVENT_PARAM_SCRAMBLING_CODE_CELL_1
EVENT_PARAM_SCRAMBLING_CODE_CELL_2
EVENT_PARAM_SCRAMBLING_CODE_CELL_3
EVENT_PARAM_SCRAMBLING_CODE_CELL_4
EVENT_PARAM_CPICH_EC_NO_CELL_1
EVENT_PARAM_CPICH_EC_NO_CELL_2
EVENT_PARAM_CPICH_EC_NO_CELL_3
EVENT_PARAM_CPICH_EC_NO_CELL_4
EVENT_PARAM_RSCP_CELL_1
EVENT_PARAM_RSCP_CELL_2
EVENT_PARAM_RSCP_CELL_3
EVENT_PARAM_RSCP_CELL_4
.........

This event however will only be available if the MRR recording is active for the cells.

Hi Kaenchan,


Do you have such kind of macro or program to allow us to parse GPEH result ?


Thanks

[keanchan]

Hi Kaenchan,


Do you have such kind of macro or program to allow us to parse GPEH result ?


Thanks

You can convert the GPEH log to text file using the OSS itself. Search for GPEH in this forum and you will also find a PERL script to convert.

[electron]

You can convert the GPEH log to text file using the OSS itself. Search for GPEH in this forum and you will also find a PERL script to convert.

Thanks Keanchan.


Actually regarding converting GPEH form OSS could you please give my som instruction or attach some step by step snapshot?



For Perl script i found it in forum but i do not know how to use it .

Your advice and experiences will help me a lot .


Appreciate

[sonerss]

hi keanchan

I wonder how to use perll script for decode GPEH data.. Can you expain us process step by step ...

BR


Thanks Kaenchan.
Actually regarding converting GPEH form OSS could you please give my som instruction or attach some step by step snapshot?

For Perl script i found it in forum but i do not know how to use it .

Your advice and experiences will help me a lot .
Appreciate

[riyantoyadi]

Great for E/// , how about in Huawei? Any answer

[keanchan]

hi keanchan

I wonder how to use perll script for decode GPEH data.. Can you expain us process step by step ...

BR

Sorry, I have not used the Perl script before

[keanchan]

Great for E/// , how about in Huawei? Any answer

In Huawei, the CHR recording also collect the propagation delay info. You can use the PCHR analyzer to decode the CHR

[JJay]

In Huawei, the CHR recording also collect the propagation delay info. You can use the PCHR analyzer to decode the CHR
Can you share the PCHR for R12?

[Resistor]

In Huawei, the CHR recording also collect the propagation delay info. You can use the PCHR analyzer to decode the CHR

However, while CHR and TMF files in Huawei contain similar information as GPEH files in E*******, there are differences, one of which is in the ability to collect data -- for example E******* can collect data from _every_ call made by _every_ subscriber on a given RNC (this is 100% of the calls for 100% of the subscribers) if the number of recorded event types is reasonable (say 20 or 30 recorded event types). With Huawei this is not possible -- I believe that their limit is something like 32 cells per RNC and not more than 20 simultaneous calls per cell can be monitored. This limits the usefulness of the CHR files. We will have to wait until Huawei improve this and make it comparable to GPEH in efficiency of recording.

Regards,
Resistor

[choonyeh]

HI,
GPEH is known to identify missing neighbours and drop calls with the reasons due to others. i've using GPEH to trouble shoot mostly this 2 problems
Also pls note that the distance mesured may not be 100% accurate as we need to consider the multipath especially for the Inbuilding case
thanks

[k_RF]

Choonyeh,

Can you pls share couple of examples of drops due to other analysis with GPEH.

Thanks!

[choonyeh]

some of the code that provide the reasons of system release

Other Radio Link Control (RLC) unrecoverable error.10Radio Link Control (RLC) unrecoverable error in UTRAN (maximum number of RLC retransmissions is reached).11Radio Connection Supervision - expiry of timer (rcsAllRlLostTimer or rcsCchWaitCuTimer or hsDschRcLostT)12Radio link failure indication leading to a release with Cause = transport.13Radio link failure indication leading to a release with cause other than transport.14