PS Domain Analysis Guide PDF

PS Domain
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 2
1 INTRODUCTION .........................................................................................4
2 SERVICE ANALYSIS .....................................................................................5
3 AGGREGATION LEVELS AND TRACKERS ..............................................................6

3.1 SUBSCRIBER LEVEL .......................................................................................... 7
3.2 CONTEXT LEVEL.............................................................................................. 7
3.3 SERVICE LEVEL .............................................................................................. 7
3.4 TASK LEVEL .................................................................................................. 7
3.5 PACKET LEVEL ............................................................................................... 8
4 TRIGGER POINTS AND KEY PERFORMANCE INDICATORS ..........................................9
5 ANALYSIS EXAMPLES ...................................................................................9

5.1 STATISTICAL ANALYSIS OF THE TRACES ................................................................... 9
5.1.1 Sample Gb file ..................................................................................... 9
5.1.2 Sample Gn file ..................................................................................... 9
5.2 FTP TRANSFER .............................................................................................. 9
5.3 HTTP SESSION ............................................................................................. 9
6 ADDITIONAL RADIO EVENTS FOR THE PS DOMAIN IN UMTS ....................................9

6.1 INTRODUCTION .............................................................................................. 9
6.2 PS SIGNALING CONNECTION PMM – UMTS ONLY ..................................................... 9
6.2.1 PS Signaling Connection concept ............................................................ 9
6.2.2 Setup of the PS Signaling Connection ...................................................... 9
6.2.3 Release of the PS Signaling Connection ................................................... 9
6.2.4 Attributes for PS Signaling Connection..................................................... 9
6.3 GPRS MOBILITY MANAGEMENT EVENT DIAGRAM (GMM) – UMTS ONLY ............................ 9
6.3.1 GMM procedures .................................................................................. 9
6.3.2 Attributes for GMM ............................................................................... 9
6.4 SESSION MANAGEMENT (SM) – UMTS ONLY WITH INTER-SYSTEM HANDOVER TO/FROM
GPRS.............................................................................................................. 9
6.4.1 SM procedures ..................................................................................... 9
6.4.2 Additional notes Inter-RAT Handover and SM ........................................... 9
6.4.3 Attributes for SM .................................................................................. 9
7 APPENDIX A.............................................................................................9
8 APPENDIX B.............................................................................................9
www.actix.com
Actix Analyzer PS Domain November 2004 Analysis Guide Introduction 4
2
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 IP—not originally
conceived of as a wireless data protocol—brings 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 real-
life 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
Actix Analyzer PS Domain November 2004 Analysis Guide Service analysis 5
2
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.
In the following sections, these elements will be analyzed in more detail.
1
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
Actix Analyzer PS Domain November 2004 Analysis Guide Aggregation levels and trackers 6
2
3 Aggregation levels and trackers
The aggregation of measurements to provide metrics can be done in two different ways:
• 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 Um Gb Gn Gi Server
Subscriber Id - Yes Yes - -
Mobile IP Address Yes Yes Yes Yes Yes
PdP Context Id No Yes Yes - -
Service Id Yes Yes Yes Yes Yes
Task Id Yes Yes Yes Yes Yes
Packet Session Id (TCP/UDP/WTP) Yes Yes Yes Yes Yes
IP Session Id Yes Yes Yes Yes Yes

Table 1 – Trackers per interface
www.actix.com
IMPORTANT: the trackers are available in traces containing IP packets:
• IP sniffer files, collected on any interface from R (between TE and MT) to the
2
server side2
• Protocol analyzer files3
3.1 Subscriber level

The actual user represents the highest aggregation level. In fact, this is the focal point to
define the customer experience. The identifier is given by the IMSI (mapped to the
attribute Subscriber_Session_Id in Actix solutions). It is valid from the access to the
network (attach procedure) till the detach (detach procedure).
3.2 Context level

This level is triggered when the user accesses the services. The Context_Session_Id starts
when an attached user opens a context (PdP Context activation) to access services and
ends with the context deactivation.
3.3 Service level

Every service entity is defined as the self-consistent and usable result of an action
performed by the user. In practical terms it can be:
• 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 Service_Session_Id is created for the scope.
3.4 Task level

This level defined the single elements defining a service. In some cases, the two levels can
coincide (for a single object WAP page or a PING the task coincides with the service
entity).
Examples of tasks (Task_Session_Id) are:
• 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
2
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
3.5 Packet level

