Beruflich Dokumente
Kultur Dokumente
Analysis Guide
November 2004
www.actix.com
The content of this manual is provided for information only, is subject to change without notice, and should not be construed as a commitment by Actix. Actix assumes no responsibility or liability for any errors or inaccuracies that appear in this documentation. Copyright Actix 2004-2008. All rights reserved. All trademarks are hereby acknowledged.
www.actix.com
Contents
1 INTRODUCTION .........................................................................................4 2 SERVICE ANALYSIS .....................................................................................5 3 AGGREGATION LEVELS AND TRACKERS ..............................................................6
3.1 SUBSCRIBER LEVEL .......................................................................................... 3.2 CONTEXT LEVEL.............................................................................................. 3.3 SERVICE LEVEL .............................................................................................. 3.4 TASK LEVEL .................................................................................................. 3.5 PACKET LEVEL ............................................................................................... 7 7 7 7 8
4 TRIGGER POINTS AND KEY PERFORMANCE INDICATORS ..........................................9 5 ANALYSIS EXAMPLES ...................................................................................9
5.1 STATISTICAL ANALYSIS OF THE TRACES ................................................................... 5.1.1 Sample Gb file ..................................................................................... 5.1.2 Sample Gn file ..................................................................................... 5.2 FTP TRANSFER .............................................................................................. 5.3 HTTP SESSION ............................................................................................. 9 9 9 9 9
www.actix.com
Introduction 4
1 Introduction
For many operators, GPRS-based services are a key element of their strategies to boost average revenue per user. The convergence of wireless networks and IPnot originally conceived of as a wireless data protocolbrings a unique challenge to operators of GPRS networks. As new services and devices for transmitting data are launched onto the market, and traffic increases, more pressure will be placed on monitoring and optimizing GPRS networks. In the market there are many products that allow users to monitor radio or network performance (drive test tools and protocol analyzers, although with poor KPIs creation and troubleshooting capability), but none that combine that with a clear vision of the user perception of services with the availability of indicators to dig down into the service behavior. Actix Analyzer now supports GPRS and EDGE KPIs and detailed messaging, thereby offering this functionality. This document gives an insight into the structure of the new trackers, attributes and events. It starts with an overview of the different levels of investigation, and goes on to document the definition of the single parameters and processes. A full set of practical reallife examples enable users to become confident with the new capabilities. The final aim is to offer a level of detail that gives an unrivalled flexibility on the type of analysis. Users will be able, in the same tool, to have a very high-level overview of service utilization and user behavior, as well as to be able to do a very low-level drilldown on messages belonging to a specific service or TCP/IP session.
www.actix.com
Service analysis 5
2 Service analysis
Performance of data services depends on the interaction of many entities and different protocol levels. Flexibility in data filtering and aggregation possibilities is necessary, so Actix solutions allow:
Data aggregation per single users, PdP Contexts, service sessions, single IP connections and many others. Application of generic KPIs to different interfaces and services, thereby standardizing queries and reports. Analysis from the service (HTTP, MMS etc.1) to TCP/IP transport layer and further down to GPRS specific protocols.
The services that have predefined KPIs are: FTP, HTTP, MMS, WAP and ICMP. SMTP and POP3 are decoded and listed in summary queries.
www.actix.com
From a network point of view (so per network elements) From a 'user experience' point of view
The first case applies when we want to maximize the network performance and efficiency, the second when we want to achieve an optimal user experience (QoS as perceived by the customers). Of course, the best optimization needs to find the trade-off between the two. This section specifies the trackers (i.e. identifiers attached to every message belonging to the particular session) used to aggregate performance indicators, thus measuring the user perception of services.
The following table lists all the available trackers and their applicability: Tracker Subscriber Id Mobile IP Address PdP Context Id Service Id Task Id Packet Session Id (TCP/UDP/WTP) IP Session Id Um Yes No Yes Yes Yes Yes Gb Yes Yes Yes Yes Yes Yes Yes Gn Yes Yes Yes Yes Yes Yes Yes Gi Yes Yes Yes Yes Yes Server Yes Yes Yes Yes Yes
IP sniffer files, collected on any interface from R (between TE and MT) to the server side2 Protocol analyzer files3
a connection to an FTP server to trigger the download or upload of a group files the download of a web or WAP page the transfer of a picture message or other MMS transactions a complete e-mail
the single file downloads triggered by a retrieve the single objects of a web page (text, icons and pictures) the text and the attachments of an e-mail an object of an MMS session
The traces outside the GPRS network must be based on a protocol stack similar to the Gi interface. 3 For the complete list of protocol analyzers and interfaces supported see IVS release notes or contact Actix support.
www.actix.com
www.actix.com
Interactions among service, task and packet levels. Trigger points for the different events (set-up, data transmission and release phase, when applicable). Measurements and KPIs available in the different phases (signaling times, success and failure events, data volumes and throughput, retransmissions, durations).
www.actix.com
www.actix.com
General attributes (like the session identifiers). Key Performance Indicators (like overall throughput with and without retransmissions, retransmission percentage, initialization time). Measurements (like delta and cumulative packets, bytes, throughput with and without retransmissions, times). Events and events time (also failure causes are included here).
www.actix.com
Every level sets similar names for these parameters (the prefix distinguish them). That gives a broad, comprehensive and easy-to-understand set of KPIs or attributes that can be aggregated in KPIs. Reports and queries can be designed on top of them. Appendix A gives details for every single indicator definition, while in Appendix B the formula of every single aggregated value is provided.
www.actix.com
Analysis examples 13
5 Analysis examples
This section provides example analyses using the indicators and trackers presented in the previous sections. The aim is to show how it is possible to use the information described in the previous sections to:
Provide a statistical view of the content of the traces (users, traffic, events etc.). Identify quickly those cases with poor performance. Drill down into the causes and circumstances that generated the problems.
The queries presented below can be also used to generate a summary report, since they provide information on all levels:
Subscriber PdP Context Service Task Packet (normally too detailed for a statistical analysis)
www.actix.com
Analysis examples 14
The first query gives statistics of the attached subscribers (124 unique IMSIs4 are in the trace):
Clicking on the query Active subscribers per application, we can see that only 5 of them are active5 in the trace (one using FTP, generating most of the data volume, and the others doing WAP):
Sometimes the traces contain only parts of user sessions (for example they do not include the attach or the PdP Context activation); Analyzer tracks the sessions anyway but assigns progressive internal identifiers, substituting the IMSI if it is found at some point in the trace, otherwise leaving the internal ID. 5 A subscriber or other dimension is defined Active when at least one packet is transmitted during the session.
www.actix.com
Analysis examples 15
With the query Active Context per trace, we get the list of active PdP Contexts:
Any of these queries can be used to filter on a specific quantity (a subscriber or a context) for more detailed analysis. Using the queries activated by the scenarios, it is also possible to extract the subscribers in separate sub-streams. See the IVS release notes and online help for details. A second step in the analysis is given by the queries on service, task or packet level. The service summary shows the events and data throughput and volumes. It is clear from it that most of the sessions, although generating traffic, have been abnormally terminated (see statistic # Service abort):
www.actix.com
Analysis examples 16
We need then to have a better insight on the causes, selecting the query Subscriber and service report:
From that we can appreciate not only the causes of the aborts, but also KPIs like the time taken to connect to the server, the total duration of the connection, or the part dedicated only to data transfer (thus cutting out the idle time and signaling), so that usage patterns can be identified. Scrolling on the right, we can see all the other KPIs (throughput values, data volumes and retransmissions, in number of packets and percentage):
The throughput values represent the throughput average of the single tasks. The Service summary query includes also the average of all the single throughput measurements during the service (so the longest tasks have a higher influence on the resulting value, whilst in the first case they all contribute in the same way).
www.actix.com
Analysis examples 17
In this case, the task level is not adding a lot, because there is a single download per connection to the FTP server (that is not true in case of mget or mput with multiple files), and the cause of abort is still the Packet Data Session Ended:
We have seen how to summarize in a single click the content of the trace, and then to refine the statistics to a higher level of detail. There are some problems related to the services used in the file so the investigation can proceed with a drill-down. The follow-up of the investigation (possible in the same session) will be performed in the next sections (5.2 and 5.3).
of which 33 are active (31 on HTTP and 2 doing Pings, next picture). The logged trace is quite short; one effect of this is that there are many sessions, of which the start of signaling and data transfer is tracked, but not the conclusion (that explains the discrepancy between the counters).
www.actix.com
Analysis examples 18
From the PDP Context query, we can see that there several open contexts for other services, but they are not active in the trace (no packets are tracked):
www.actix.com
Analysis examples 19
If we analyze the WAP sessions, we can see that 3 of them are aborted because of a connection redirect:
For a drill-down, Packet report query can be selected and a single WAP session filtered:
www.actix.com
Analysis examples 20
Then tables using WSP and WTP attributes and the Protocol Stack Browser can be used:
We can see that there are two Service Session Starts, but only one Service Session End. Also, we find that Service Abort has happened. When we open individual FTP Sessions (Figure 19), we find two Service Sessions. The first Service Session ends correctly, but the second one has no Service End but a Service Abort. Lets focus on the second Service Session.
www.actix.com
Analysis examples 21
We can use the filter functionality of the Statistic Explorer to narrow down the analysis to the messages of the second Service Session. Lets use the Service report query to investigate that Service Session. From that query, we can see that the cause of abort was Packet Data Session Ended6 (Figure 20).
The next step is to investigate individual tasks, and find out which task caused the problem. From the Task report (Figure 21) view, we see that there are three FTP tasks, and one of these is aborted. Also, other information on tasks is presented, although we will not consider it in this analysis.
We will go further down to the packet level using a Packet report query. We can see that the initiator of the abort was the FTP Server (Figure 22).
Analysis examples 22
Using Internet level attributes and the Protocol Stack Browser, we can investigate at a more detailed level what really happened (Figure 23). The FTP Client has asked to store a file (FTP_Event = STORE), and a new TCP Data connection was opened. TCP_Event_ID attribute describes how TCP connection proceeds. Here we can see that there has been normal data transfer, one retransmission and then the FTP server sends an abort. Checking that packet from the Protocol Stack Browser, we can see that the TCP Reset bit is set. By this way, it is possible to investigate all aspects of TCP level, and if necessary, go still further down to IP level.
The event engine uses internal Event Diagrams to generate application level information and events. Diagrams calculate part of attributes and events, but they are also a visual aid to internal troubleshooting. For example, to find out how FTP Session proceeds, FTP Diagram shows main states and transitions between states (Figure 24). There are diagrams for Service and Task Sessions too, so one can start the investigation using these diagrams, and proceed to lower levels if necessary. In this example, one may notice that an Abort happens from the Transfer state to the End State, which means that whole FTP Session is aborted. If the transition was from the Transfer state to the Ready state, only that particular task was aborted (e.g. the user cancelled the current file download).
www.actix.com
Analysis examples 23
www.actix.com
Analysis examples 24
When scrolling the same query to the right, we can check the throughput values, both including retransmissions and without retransmission. We can see that there is some difference between these values, and if we check retransmission percentages, we see that the first HTTP session has 0.30 % of packets retransmitted (Figure 26). The second session is free of retransmissions.
After that, we can use Task level query to find out which tasks have had problems. Then we can open a chart with the attribute Packet_Evt_Packet_Retransmitted. There are 10 retransmissions, but most of them occurred on the signaling phase, so they are not taken into account when calculating the number of Service Packets and Bytes. Lets zoom to the task that we found had retransmissions (Figure 27). Using tables, charts and the Protocol Stack Browser, we can see when retransmissions happened, in which session and task, and also investigate particular IP packets if necessary.
www.actix.com
Analysis examples 25
In this case there were only three retransmissions, which do not cause any significant quality degradation to the end user. Anyway, in this way it is possible to focus on the problematic tasks and analyze these only. Another useful attribute is to use round trip time measurements: Packet_RTT_Server_Side and Packet_RTT_Mobile_Side (Figure 28).
www.actix.com
Analysis examples 26
From this chart, we can see what the response times are. Since the logfile is captured on Mobile Site, response times are short. From Server Side RTT we can see quite constant response time, with some peaks, which can be due network delay or the server has been busy. Every user can define some ideal threshold for the parameters and use them as benchmarking to highlight a critical performance. Although this specific trace shows no big problems, the process shown can be applied to spot abnormal patterns and drill down to the root cause.
www.actix.com
There are three new corresponding event diagrams (.aev), format groups (.xml), and attributes (.xml) files. There are also changes to some of the already existing files, mainly due to the fact that some old attributes in the UMTS.xxx are now moved to the above new files, with the intention of including the PS properties (attributes, format groups) in the specific PS files rather than keep them in the more general UMTS files. Description of events, attributes and values are specified in the relevant sections below. Note on diagrams Red dotted lines between states represent transition that have been added to cope with corrupted log files that occasionally skip messages. Note on timers Several NAS procedures are supervised by a re-transmission mechanism. The principle is to provide the requesting node with the possibility to resend a particular message in the case that the peer entity does not reply in time. 3GPP specifies the max number of retransmissions, the time between two consecutive retransmissions and, in most cases, the expected behavior of the requesting node in the abnormal event that no reply is received after the last attempt. For some of the procedures (e.g. PDP Context Activation from SGSN) the PS NAS Event Diagrams handle the supervision timers; the abortion event is detected by the timer expiry because the requesting node is not expected to signal the abortion the other node. However, for the cases in which the requesting node is expected to abort the procedure with explicit signaling (e.g. PDP Context Activation from UE) the supervision timer is not implemented.
www.actix.com
6.2.3.1
www.actix.com
6.2.3.2
RRC: Signaling Connection Release with PS domain indication RRC: RB Release also explicitly indicates the release of the PS signaling connection
Only if RB Release is used RRC: Signaling Connection Release Request with PS domain indication
www.actix.com
www.actix.com
PS Attach A PS Attach is always initiated by the UE via: Attach Request The message is included either in RRC:Initial Direct transfer or in RRC:Uplink Direct Transfer messages.
Successful PS Attach Note that in case of missing reply to Attach Request, the UE should re-send the message, up to a total of 4 re-transmissions. The same mechanism is used by the SGSN to supervise the reply (when expected) to Attach Accept. The PS Attach procedure can fail for several reasons, the most common of which are detected by the GMM Event diagram and listed below (see the table of attributes for more details):
Attach rejected by the SGSN (Attach Reject msg) Attach request not replied (after the 5th attempt) Attach Accept not replied (after the 5th attempt)
PS Detach A UE can be PS detached explicitly (the procedure can be initiated by either the UE or the SGN) or implicitly (normally by the SGSN only) The GMM Event diagram can only detect an explicit PS Detach procedure; regardless of the initiating node, the explicit PS Detach is triggered by: Detach request The message is included either in RRC:Initial Direct Transfer or in RRC:Uplink Direct Transfer messages if UE initiated, in a RRC:Downlink Direct Transfer if SGSN initiated. 1 Only if P-TMSI is included in Attach Accept message
www.actix.com
Successful PS Detach The failure scenarios covered by the Event Diagram occur only in case of UE initiated Detach without power-off:
The network release the underlying RRC connection instead of accepting the Detach request Detach request not replied (after the 5th attempt)
Routing Area Update (RAU) RAU is always initiated by the UE, which needs to be already PS Attached (or GMMregistered). However, the Event diagram copes with abnormal scenarios where a RAU is triggered from a UE that is considered PS Detached. In any case, the procedure is initiated via: Routing Area Update request The message is included either in RRC:Initial Direct transfer or in RRC:Uplink Direct Transfer messages.
RRC Connection
Successful Routing Area Update 1 Only if triggered by the UE and with power-off flag As for the PS Attach procedure, a re-transmission process can be triggered by missing replies to Request and Accept messages. Therefore, the failure scenarios of RAU are very similar to the ones of PS Attach:
RAU rejected by the SGSN (Attach Reject msg) RAU request not replied (after the 5th attempt) RAU Accept not replied (after the 5th attempt)
www.actix.com
Except for Network Failure reasons, when a RAU fails the UE is still considered PS Attached. The diagram is a simplified interpretation of the 3GPP specs (24.008), where more specific failure scenarios are specified. However, all of the most common scenarios are covered.
Aborted After Attach request: RRC:RRC Conn. Rel. or RRC:Sig. Conn. Rel. (PS) or RRC:Sig. Conn. Rel. Req. (PS) or RRC connection Request or RAU Request or Detach Request (from SGSN with re-attach not required) After Attach Accept: expiry of T3350 (after the 5th attempt) Uu_PS_Detach Succ_1_Attempt .. Succ_5_Attempt Detach Request from UE (with power-off) or from SGSN After Detach Request from UE (with power-off): Detach Accept The attempts refer to the number of Detach Request messages sent Aborted After Detach Request from UE (with power-off): expiry of T3321 (after the 5th attempt) or RRC Connection release
Succ_1_Attempt .. Succ_5_Attempt RAU Accept if this message includes PTMSI RAU Complete if preceding RAU Accept do not include P-TMSI The attempts refer to the number of RAU Request messages sent Uu_PS_RAU Rejected After RAU request: RAU Reject
Aborted After RAU request: RRC:RRC Conn. Rel. or RRC:Sig. Conn. Rel. (PS) or RRC:Sig. Conn. Rel. Req. (PS) After RAU Accept: expiry of T3350 (after the 5th attempt) Uu_PS_Attach_Duration Value in msec. Time elapsed between the request and the completion of a successful PS Attach
6.4 Session Management (SM) UMTS only with inter-system handover to/from GPRS
6.4.1 SM procedures
As in GMM most of the SM procedures are common to UMTS and GPRS. This initial version of SM event diagram is focused on UMTS events; in most of the inter-system (3G 2.5G) handover scenarios also some GPRS events are considered. However the Event diagram set only UMTS attributes. The following procedures are analyzed:
Although the Event Diagram can trace the number of PDP Contexts simultaneously active for the UE, there is no differentiation between primary and secondary contexts
PDP Context Activation Both UE and SGSN can ask for the activation of a Primary PDP Context. Only the UE can ask for the activation of a Secondary PDP Context. The UE can have a PDP Context only if is PS Attached.
RRC Connection
Iu procedures
Successful Activation of a Primary PDP Context 1 Only for SGSN initiated procedure
Successful Activation of a Secondary PDP Context Both SGSN and UE initiated PDP Context Activation procedures provide a mechanism for re-transmitting a message when an expected reply is not received. These are the failure scenarios covered:
Activation rejected by the SGSN (Activate PDP Context Reject msg) Activation request not replied by the SGSN (after the 5th attempt) Activation rejected by the UE (Request PDP Context Activation Reject msg) Activation request not sent by UE following SGSN initiation (after the 5th attempt)
PDP Context Deactivation Both UE and SGSN can ask for the deactivation of a PDP Context. The deactivation procedure is the same for both primary and secondary PDP contexts and is triggered via: Deactivate PDP Context Request
www.actix.com
Successful Activation of a Secondary PDP Context The only failure scenario detected for the PDP context Deactivation procedure is a missing reply to the Deactivation Request:
The first event usually detected by the SM Event Diagram is a PDP context Activation with UE in UMTS coverage. However, the diagram also recognizes: A PDP context deactivation (from UMTS). This may occur if the logs start with the UE already having an active PDP context. An inter-RAT Cell Change Order from UTRAN, which causes a UMTS GPRS transition for a UEs in Cell_DCH or Cell_FACH state. A GPRS UMTS transition. In this case, it is always assumed that only one PDP Context is active at the time the transition occurs. Moreover the GPRS SM/GMM activity eventually occurring before the transition is not taken into account.
Just like during UMTS coverage the number of PDP Contexts active in GPRS is tracked, although such information is not displayed until the UE returns to UMTS coverage. Throughout the GPRS session only, an in GPRS flag will appear. No attributes are displayed for SM events occurring in GPRS. However, once the UE is in GPRS mode, the following GPRS NAS procedures are detected: PDP context Activation/Deactivation PS Detach PS Attach
The detection of the above procedures in GPRS is fundamental in order to keep track of the correct number of PDP Contexts active when the UE returns eventually to 3G.
The SM diagram takes into account the following inter-system handover and cell re-selection procedures: Inter-RAT Cell Change Order from UTRAN (UMTS Inter-RAT Handover to UTRAN (GPRS UMTS) UMTS) UMTS) GPRS)
Inter-RAT Cell Re-Selection to UTRAN (GPRS Inter-RAT Cell Change Order to UTRAN (GPRS
www.actix.com
Attribute Uu_PS_PDPAct_From_UE
Values Succ_1_Attempt
Triggers After Activate PDP Context Request or Activate Secondary PDP Context Request: Activate PDP Context Accept The attempts refer to the number of Activate PDP Context Request messages sent by UE After Activate PDP Context Request: Activate PDP Context Reject
.. Succ_5_Attempt
Rejected_by_NW
Aborted
After Request PDP context Activation: RRC:RRC Conn. Rel. or RRC:Sig. Conn. Rel. (PS) or RRC:Sig. Conn. Rel. Req. (PS) or RRC connection Request After Activate PDP Context Request: Activate PDP Context Accept The attempts refer to the number of Request PDP Context Activation messages sent by SGSN After Activate PDP Context Request: Activate PDP Context Reject
Uu_PS_PDPAct_From_NW
Succ_1_Attempt .. Succ_5_Attempt
Rejected_by_NW
Rejected_by_UE
After Request PDP context Activation: Request PDP context Activation Reject
Aborted
After Request PDP context Activation: RRC:RRC Conn. Rel. or RRC:Sig. Conn. Rel. (PS) or RRC:Sig. Conn. Rel. Req. (PS) or RRC connection Request or (after the 5th attempt) expiry of T3385
Uu_PS_PDPDeact_From_UE
Succ_1_Attempt
Attribute
Values ..
Triggers Deactivate PDP Context Accept from SGSN or Activate PDP Context Request or Request PDP context Activation (NOTE: the last two cases are used to cope with eventual missing Deactivation Accept message from the logs) After Deactivate PDP Context Request from UE: expiry of T3390 (after the 5th attempt) or RRC:RRC Conn. Rel. or RRC connection Request or Detach request
Succ_5_Attempt
Aborted
Uu_PS_PDPDeact_From_NW
Succ_1_Attempt ..
After Deactivate PDP Context Request from SGSN: Deactivate PDP Context Accept from UE or Activate PDP Context Request or Request PDP context Activation (NOTE: the last two cases are used to cope with eventual missing Deactivation Accept message from the logs) After Deactivate PDP Context Request from SGSN: expiry of T3395 (after the 5th attempt)
Succ_5_Attempt
Aborted
Uu_PDP_State
1st Activate PDP Context Request or 1st Request PDP context Activation 1st Deactivate PDP Context Request (UE of SGSN) Cell Change Order from UTRAN Beginning of the file Last PDP deactivated GPRS to UMTS transition with no PDP Active Detach request from PDP(x) Inactive or PDP Context Deactivation pending states
www.actix.com
Attribute
Triggers
PDP_Session_ID Uu_TimeBetweenPDP_ReqAndAct
Incremented every time a new PDP Context is set up Time between Activate PDP Context Request (or Request PDP Context Activation) and Activate PDP Context Accept Time between Activate PDP Context Request (or Request PDP Context Activation) and Deactivate PDP Context Request Time between Activate PDP Context Request (or Request PDP Context Activation) and Deactivate PDP Context Request Time between Deactivate PDP Context Request and Deactivate PDP Context Accept
Uu_TimeBetweenPDP_ReqAndDeactReq
Value in msec.
Uu_TimeBetweenPDP_ActAndDeact
Value in msec.
Uu_TimeBetweenPDP_DeactReqAndDeact
Value in msec.
www.actix.com
Appendix A 40
7 Appendix A
Attribute
Subscriber Session Subscriber_Session_ID Event Subscriber_Evt_Start_Session Subscriber_Evt_End_Session Generated on the first packet for a Subscriber Session Generated when the Mobile or Server indicate the Subscriber Session is over Event Event A unique ID for this Subscriber Session Identifier
Description
Unit
Direction
Event Times Subscriber_Time_Start_Session Subscriber_Time_End_Session Context Session Context_Session_ID Context_Duration_Session Event Context_Evt_Start_Session Context_Evt_End_Session Event Times Context_Time_Start_Session Context_Time_End_Session Service Session Service_Session_ID Service_Protocol_Type Key Performance Indicators Service_Duration_Session_Initiali zation The time it takes for the server to be ready to serve a mobile's request for data transfer Millisec A unique ID for this Service Session The service type, eg HTTP, FTP, POP3, SMTP, WAP or ICMP Identifier Protocol The time of Context_Evt_Start_Session The time of Context_End_Session Relative millisec Relative millisec Generated on the first packet for a Context Session Generated when the Mobile or Server indicate the Context Session is over Event Event A unique ID for this Context Session The duration of the Context Session Identifier Time The time of Subscriber_Evt_Start_Session The time of Subscriber_Evt_End_Session Relative millisec Relative millisec
www.actix.com
Appendix A 41
Attribute
Service_Perc_Packets_Retr_UL Service_Perc_Packets_Retr_DL Service_ThrPut_Fin_IncRetr_UL
Description
The percentage of packets that have been retransmitted The percentage of packets that have been retransmitted Final throughput including retransmissions. Calculated only at the end of the service Final throughput not including retransmissions. Calculated only at the end of the service Final throughput including retransmissions. Calculated only at the end of the service Final throughput not including retransmissions. Calculated only at the end of the service
Unit
Percent Percent Kilobits per second Kilobits per second Kilobits per second Kilobits per second
Direction
Uplink Downlink Uplink
Service_ThrPut_Fin_NoRetr_UL
Uplink
Service_ThrPut_Fin_IncRetr_DL
Downlink
Service_ThrPut_Fin_NoRetr_DL
Downlink
Measure Service_Duration_Data_Transfer_ Delta Service_Duration_Data_Transfer_ Cum Service_Duration_Session_Delta The time the task was active The sum of Service_Duration_Data_Transfer_Del ta The time since the last task was complete or the Service was initialized. This can be used as interarrival time between tasks. The time since Service was Initialized. Calculated at the end of Task and at the end on Service. The number of packets transmitted in the completed task. This includes retransmitted packets The sum of packets transmitted in the completed tasks. This includes retransmitted packets The number of packets transmitted in the completed task. This does not include retransmitted packets The sum of packets transmitted in the completed tasks. This does not include retransmitted packets The number of bytes transmitted in the completed task. This includes retransmitted packets The sum of bytes transmitted in the completed tasks. This includes retransmitted packets Millisec Millisec
Millisec
Service_Duration_Session_Cum
Millisec
Count
Uplink
Count
Uplink
Count
Uplink
Count
Uplink
Service_Bytes_Delta_IncRetr_UL
Bytes
Uplink
Service_Bytes_Cum_IncRetr_UL
Bytes
Uplink
www.actix.com
Appendix A 42
Attribute
Service_Bytes_Delta_NoRetr_UL
Description
The number of bytes transmitted in the completed task. This does not include retransmitted packets The sum of bytes transmitted in the completed tasks. This does not include retransmitted packets The number of packets transmitted in the completed task. This includes retransmitted packets The sum of packets transmitted in the completed tasks. This includes retransmitted packets The number of packets transmitted in the completed task. This does not include retransmitted packets The sum of packets transmitted in the completed tasks. This does not include retransmitted packets The number of bytes transmitted in the completed task. This includes retransmitted packets The sum of bytes transmitted. This includes retransmitted packets The number of bytes transmitted in the completed task. This does not include retransmitted packets The sum of bytes transmitted. This does not include retransmitted packets
Unit
Bytes
Direction
Uplink
Service_Bytes_Cum_NoRetr_UL
Bytes
Uplink
Count
Downlink
Count
Downlink
Count
Downlink
Count
Downlink
Service_Bytes_Delta_IncRetr_UL
Bytes
Downlink
Service_Bytes_Cum_IncRetr_DL Service_Bytes_Delta_NoRetr_DL
Bytes Bytes
Downlink Downlink
Service_Bytes_Cum_NoRetr_DL
Bytes
Downlink
Event Service_Evt_Start_Session Service_Evt_Incomplete_Start_S essi on Service_Evt_Initialize_Session Generated on the first packet for a Service Session Generated when a start of the Service Session was not found Generated when the Server has acknowledged that it is ready to service any request from the Mobile Generated when the Mobile or Server indicate the Service Session is over Generated when the Mobile or Server abnormally terminate the Service Session, or a timeout occurs in the Application Layer The reason for abnormal termination of the Service Session Event Event Event
Service_Evt_End_Session Service_Evt_Abort_Session
Event Event
Service_Cause_Abort
www.actix.com
Appendix A 43
Attribute
Event Times Service_Time_Start_Session Service_Time_Initialize_Session Service_Time_End_Session Task Session Task_Session_ID Key Performance Indicators Task_Perc_Packets_Retr_UL
Description
Unit
Direction
Identifier
The percentage of packets retransmitted. Calculated only at the end of the task The percentage of packets retransmitted. Calculated only at the end of the task Final throughput including retransmissions. Calculated only at the end of the task Final throughput not including retransmissions. Calculated only at the end of the task Final throughput including retransmissions. Calculated only at the end of the task Final throughput not including retransmissions. Calculated only at the end of the task
Percent
Uplink
Task_Perc_Packets_Retr_DL
Percent
Downlink
Task_ThrPut_Fin_IncRetr_UL
Kilobits per second Kilobits per second Kilobits per second Kilobits per second
Uplink
Task_ThrPut_Fin_NoRetr_UL
Uplink
Task_ThrPut_Fin_IncRetr_DL
Downlink
Task_ThrPut_Fin_NoRetr_DL
Downlink
Measure Task_Duration_Session Task_Time_Delta_UL The duration of the Task Session Time since last Application Data. This can be used as interarrival time between packets Time since last Application Data. This can be used as interarrival time between packets The sum of Task_Time_Delta The sum of Task_Time_Delta The sum of packets including retransmissions The sum of packets excluding retransmissions The number of bytes sent in this packet including retransmissions Time Time Uplink
Task_Time_Delta_DL
Time
Downlink
www.actix.com
Appendix A 44
Attribute
Task_Bytes_Delta_NoRetr_UL Task_Bytes_Cum_IncRetr_UL Task_Bytes_Cum_NoRetr_UL Task_Packets_Cum_IncRetr_DL Task_Packets_Cum_NoRetr_DL Task_Bytes_Delta_IncRetr_DL Task_Bytes_Delta_NoRetr_DL Task_Bytes_Cum_IncRetr_DL Task_Bytes_Cum_NoRetr_DL Task_ThrPut_Inst_IncRetr_UL
Description
The number of bytes sent in this packet excluding retransmissions The sum of bytes sent including retransmissions The sum of bytes sent excluding retransmissions The sum of packets including retransmissions The sum of packets excluding retransmissions The number of bytes sent in this packet including retransmissions The number of bytes sent in this packet excluding retransmissions The sum of bytes sent including retransmissions The sum of bytes sent excluding retransmissions Instantaneous throughput not including retransmissions. Calculated once a second Instantaneous throughput not including retransmissions. Calculated once a second Instantaneous throughput not including retransmissions. Calculated once a second Instantaneous throughput not including retransmissions. Calculated once a second The cumulative percentage of retransmitted packets. It is generated each time a packet is received The cumulative percentage of retransmitted packets. It is generated each time a packet is received
Unit
Bytes Bytes Bytes Packets Packets Bytes Bytes Bytes Bytes Kilobits per second Kilobits per second Kilobits per second Kilobits per second Percent
Direction
Uplink Uplink Uplink Downlink Downlink Downlink Downlink Downlink Downlink Uplink
Task_ThrPut_Inst_NoRetr_UL
Uplink
Task_ThrPut_Inst_IncRetr_DL
Downlink
Task_ThrPut_Inst_NoRetr_DL
Downlink
Task_Perc_Packets_Cum_Retr_UL
Uplink
Task_Perc_Packets_Cum_Retr_D L
Percent
Downlink
Event Task_Evt_Start_Session Task_Evt_End_Session Task_Evt_Abort_Session Task_Cause_Abort Generated at the start of a Task Session Generated at the end of a Task Session Generated when on Packet Layer abort or Application Layer timeout The cause of the Task Abort Event Event Event Event
www.actix.com
Appendix A 45
Attribute
Event Times Task_Time_Start_Session Task_Time_End_Session Packet Session Packet_Session_ID Packet_Direction Key Performance Indicators Packet_Packets_Retr_Perc_UL Packet_Packets_Retr_Perc_DL Packet_Duration_Initialization
Description
Unit
Direction
Time Time
Identifier Uplink/Downli nk
Percentage of packet retransmissions Percentage of packet retransmissions The time it takes for the Server to be ready to serve a Mobile's request for data transfer The time it takes for the Mobile or Server to close the Packet Session
Uplink Downlink
Time
Packet count, including retransmissions Packet count, not including retransmissions Percentage of packet retransmissions Instantaneous Packet Throughput, including retransmissions. Calculated once a second Instantaneous Packet Throughput, not including retransmissions. Calculated once a second Packet count, including retransmissions Packet count, not including retransmissions Percentage of packet retransmissions Instantaneous Packet Throughput, including retransmissions. Calculated once a second Instantaneous Packet Throughput, not including retransmissions. Calculated once a second
Count Count Percent Kilobits per second Kilobits per second Count Count Percent Kilobits per second Kilobits per second
Packet_ThrPut_Inst_NoRetr_UL
Uplink
Packet_ThrPut_Inst_NoRetr_DL
Downlink
www.actix.com
Appendix A 46
Attribute
Packet_Duration_Data_Session
Description
The duration of the Packet Data Session, maximum of Packet_Duration_Mobile_Data_Sessi on and Packet_Duration_Server_Data_Sessi on The duration of the Mobile Packet Data Session The duration of the Server Packet Data Session Round-Trip Time it takes to send a packet to the Server and come back to the Mobile Round-Trip Time it takes to send a packet to the Mobile and come back to the Server The number of bytes sent in this packet including retransmissions The number of bytes sent in this packet excluding retransmissions The sum of bytes sent including retransmissions The sum of bytes sent excluding retransmissions The number of bytes sent in this packet including retransmissions The number of bytes sent in this packet excluding retransmissions The sum of bytes sent including retransmissions The sum of bytes sent excluding retransmissions
Unit
Time
Direction
Packet_RTT_Mobile_Side
Millisec
Packet_Bytes_Delta_IncRetr_UL Packet_Bytes_Delta_NoRetr_UL Packet_Bytes_Cum_IncRetr_UL Packet_Bytes_Cum_NoRetr_UL Packet_Bytes_Delta_IncRetr_DL Packet_Bytes_Delta_NoRetr_DL Packet_Bytes_Cum_IncRetr_DL Packet_Bytes_Cum_NoRetr_DL Event Packet_Evt_Start_Session Packet_Evt_Incomplete_Start_Se ssion Packet_Evt_Start_Data_Session Packet_Evt_Mobile_End_Data_Se ssion Packet_Evt_Server_End_Data_Se ssion Packet_Evt_End_Data_Session
Generated on the first packet of the Packet Session Generated when a start of the Packet Session was not found Generated when the initialization phase of the Packet Session is over Generated when the Mobile indicates the Packet Data Session is over Generated when the Server indicates the Packet Data Session is over Generated when both the Mobile and Server has indicated the Packet Data Session is over
www.actix.com
Appendix A 47
Attribute
Packet_Evt_End_Session
Description
Generated when both the Mobile or Server indicate the Packet Session is over Generated when the Mobile or Server abnormally terminate the Packet Session This packet is a retransmission of some previous packet This packet is truncated This packet is corrupted
Unit
Event
Direction
Packet_Evt_Abort_Session
Event
Packet_Evt_Packet_Retransmitte d Packet_Evt_Packet_Truncated Packet_Evt_Packet_Corrupted Event Initiator Packet_Initiator_Open Packet_Initiator_Close Packet_Initiator_Abort Event Times Packet_Time_Start_Session Packet_Time_Start_Data_Session Packet_Time_End_Data_Session Packet_Time_Mobile_End_Data_S ession Packet_Time_Server_End_Data_S ession Packet_Time_End_Session
The entity initiating the opening of the Packet Session The entity closing the Packet Session The entity aborting the Packet Session
Time of Packet_Evt_Start_Session Time of Packet_Evt_Start_Data_Session Time of Packet_Evt_End_Data_Session Time of Packet_Evt_Mobile_End_Data_Sessio n Time of Packet_Evt_Server_End_Data_Sessio n Time of Packet_Evt_End_Session
Time
Downlink
Time
www.actix.com
Appendix B 48
8 Appendix B
www.actix.com
Appendix B 49
www.actix.com
Appendix B 50
www.actix.com
Appendix B 51
4103, 4128
www.actix.com