Usually the performance measurement equipment is able to automatically detect to which specific interfaces a probe is connected and which protocol stacks are necessary to decode captured data. If necessary it can also detect on which particular channel data is transmitted. This especially refers to dedicated and common transport channels on the Iub interface. In addition, it can be assumed that the same equipment also provides a function that is commonly known as call trace, which allows for the automatic detection and filtering of all messages and data packets belonging to a particular connection between a single UE and the network.
Within UTRAN four interfaces exist where performance-related data can be captured: the Iub interface between Node Bs and RNC; the Iur interface between different RNCs; the IuCS interface between RNCs and the CS core network domain; and the IuPS interface between RNCs and the PS core network domain. For each interface a specific protocol stack is necessary to decode all layers of captured data.
The approach is to count all connections in a cell and provide a set of sub-counters that is able to distinguish which services are used during these connections. From a subscriber’s perspective this scenario is simple. They switch on their mobile phones, set up calls, walk around or drive by car (which could result in a couple of mobility management procedures) and finish their calls whenever they want. Now from a network operator’s perspective it is necessary to find out in which cell the calls are active and identify the type of service related to each particular call. It sounds easy, but due to the specific nature of the UTRAN procedure it is indeed a fairly complicated analysis.
When the term ‘service’ is used in the context of performance measurement this usually applies to end-user services such as voice calls, data calls and – if available in network and if the UE is capable – video-telephony calls. All kinds of supplementary services such as conference calls or multi-party connections are seen as special cases of the above categories and are not analysed in detail. However, when looking at data calls the type of service can also be determined from the TCP/IP application layer, e.g. file transfer (FTP) or web browsing (HTTP). These specific services are beyond the scope of this basic approach for two reasons. Firstly they require a more complex correlation of measurement data, secondly it makes no sense to define a TCP/IP analysis at cell level, because even the smallest email or website is segmented by the RLC into a number of different transport blocks and theoretically each transport block set can be transmitted using a different cell.
A CS call set up always starts with a Call Control Setup message as specified in 3GPP 24.008. The ‘decision maker’ that distinguishes between voice calls and video-telephony calls is the value of the bearer capability information element within this Setup message. If the bearer capability information element shows the value ‘unrestricted digital info’ the call is a video-telephony call. Another indicator is the signalling access protocol I.440/450 and rate adaptation following H.223 & H.245 mentioned in the same message. It is difficult to explain what a bearer is. Maybe the following definition is the best one: A bearer is a temporary channel used to transport a data stream (user or network data) with a defined quality of service.
This is true for both GSM and UMTS, but in UMTS the bearer concept covers all possible data streams in each part and layer of the network while in ISDN/GSM it is only used to define the characteristics of traffic channels between subscribers. A service from the point of view of UTRAN is always bound to a certain type of (radio) bearer and hence, analysing characteristics of UMTS bearer services is another possible definition of ‘call type’.
Looking back to the specific signalling used between the UE and the CS core network domain it emerges that in contrast to video-telephony calls voice calls have the bearer capability value ‘speech’ in the Call Control Setup message. A PS connection (data call) always starts with a Service Request message. This Service Request indicates that there is data (IP payload) to be transmitted, but it should be noted that this definition might not always fit to the user’s perspective of an active PS call.
Imagine a subscriber starting a mobile web-browsing application. For this purpose a PDP context is established between the UE and the SGSN and a traffic channel, which is called the radio access bearer (RAB) is provided.
Now a website is downloaded and the user starts to read its contents. This may take a while. Besides the user may switch to another application while keeping the web-browser open. This is not a problem in fixed data networks. IP data is only transmitted when necessary, if there is no data transfer no network resources of the fixed line are occupied. That does not apply to UTRAN. Here dedicated resources (these are the codes used to identify channels on the radio interface) need to be provided for each RAB. And those resources are limited. That is the reason why the network needs to identify which resources are really used.
All other resources are released to prevent shortage and guarantee subscriber satisfaction. This leads to a situation that a PDP Context that is bound to the open web-browsing application remains active in the UE and SGSN while a RAB is released if the network detects that no data is transmitted for a certain time. Based on this a PS connection in UTRAN is defined, whereas an active PS RAB and RAB assignment is always triggered by a Session Management Service Request message. RABs are also set up for CS connections, but for conversational calls they are active as long as a call is active. Indeed, there are several ways to count the number of active connections, which means that there are different protocol messages from different protocol layers.
To complete the call type definition, ‘signalling’ constitutes all call flows between the UE and core network domains that do not contain Setup or Service Request messages. It is also necessary to define another category that is usually called ‘Multi-RAB’ and describes a UE that has at least two active connections (RABs) simultaneously. Multi-RAB calls can be a combination of CS and PS services for one UE, but multiple PS RABs are also possible, for instance if PS streaming video requires the set up of a secondary PDP context that triggers the establishment of a second PS RAB for the same UE. This second RAB provides a different traffic class (= different delay sensitivity) and different maximum bit rates. An example for such a kind of Multi-RAB PS+PS would be a GPRS session management message Activate Secondary PDP Context Request.
Protocol events used to determine the call type cannot immediately be used to count the number of active connections, because they only describe connection attempts. Therefore, it is necessary to check if the attempted connection has been set up successfully. This can be done on the RRC, RANAP or NAS layer. On the Iub interface the RRC Radio Bearer Setup Complete message indicates that a traffic channel has been established successfully. Following this the RANAP RAB Assignment Response is sent on the Iu interface while the NAS layer indicates that the connection between A-party and B-party has been established. For PS calls the session management Service Accept and PDP Context Activation Accept messages could be used as additional indicators for a successful connection. It should be noted that in the case of video telephony calls via the CS domain in-band signalling is also necessary to really get the service running. This in-band signalling is transmitted using the radio (access) bearer and the example proves that there are different perspectives of user and network and it clarifies the need to have different KPIs for those different perspectives.
Having defined the necessary set of counters to determine the number of active connections, it is important to find out which calls are active in which cell.
When counting the messages on Iu interfaces there is actually no chance of finding a relationship between call and cell. There is only one identifier that allows a very vague estimation of the cell by using the service area code (SAC), which is part of the service area identity (SAI). A single SAC represents a single cell according to the definition in the numbering plans of most UMTS network operators. Normally it is the cell in which the UE is located when the call is set up. This cell can easily be detected on the Iub interface, because the first message of each call (RRC Connection Request or RRC Cell Update – on the basis that Paging messages only trigger calls) is always sent on the random access channel (RACH) and there is always one and only one RACH assigned to each cell. A problem is caused by the following. When the first message of a call is monitored on the RACH there is no identifier that indicates which cell this RACH is related to. Certainly the CRNC knows which RACH belongs to which cell, but this correlation can only be monitored when the RACH is installed immediately after the Cell Setup procedure. It remains unknown as long as the channel is not deleted and re-established or reset. Hence, cell ID related to RACH must be found by monitoring the system and using an indirect algorithm. This algorithm is based on the fact that one or more forward access channels (FACHs) belong to the same cell as the RACH and the messages sent on an FACH are called RRC Connection Setup or Cell Update Complete. These messages contain a cell identifier and have a 1 : 1 relationship with RRC Connection Request or RRC Cell Update Request messages previously monitored on the RACH. Using this principle the cell identity related to a certain RACH can be investigated and the results are stored in a special database of the performance measurement system. This database is often named the ‘topology module’. It contains necessary information to correlate protocol events with network elements and their identifiers. Due to the fact that the phone is a mobile it moves and may change the cell, which causes another problem. The footprint of UMTS cells is on average 10 times smaller than the footprint of GSM cells and therefore cell changes, called ‘handovers’ in UMTS, occur much more often. In addition, most currently deployed UMTS networks in Europe and North America work in FDD mode. FDD stands for frequency division duplex and means that the uplink and downlink channels use different frequency bands. This applies for instance for the already mentioned RACH (uplink) and FACH (downlink).
If the analysis target is to find out how many connections are active in each cell it is necessary to track the mobility of each single UE in the network, because the number of connections per cell depends on the location of the UEs. Due to this fact a relatively simple counter already requires highly sophisticated measurement applications and it is not enough just to count some
Within UTRAN four interfaces exist where performance-related data can be captured: the Iub interface between Node Bs and RNC; the Iur interface between different RNCs; the IuCS interface between RNCs and the CS core network domain; and the IuPS interface between RNCs and the PS core network domain. For each interface a specific protocol stack is necessary to decode all layers of captured data.