Single packets from transport protocols constitute this level. This is too detailed for KPI
2
definition, but is useful for troubleshooting and optimization (when drill-down is required).
The protocols that are implemented for this level are:
• TCP
• WTP
• ICMP
UDP is currently not implemented.
www.actix.com
Actix Analyzer PS Domain November 2004 Analysis Guide Trigger points and Key Performance Indicators 9
2
4 Trigger points and Key Performance Indicators
Every entity defined above can be subdivided in a setup phase, an activity phase and a
release phase, and that applies to any investigation level.
For example, for the user level, the setup corresponds to the attach procedure, the activity
phase is the time where the user remains attached, and the release phase corresponds to
the detach procedure. At the lower level, the setup is, for instance, the signaling phase of
the HTTP protocol for a single object of a web page and the activity phase is the actual
object download.
The following diagrams (Figure 1, Figure 2 and Figure 3) define the:
• 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
Figure 1 - Session levels and attributes
www.actix.com
Figure 2 - Service Session durations (all attributes have a prefix “Service_”)
Figure 3 - Packet Session durations (all attributes have a prefix “Packet_”)
The attributes are organized in groups (see Figure 4):
• 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
Figure 4 - Applications’ attribute tree
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
Actix Analyzer PS Domain November 2004 Analysis Guide Analysis examples 13
2
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.
5.1 Statistical analysis of the traces

In this section, we will analyze a Gb file and a Gn file. A similar approach could be followed
with traces collected from other interfaces (compatible with the trackers available - see
Table 1).
5.1.1 Sample Gb file

Loading a Gb file and importing the queries included in “Subscriber and Context
queries.aqf”, it is possible to make a statistical analysis of the attached users and the
active ones in terms of contexts and applications.
The queries can be found under:
\Actix\Analyzer\Queries\Subscriber and Service Analysis
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
The first query gives statistics of the attached subscribers (124 unique IMSIs4 are in the
trace):
2
Figure 5 – Statistics of attached subscribers
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):
Figure 6 – Active subscribers per application
4
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
With the query “Active Context per trace”, we get the list of active PdP Contexts:
Figure 7 – Active context per trace
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”):
Figure 8 – Service summary
www.actix.com
We need then to have a better insight on the causes, selecting the query “Subscriber and
service report”:
2
Figure 9 – 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):
Figure 10 – Other KPIs
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
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:
2
Figure 11 – Service summary
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).
5.1.2 Sample Gn file

Let us repeat the statistical analysis, but this time with a Gn file. The important thing is
that the same queries and the same approach can be used because we are addressing
information belonging to the IP protocol layer or higher, which are common across the
interfaces.
As previously said, the queries are applicable seamlessly on every interface, so the look
and feel is the same as the one analyzed for Gb.
There are 224 IMSIs attached:
Figure 12 – Subscribers per trace
…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
Figure 13 – Active subscribers per application
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):
Figure 14 – PDP Context
www.actix.com
If we analyze the WAP sessions, we can see that 3 of them are aborted because of a
connection redirect:
2
Figure 15 – Service report
For a drill-down, “Packet report” query can be selected and a single WAP session filtered:
Figure 16 – Packet report
www.actix.com
Then tables using WSP and WTP attributes and the Protocol Stack Browser can be used:
Figure 17 – Protocol Stack Browser
5.2 FTP Transfer

This example describes an analysis of a file containing some FTP data transfer. We will see
how to use KPIs and queries introduced in the previous sections to separate successful
cases from unsuccessful cases, and how to analyze unsuccessful cases step by step,
finding the root cause of the problem.
To figure out what is going on, we open a crosstab query (Service summary) which shows
summary information of traffic dimensioned by Protocol type and Service Session. That
query (Figure 18) shows only an overview of Service Sessions, namely Service Start and
End events and KPIs.
Figure 18 – FTP example, Service summary
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. Let’s focus on the second Service
Session.
www.actix.com
Figure 19 – FTP example, Service Abort
We can use the filter functionality of the Statistic Explorer to narrow down the analysis to
the messages of the second Service Session. Let’s 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 Ended”6 (Figure 20).
Figure 20 – FTP example, Service details
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.
Figure 21 – FTP example, Task level
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).
Figure 22 – FTP example, Packet level
6
Another possible cause for abort is “Task Session Timeout”.
www.actix.com
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
2
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.
Figure 23 – FTP example, TCP 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
Figure 24 – FTP example, FTP diagram
www.actix.com
5.3 HTTP Session

