GEO Interface
The Nokia traces we currently use are the GEO Interface files, generated by Emil Server (Megamon and Emil together).
| Name | How to detect? |
| DNS_RSCP_AVG DNS_RSCP_MAX DNS_ECNO_AVG DNS_ECNO_MAX |
extracted from RRC message “rrcMeasurementReport” (UL DCCH) |
| DNS_VOICE_CALL_START EVT_VOICE_CALL_START |
detected from Geo Interface event “RabTicket”
where rab_phase = 7 (“Active”) and rab_status = 1 (“Success”) and rab_type = 1 (“CS Voice”) note: if requested by customer separate analysis based on RANAP message flow can be done |
| DNS_PACKET_CALL_START
EVT_PACKET_CALL_START |
detected from Geo Interface event “RabTicket”
where rab_phase = 7 (“Active”) and rab_status = 1 (“Success”) and rab_ type = 3 (“PS Data”) note: if requested by customer separate analysis based on RANAP message flow can be done |
| DNS_SPEECH_DROP_CALL
EVT_SPEECH_DROP_CALL |
detected from Geo Interface event “RabTicket”
where rab_phase = 7 (“Active”) and rab_status = 2 (“Failure”) and rab_ type = 1 (“CS Voice”) note: if requested by customer separate analysis based on RANAP message flow can be done |
| DNS_PS_DROP_CALL EVT_PS_DROP_CALL |
detected from Geo Interface event “RabTicket”
where rab_phase = 7 (“Active”) and rab_status = 2 (“Failure”) and rab_ type = 3 (“PS Data”) note: if requested by customer separate analysis based on RANAP message flow can be done |
| DNS_LOCATION_AREA_UPDATE EVT_LOCATION_AREA_UPDATE | detected from NAS message
where protocol = “mobile management” and type = “location updating request” |
| DNS_LOCATION_AREA_UPDATE_REJECT EVT_LOCATION_AREA_UPDATE_REJECT | detected from NAS message
where protocol = “mobile management” and type = “location updating reject” |
| DNS_ROUTING_AREA_UPDATE EVT_ROUTING_AREA_UPDATE | detected from NAS message
where protocol = “GPRS mobility management” and type = “routing area update request” |
| DNS_RRC_CONNECTION_REQUEST EVT_RRC_CONNECTION_REQUEST | detected from RRC message “rrcConnectionRequest” (UL CCCH) additional information: “establishmentCause” |
| DNS_RRC_CONNECTION_RELEASE EVT_RRC_CONNECTION_RELEASE |
detected from RRC message “rrcConnectionRelease” (DL CCCH) additional information: “releaseCause”
|
| DNS_RRC_CONNECTION_REJECT EVT_RRC_CONNECTION_REJECT | detected from RRC message “rrcConnectionReject” (DL CCCH) additional information: “RejectionCause” |
| DNS_RRC_CELL_UPDATE EVT_RRC_CELL_UPDATE |
detected from RRC message “rrcCellUpdate” (UL CCCH) |
| DNS_RRC_URA_UPDATE EVT_RRC_URA_UPDATE |
detected from RRC message “rrcUraUPdate” (UL CCCH) |
| DNS_SOFT_HO_EXECUTION EVT_SOFT_HO_EXECUTION | detected from RRC message “activeSetUpdate” (DL DCCH)
additional information is one of the following elements: BRANCH_AD- DITION_REQUEST, BRANCH_REPLACEMENT_REQUEST or BRANCH_DE- LETION_REQUEST |
| DNS_ IRAT_HO_EXECUTION EVT_ IRAT_HO_ EXECUTION |
detected from RRC message “handoverFromUTRANCommand” (DL DCCH)
additional information is target system: GSM, EUTRA, CDMA2000, etc |
| DNS_IRAT_HO_EXECUTION_FAILURE EVT_IRAT_HO_EXECUTION_FAILURE | detected from RRC message “HandoverFromUTRANFailure” (UL DCCH) |
| DNS_IRAT_CC_EXECUTION EVT_IRAT_ CC_EXECUTION |
detected from RRC message “CellChangeOrderFromUTRAN “ (DL DCCH)
Additional Information is GSM when available. |
| DNS_ IRAT_CC_EXECUTION_FAILURE EVT_ IRAT_CC_EXECUTION_FAILURE |
detected from RRC message “CellChangeOrderFromUTRANFailure” (UL DCCH) |
| DNS_PS_DATA_VOLUME | detected from Geo Interface “ThroughputTicket”
this event is a list of integer numbers meaning different categories of a user packet traffic volumes in Bytes during a measurement period of 20 seconds: int01 = AMR_DL bytes int02 = AMR_UL bytes int03 = CS_Conv_DL bytes int04 = CS_Conv_UL bytes int05 = CS_Strea_DL bytes int06 = CS_Strea_UL bytes int07 = PS_Strea_DL bytes int08 = PS_Strea_UL bytes int09 = Intera_DL bytes int10 = Intera_UL bytes int11 = Bgr_DL bytes int12 = Bgr_UL bytes int13 = CS_Voice_HS_DSCH_DL bytes int14 = CS_Voice_HS_DSCH_UL bytes
Most of the time AMR (DL and UL) bytes are non zero (this is an AMR voice call) and/or Interactive (DL and UL) bytes are non zero (this is a typical packet data transfer using NRT R99 or HSPA service).
Other packet traffic categories have typically zero values (sometimes PS Streaming can be seen). |
| DNS _THROUGHPUT_DL DNS _THROUGHPUT_UL |
detected from Geo Interface “ThroughputTicket”
this event offers downlink and uplink interactive type throughput values in kbits/sec
Throughput is calculated from PS_DATA_VOLUME as: downlink_throughput_kbits_per_second = (8 * Intera_DL bytes / 1024) / measurement_period uplink_throughput_kbits_per_second = (8 * Intera_UL bytes / 1024) / measurement_period where measurement_period = 20 seconds (this value is fixed in RNC).
Note: Throughput in traces is calculated as number of bytes (data volume) per measurement period equal to 20 seconds. Throughput calculated this way may be close to average throughput in case of FTP or Streaming services but unfortunately is far away from expected user throughput values experienced in case of the most typical Inte- ractive Service with HSPA. For example: a single measurement period with 0,5 second of 10Mbits/s and then 19,5 sec of 0Mbit/s would give reported throughput of 0,25Mbit/s which is mathematically correct but far from common sense as the user throughput was 10Mbit/s in fact. In other words throughput values from traces cannot be used to evaluate user experience and they almost always appear much lower then expected. |