This example shows an analysis of HTTP Sessions. We start the investigation from the
2
Service Report query, which shows us that there are two HTTP Sessions, which both start
and end gracefully (Figure 25). We can see also the number of tasks and service
initialization time. Initialization time (Service_Duration_Session_Initialization) is an
important attribute to see how fast a service provider responds to a service request. In the
HTTP case, it is the time it takes to create a first TCP connection to the server. HTTP task
is defined as a download or upload of a particular object of web page, so it starts when
HTTP Client sends a GET method (or any other method specified in RFC2616) to the
server.
Figure 25 – HTTP example, Service report
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.
Figure 26 – HTTP example, 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. Let’s 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
Figure 27 – HTTP example, Chart
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
Figure 28 – HTTP example, RTTs
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
Actix Analyzer PS Domain November 2004 Analysis Guide Additional Radio Events for the PS domain in UMTS
27
6 Additional Radio Events for the PS domain in

2
UMTS
6.1 Introduction
Three event diagrams handle the PS NAS signaling and associated procedures for UMTS.
The events apply to radio interface logs only (e.g. drive test logs).
PMM Î PS Signaling Connection monitoring
GMM Î PS Mobility Management monitoring
SM Î Session Management monitoring
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 re-
transmissions, the time between two consecutive re-
transmissions 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
28
6.2 PS Signaling Connection PMM – UMTS only

2
Figure 29 – PS Signaling PPM event diagram
6.2.1 PS Signaling Connection concept

The PPM event diagram traces the PS signaling connections, from the setup to the release
phases.
A PS signaling connection is a logical signaling resource between terminal and SGSN. It
relies on the presence of both radio (RAN Q UE) and Iu-PS interface (RAN Q SGSN)
logical/physical resources: Every NAS procedure (e.g. PS Attach or PDP context Activation)
between UE and SGSN can take place only if the PS Signaling connection is already
established between the two nodes.
Figure 30 – PS Signaling Connection
www.actix.com
29
6.2.2 Setup of the PS Signaling Connection

As shown in Figure 30, in order to establish a PS Signaling connection, a RRC and Iu-PS
connections need to be present for the UE. 2
While on the radio side the RRC Connection is shared between CS and PS Signaling
connections, on the Iu interface side the Iu resources are logically separated.
The PS signaling connection establishment is always initiated by the UE via:
RRC: Initial Direct Transfer with PS domain indication
Figure 31 – Successful PS Signaling connection Setup
6.2.3 Release of the PS Signaling Connection

The PS Signaling Connection is normally released via a RRC Connection release procedure
or a PS Signaling connection release procedure. The latter occurs usually when a CS
connection is also present and can be triggered by both UE and RAN/SGSN
6.2.3.1 RRC connection Release procedure

RRC: RRC Connection Release
www.actix.com
30
Figure 32 – Successful PS Signaling connection release – case 1
6.2.3.2 Signaling Connection Release procedure

RRC: Signaling Connection Release with PS domain indication
RRC: RB Release also explicitly indicates the release of the PS signaling connection
1
Only if RB Release is used RRC: Signaling Connection Release Request with PS domain
indication
RRC: Signaling Connection Release Request with PS domain indication
www.actix.com
31
6.2.4 Attributes for PS Signaling Connection

Attribute Values Triggers
Uu_PS_SigConn_Setup Successful After Initial direct Transfer (PS):

RRC: Security Mode Cmd (PS) or RRC
DL Direct Transfer (PS)
Failed After Initial direct Transfer (PS):

RRC: RRC Conn. Rel. or RRC: Sig.
Conn. Rel. (PS) or RRC: Sig. Conn.
Rel. Req. (PS)
Uu_PS_SigConn_Release Successful After Sig. Conn. is set up:

RRC: RRC Conn. Rel. or RRC: Sig.
Conn. Rel. (PS) or RRC: Sig. Conn.
Rel. Req. (PS)
After RB Release:
RB Release Complete
Failed RB Release Failure
Abnormal release After Initial direct Transfer (PS) or

Sig. Conn. is set up or RB Release:
RRC: RRC Conn. Req.
Uu_PS_SigComm_Duration Value in msec. Time elapsed between the successful

setup and the successful/abnormal
release of the PS Signaling
Connection
www.actix.com
32
6.3 GPRS Mobility Management event diagram (GMM) – UMTS

only
2
6.3.1 GMM procedures

Most of the GMM procedures are common to UMTS and GPRS. In this initial version of GMM
event diagram only the UMTS events are detected. The following GMM procedures are
analyzed:
• PS Attach
• PS Detach
• Routing Area Update
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
33
Successful PS Detach
2
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 GMM-
registered). 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
RAU request (n)
RAU Accept (m)
RAU complete1
Iu procedures
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
34
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. 2
6.3.2 Attributes for GMM

Succ_1_Attempt .. Succ_5_Attempt Attach Accept if this message includes P-TMSI
Attach Complete if preceding Attach Accept do not include P-TMSI The attempts refer to
the number of Attach Request messages sent
Uu_PS_Attach Rejected After Attach request: Attach Reject
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:
• PDP Context Activation
• PDP Context Deactivation

Limitations:
• PDP Context Modification events
www.actix.com
35
• 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 2
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
Request PDP context Activation1

Activate PDP Context Request
Iu procedures
Activate PDP Context Accept
New PDP Context
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
36
Successful Activation of a Secondary PDP Context

2
The only failure scenario detected for the PDP context Deactivation procedure is a missing
reply to the Deactivation Request:
• Deactivation request not replied (after the 5th attempt)
6.4.2 Additional notes Inter-RAT Handover and SM

This is a summary of scenarios occurring in PS Inter-RAT Handover (UMTS Q GPRS) that
are handled by the SM Event Diagram:
• 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 J
GPRS transition for a UEs in Cell_DCH or Cell_FACH state.
▫ A GPRS J 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 Q GPRS)
▫ Inter-RAT Handover to UTRAN (GPRS Q UMTS)
▫ Inter-RAT Cell Re-Selection to UTRAN (GPRS Q UMTS)
▫ Inter-RAT Cell Change Order to UTRAN (GPRS Q UMTS)
6.4.3 Attributes for SM

www.actix.com
37
Uu_PS_PDPAct_From_UE Succ_1_Attempt After Activate PDP Context

2
Request or Activate Secondary
PDP Context Request:
.. Activate PDP Context Accept
Succ_5_Attempt The attempts refer to the

number of Activate PDP
Context Request messages
sent by UE
Rejected_by_NW After Activate PDP Context

Request:
Activate PDP Context 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
Uu_PS_PDPAct_From_NW Succ_1_Attempt After Activate PDP Context

Request:
.. Activate PDP Context Accept
Succ_5_Attempt The attempts refer to the

number of Request PDP
Context Activation messages
sent by SGSN
Rejected_by_NW After Activate PDP Context

Request:
Activate PDP Context Reject
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 After Deactivate PDP Context

Request from UE:
www.actix.com
38
.. Deactivate PDP Context

2
Accept from SGSN or Activate
PDP Context Request or
Request PDP context
Activation
Succ_5_Attempt (NOTE: the last two cases are

used to cope with eventual
missing Deactivation Accept
message from the logs)
Aborted 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
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
Succ_5_Attempt (NOTE: the last two cases are

used to cope with eventual
missing Deactivation Accept
message from the logs)
Aborted After Deactivate PDP Context

Request from SGSN:
expiry of T3395 (after the 5th
attempt)
Uu_PDP_State PDP Act Request 1st Activate PDP Context

Request or 1st Request PDP
context Activation
PDP Deact Request 1st Deactivate PDP Context

Request (UE of SGSN)
in GPRS Cell Change Order from

UTRAN
No PDP 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
39
1 PDP
2
.. Number of PDPs active
3 PDPs
PDP_Session_ID 0..n Incremented every time a new

PDP Context is set up
Uu_TimeBetweenPDP_ReqAndAct Value in msec. Time between Activate PDP

Context Request (or Request
PDP Context Activation) and
Activate PDP Context Accept
Uu_TimeBetweenPDP_ReqAndDeactReq Value in msec. Time between Activate PDP

Deactivate PDP Context
Request
Uu_TimeBetweenPDP_ActAndDeact Value in msec. Time between Activate PDP

Request
Uu_TimeBetweenPDP_DeactReqAndDeact Value in msec. Time between Deactivate PDP

Context Request and
Accept
www.actix.com
Actix Analyzer PS Domain November 2004 Analysis Guide Appendix A 40
2
7 Appendix A
Attribute Description Unit Direction
Subscriber Session
Subscriber_Session_ID A unique ID for this Subscriber Identifier

Session
Event
Subscriber_Evt_Start_Session Generated on the first packet for a Event

Subscriber Session
Subscriber_Evt_End_Session Generated when the Mobile or Server Event

indicate the Subscriber Session is
over
Event Times
Subscriber_Time_Start_Session The time of Relative millisec

Subscriber_Evt_Start_Session
Subscriber_Time_End_Session The time of Relative millisec

Subscriber_Evt_End_Session
Context Session
Context_Session_ID A unique ID for this Context Session Identifier
Context_Duration_Session The duration of the Context Session Time
Event
Context_Evt_Start_Session Generated on the first packet for a Event

Context Session
Context_Evt_End_Session Generated when the Mobile or Server Event

indicate the Context Session is over
Event Times
Context_Time_Start_Session The time of Relative millisec

Context_Evt_Start_Session
Context_Time_End_Session The time of Context_End_Session Relative millisec
Service Session
Service_Session_ID A unique ID for this Service Session Identifier
Service_Protocol_Type The service type, eg HTTP, FTP, Protocol

POP3, SMTP, WAP or ICMP
Key Performance Indicators
Service_Duration_Session_Initiali The time it takes for the server to be Millisec

zation ready to serve a mobile's request for
data transfer
www.actix.com
Service_Perc_Packets_Retr_UL The percentage of packets that have Percent Uplink

2
been retransmitted
Service_Perc_Packets_Retr_DL The percentage of packets that have Percent Downlink

been retransmitted
Service_ThrPut_Fin_IncRetr_UL Final throughput including Kilobits per Uplink

retransmissions. Calculated only at second
the end of the service
Service_ThrPut_Fin_NoRetr_UL Final throughput not including Kilobits per Uplink

Service_ThrPut_Fin_IncRetr_DL Final throughput including Kilobits per Downlink

Service_ThrPut_Fin_NoRetr_DL Final throughput not including Kilobits per Downlink

Measure
Service_Duration_Data_Transfer_ The time the task was active Millisec

Delta
Service_Duration_Data_Transfer_ The sum of Millisec

Cum Service_Duration_Data_Transfer_Del
ta
Service_Duration_Session_Delta The time since the last task was Millisec

complete or the Service was
initialized. This can be used as
interarrival time between tasks.
Service_Duration_Session_Cum The time since Service was Millisec

Initialized. Calculated at the end of
Task and at the end on Service.
Service_Packets_Delta_IncRetr_U The number of packets transmitted Count Uplink

L in the completed task. This includes
retransmitted packets
Service_Packets_Cum_IncRetr_U The sum of packets transmitted in Count Uplink

L the completed tasks. This includes
Service_Packets_Delta_NoRetr_U The number of packets transmitted Count Uplink

L in the completed task. This does not
include retransmitted packets
Service_Packets_Cum_NoRetr_UL The sum of packets transmitted in Count Uplink

the completed tasks. This does not
Service_Bytes_Delta_IncRetr_UL The number of bytes transmitted in Bytes Uplink

the completed task. This includes
Service_Bytes_Cum_IncRetr_UL The sum of bytes transmitted in the Bytes Uplink

completed tasks. This includes
www.actix.com
Service_Bytes_Delta_NoRetr_UL The number of bytes transmitted in Bytes Uplink

2
the completed task. This does not
Service_Bytes_Cum_NoRetr_UL The sum of bytes transmitted in the Bytes Uplink

completed tasks. This does not
Service_Packets_Delta_IncRetr_D The number of packets transmitted Count Downlink

L in the completed task. This includes
Service_Packets_Cum_IncRetr_D The sum of packets transmitted in Count Downlink

L the completed tasks. This includes
Service_Packets_Delta_NoRetr_D The number of packets transmitted Count Downlink

L in the completed task. This does not
Service_Packets_Cum_NoRetr_DL The sum of packets transmitted in Count Downlink

the completed tasks. This does not
Service_Bytes_Delta_IncRetr_UL The number of bytes transmitted in Bytes Downlink

the completed task. This includes
Service_Bytes_Cum_IncRetr_DL The sum of bytes transmitted. This Bytes Downlink

includes retransmitted packets
Service_Bytes_Delta_NoRetr_DL The number of bytes transmitted in Bytes Downlink

the completed task. This does not
Service_Bytes_Cum_NoRetr_DL The sum of bytes transmitted. This Bytes Downlink

does not include retransmitted
packets
Event
Service_Evt_Start_Session Generated on the first packet for a Event

Service Session
Service_Evt_Incomplete_Start_S Generated when a start of the Event

essi on Service Session was not found
Service_Evt_Initialize_Session Generated when the Server has Event

acknowledged that it is ready to
service any request from the Mobile
Service_Evt_End_Session Generated when the Mobile or Server Event

indicate the Service Session is over
Service_Evt_Abort_Session Generated when the Mobile or Server Event

abnormally terminate the Service
Session, or a timeout occurs in the
Application Layer
Service_Cause_Abort The reason for abnormal termination Packet Data

of the Service Session Session
Ended/Task
Session Timeout
www.actix.com
Event Times
2
Service_Time_Start_Session The time of Relative millisec
Service_Evt_Start_Session
Service_Time_Initialize_Session The time of Relative millisec

Service_Evt_Initialize_Session
Service_Time_End_Session The time of Relative millisec

Service_Evt_End_Session
Task Session
Task_Session_ID A unique ID for this Task Session Identifier
Task_Perc_Packets_Retr_UL The percentage of packets Percent Uplink

retransmitted. Calculated only at the
end of the task
Task_Perc_Packets_Retr_DL The percentage of packets Percent Downlink

retransmitted. Calculated only at the
end of the task
Task_ThrPut_Fin_IncRetr_UL Final throughput including Kilobits per Uplink

the end of the task
Task_ThrPut_Fin_NoRetr_UL Final throughput not including Kilobits per Uplink

the end of the task
Task_ThrPut_Fin_IncRetr_DL Final throughput including Kilobits per Downlink

the end of the task
Task_ThrPut_Fin_NoRetr_DL Final throughput not including Kilobits per Downlink

the end of the task
Measure
Task_Duration_Session The duration of the Task Session Time
Task_Time_Delta_UL Time since last Application Data. This Time Uplink

can be used as interarrival time
between packets
Task_Time_Delta_DL Time since last Application Data. This Time Downlink

can be used as interarrival time
between packets
Task_Time_Cum_UL The sum of Task_Time_Delta Time Uplink
Task_Time_Cum_DL The sum of Task_Time_Delta Time Downlink
Task_Packets_Cum_IncRetr_UL The sum of packets including Count Uplink

retransmissions
Task_Packets_Cum_NoRetr_UL The sum of packets excluding Count Uplink

retransmissions
Task_Bytes_Delta_IncRetr_UL The number of bytes sent in this Bytes Uplink

packet including retransmissions
www.actix.com
Task_Bytes_Delta_NoRetr_UL The number of bytes sent in this Bytes Uplink

2
packet excluding retransmissions
Task_Bytes_Cum_IncRetr_UL The sum of bytes sent including Bytes Uplink

retransmissions
Task_Bytes_Cum_NoRetr_UL The sum of bytes sent excluding Bytes Uplink

retransmissions
Task_Packets_Cum_IncRetr_DL The sum of packets including Packets Downlink

retransmissions
Task_Packets_Cum_NoRetr_DL The sum of packets excluding Packets Downlink

retransmissions
Task_Bytes_Delta_IncRetr_DL The number of bytes sent in this Bytes Downlink

Task_Bytes_Delta_NoRetr_DL The number of bytes sent in this Bytes Downlink

Task_Bytes_Cum_IncRetr_DL The sum of bytes sent including Bytes Downlink

retransmissions
Task_Bytes_Cum_NoRetr_DL The sum of bytes sent excluding Bytes Downlink

retransmissions
Task_ThrPut_Inst_IncRetr_UL Instantaneous throughput not Kilobits per Uplink

including retransmissions. Calculated second
once a second
Task_ThrPut_Inst_NoRetr_UL Instantaneous throughput not Kilobits per Uplink

once a second
Task_ThrPut_Inst_IncRetr_DL Instantaneous throughput not Kilobits per Downlink

once a second
Task_ThrPut_Inst_NoRetr_DL Instantaneous throughput not Kilobits per Downlink

once a second
Task_Perc_Packets_Cum_Retr_UL The cumulative percentage of Percent Uplink

retransmitted packets. It is
generated each time a packet is
received
Task_Perc_Packets_Cum_Retr_D The cumulative percentage of Percent Downlink

L retransmitted packets. It is
generated each time a packet is
received
Event
Task_Evt_Start_Session Generated at the start of a Task Event

Session
Task_Evt_End_Session Generated at the end of a Task Event

Session
Task_Evt_Abort_Session Generated when on Packet Layer Event

abort or Application Layer timeout
Task_Cause_Abort The cause of the Task Abort Event
www.actix.com
Event Times
2
Task_Time_Start_Session Time of Task_Evt_Start_Session Time
Task_Time_End_Session Time of Task_Evt_End_Session Time
Packet Session
Packet_Session_ID A unique ID for this Packet Session Identifier
Packet_Direction The direction of this packet Uplink/Downli nk
Packet_Packets_Retr_Perc_UL Percentage of packet retransmissions Percent Uplink
Packet_Packets_Retr_Perc_DL Percentage of packet retransmissions Percent Downlink
Packet_Duration_Initialization The time it takes for the Server to be Time

ready to serve a Mobile's request for
data transfer
Packet_Duration_Close The time it takes for the Mobile or Time

Server to close the Packet Session
Measure
Packet_Packets_Cum_IncRetr_UL Packet count, including Count Uplink

retransmissions
Packet_Packets_Cum_NoRetr_UL Packet count, not including Count Uplink

retransmissions
Packet_Packets_Cum_Retr_Perc_ Percentage of packet retransmissions Percent Uplink

UL
Packet_ThrPut_Inst_IncRetr_UL Instantaneous Packet Throughput, Kilobits per Uplink

once a second
Packet_ThrPut_Inst_NoRetr_UL Instantaneous Packet Throughput, Kilobits per Uplink

not including retransmissions. second
Calculated once a second
Packet_Packets_Cum_IncRetr_DL Packet count, including Count Downlink

retransmissions
Packet_Packets_Cum_NoRetr_DL Packet count, not including Count Downlink

retransmissions
Packet_Packets_Cum_Retr_Perc_ Percentage of packet retransmissions Percent Downlink

DL
Packet_ThrPut_Inst_IncRetr_DL Instantaneous Packet Throughput, Kilobits per Downlink

once a second
Packet_ThrPut_Inst_NoRetr_DL Instantaneous Packet Throughput, Kilobits per Downlink

not including retransmissions. second
Calculated once a second
www.actix.com
Packet_Duration_Data_Session The duration of the Packet Data Time

2
Session, maximum of
Packet_Duration_Mobile_Data_Sessi
on and
Packet_Duration_Server_Data_Sessi
on
Packet_Duration_Mobile_Data_Se The duration of the Mobile Packet Time

ssion Data Session
Packet_Duration_Server_Data_Se The duration of the Server Packet Time

ssion Data Session
Packet_RTT_Server_Side Round-Trip Time it takes to send a Millisec

packet to the Server and come back
to the Mobile
Packet_RTT_Mobile_Side Round-Trip Time it takes to send a Millisec

packet to the Mobile and come back
to the Server
Packet_Bytes_Delta_IncRetr_UL The number of bytes sent in this Bytes Uplink

Packet_Bytes_Delta_NoRetr_UL The number of bytes sent in this Bytes Uplink

Packet_Bytes_Cum_IncRetr_UL The sum of bytes sent including Bytes Uplink

retransmissions
Packet_Bytes_Cum_NoRetr_UL The sum of bytes sent excluding Bytes Uplink

retransmissions
Packet_Bytes_Delta_IncRetr_DL The number of bytes sent in this Bytes Downlink

Packet_Bytes_Delta_NoRetr_DL The number of bytes sent in this Bytes Downlink

Packet_Bytes_Cum_IncRetr_DL The sum of bytes sent including Bytes Downlink

retransmissions
Packet_Bytes_Cum_NoRetr_DL The sum of bytes sent excluding Bytes Downlink

retransmissions
Event
Packet_Evt_Start_Session Generated on the first packet of the Event

Packet Session
Packet_Evt_Incomplete_Start_Se Generated when a start of the Packet Event

ssion Session was not found
Packet_Evt_Start_Data_Session Generated when the initialization Event

phase of the Packet Session is over
Packet_Evt_Mobile_End_Data_Se Generated when the Mobile indicates Event Uplink

ssion the Packet Data Session is over
Packet_Evt_Server_End_Data_Se Generated when the Server indicates Event Downlink

ssion the Packet Data Session is over
Packet_Evt_End_Data_Session Generated when both the Mobile and Event

Server has indicated the Packet Data
Session is over
www.actix.com
Packet_Evt_End_Session Generated when both the Mobile or Event

2
Server indicate the Packet Session is
over
Packet_Evt_Abort_Session Generated when the Mobile or Server Event

abnormally terminate the Packet
Session
Packet_Evt_Packet_Retransmitte This packet is a retransmission of Event

d some previous packet
Packet_Evt_Packet_Truncated This packet is truncated Event
Packet_Evt_Packet_Corrupted This packet is corrupted Event
Event Initiator
Packet_Initiator_Open The entity initiating the opening of Server/Mobile

the Packet Session
Packet_Initiator_Close The entity closing the Packet Session Server/Mobile
Packet_Initiator_Abort The entity aborting the Packet Server/Mobile

Session
Event Times
Packet_Time_Start_Session Time of Packet_Evt_Start_Session Time
Packet_Time_Start_Data_Session Time of Time

Packet_Evt_Start_Data_Session
Packet_Time_End_Data_Session Time of Time

Packet_Evt_End_Data_Session
Packet_Time_Mobile_End_Data_S Time of Time Uplink

ession Packet_Evt_Mobile_End_Data_Sessio
n
Packet_Time_Server_End_Data_S Time of Time Downlink

ession Packet_Evt_Server_End_Data_Sessio
n
Packet_Time_End_Session Time of Packet_Evt_End_Session Time
www.actix.com
Actix Analyzer PS Domain November 2004 Analysis Guide Appendix B 48
2
8 Appendix B
www.actix.com
www.actix.com
www.actix.com
4103, 4128
www.actix.com

PS Domain Analysis Guide PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PS Domain Analysis Guide PDF

Uploaded by

Copyright:

Available Formats

PS Domain

2 SERVICE ANALYSIS .....................................................................................5

3 AGGREGATION LEVELS AND TRACKERS ..............................................................6

4 TRIGGER POINTS AND KEY PERFORMANCE INDICATORS ..........................................9

5 ANALYSIS EXAMPLES ...................................................................................9

6 ADDITIONAL RADIO EVENTS FOR THE PS DOMAIN IN UMTS ....................................9

• Application of generic KPIs to different interfaces and services, thereby

In the following sections, these elements will be analyzed in more detail.

• From a network point of view (so per network elements)

• From a 'user experience' point of view

Subscriber Id - Yes Yes - -

Mobile IP Address Yes Yes Yes Yes Yes

PdP Context Id No Yes Yes - -

Service Id Yes Yes Yes Yes Yes

Task Id Yes Yes Yes Yes Yes

Packet Session Id (TCP/UDP/WTP) Yes Yes Yes Yes Yes

IP Session Id Yes Yes Yes Yes Yes

IMPORTANT: the trackers are available in traces containing IP packets:

• Protocol analyzer files3

3.1 Subscriber level

3.2 Context level

3.3 Service level

• 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

The Service_Session_Id is created for the scope.

3.4 Task level

• 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

3.5 Packet level

UDP is currently not implemented.

• Interactions among service, task and packet levels.

Figure 1 - Session levels and attributes

Figure 2 - Service Session durations (all attributes have a prefix “Service_”)

Figure 3 - Packet Session durations (all attributes have a prefix “Packet_”)

The attributes are organized in groups (see Figure 4):

• General attributes (like the session identifiers).

• Key Performance Indicators (like overall throughput with and without

Figure 4 - Applications’ attribute tree

• Identify quickly those cases with poor performance.

5.1 Statistical analysis of the traces

5.1.1 Sample Gb file

• Packet (normally too detailed for a statistical analysis)

Figure 5 – Statistics of attached subscribers

Figure 6 – Active subscribers per application

Figure 7 – Active context per trace

Figure 8 – Service summary

Figure 9 – Subscriber and service report

Figure 10 – Other KPIs

Figure 11 – Service summary

5.1.2 Sample Gn file

Figure 12 – Subscribers per trace

Figure 13 – Active subscribers per application

Figure 14 – PDP Context

Figure 15 – Service report

Figure 16 – Packet report

Figure 17 – Protocol Stack Browser

5.2 FTP Transfer

Figure 18 – FTP example, Service summary

Figure 19 – FTP example, Service Abort

Figure 20 – FTP example, Service details