Measuring Speed and Download times

Measuring Speed :

There are two measures for the size of a file: bits (b) and bytes (B). Communication engineers think in terms of transferring bits, whereas computer users think in terms of file sizes, which are usually measured in Bytes (such as kilobytes, megabytes, etc). There are eight bits to one byte.

The data rate determines how long it will take to transfer a file. The larger the file, the longer it takes, because there is more information to transfer. Data transfer rates are measured in thousands of bits per second (kbps) or millions of bits per second (Mbps). Notice, that in the kbps acronym, a lower case k is used instead of the upper case K. This is because when talking about the transfer of data, most engineers round the number down. So a kbps actually refers to the transfer of 1000 bits of information in one second, whereas a Kbps would refer to the transfer of 1024 bits of information in one second. A DSL or a cable modem can operate in ranges of 512 kbps, 2 Mbps or higher depending on the technology being used.

Download Times:

Calculated download times are theoretical and depend on cable connection, computer processor speed and other overheads. To get an estimate of the length of time it takes to download a file, divide the file size by the data rate. For example, how long will it take to transfer a low resolution digital photo of 256KB via a 512kbps cable connection? First step, convert the file size into bits: 8 x 256 x 1024 = 2097152 bits. 256KB corresponds to 2097 kb. Notice that the 2097152 is rounded to the nearest 1000, so lower case k is used. The download time is then 2097 kb divided by 512 kbps, which equates to approximately 4 seconds.

Measuring speed throughput

UMTS QoS Architecture

3GPP TS 23.107 describes the QoS concept and architecture. In addition, it provides QoS parameters based on the UMTS bearer service. To ensure the QoS of a network, bearer services with explicit attributes and functions must be set up between the transmitter and the receiver. A bearer service involves all the aspects that are required to ensure specific QoS. These aspects are included in control plane signaling, user plane transmission and QoS management.

UMTS QoS Architecture

As shown in the picture, the traffic from one terminal equipment (TE) to another passes different levels of bearer services. The TE is connected to the UMTS network through a mobile terminal (MT). The end-to-end service at the application layer is implemented through the bearer services of the underlying networks. The end-to-end service consists of the local bearer service, UMTS bearer service, and external bearer service. These services ensure the QoS of the end-to-end service. They are described as follows:

•  The local bearer service is beyond the UMTS research scope.
•  The external bearer service is coordinated by the telecom operator with the connected networks. Between the UMTS bearer service and the external bearer service, QoS mapping is required. Through the QoS mapping, the QoS requirement is sent to the next network element (NE).
• The coordination and QoS mapping between UMTS bearer services is very important for implementing the end-to-end QoS of UMTS.

The UMTS bearer service consists of the radio access bearer (RAB) service and the core network bearer (CNB) service. 

The RAB service is implemented through the radio bearer (RB) service and Iu bearer service. The RB service covers all the aspects of the transmission on the radio interface, and the Iu bearer service provides the transmission between the UTRAN and the CN. For PS services, the Iu bearer service can provide different QoS classes. 

The role of the CNB is to provide a negotiated UMTS bearer service. The CN provides different QoS classes for different backbone bearer services. A specific backbone bearer service can be selected to meet the QoS requirement of the CN bearer service. 

The RAB service involves the Uu, Iub, Iur, and Iu interfaces.

QoS Architecture UMTS

3G/UMTS complete MO-CS Call Setup flow

CS Call setup message flow.

1. System Information (BCCH) 

The UE reads the System Information that is broadcast on BCCH. The information is not read continuously. It is only read if the information changes 

2. RRC: RRC Connection Request (CCCH) 

The Mobile user decides to initiate a voice call. The first message the UE will send on CCCH is RRC Connection Request. This will contain among other things, Initial UE Identity and Establishment Cause 

3. NBAP: Radio Link Setup Request 

The SRNC sends this message to Node B. It will pass the Cell Id, TFS, TFCS, frequency, UL Scrambling code, etc to Node B.

4. NBAP: Radio Link Setup Response 

Node B allocates the resources and starts PHY Reception. While transmitting the response it includes the Transport layer addressing information that includes the Binding Identity of the AAL2 for Iub data transport bearer

5. ALCAP: Establish REQ 

The AAL2 binding identity (Iub Data Transport Bearer Id) is passed to ALCAP protocol in Node B. The Iub Data Transport bearer is now bounce to DCH. 

6. ALCAP: Establish CNF 

Establish confirm from ALCAP in Node B

7: DCH-FP: Downlink Synchronization 

The Node B and SRNC establishes synchronization for the Iub Data Transport bearer by means of exchange of the appropriate DCH Frame Protocol frames.

8: DCH-FP: Uplink Synchronization 

Once the UL synchronization is achieved, Node B starts DL transmission.

9: RRC: RRC Connection Setup (CCCH) 

RRC Connection Setup message is sent on CCCH with the parameters required to establish DCH. Also the state indicator will be set to DCH for the voice (or CS) call.

10: NBAP: Radio Link Restore Indication 

Once the UE establishes Radio Link, Node B will send RL Restore indication to the SRNC.

11: RRC: RRC Connection Setup Complete (DCCH) 

RRC Connection Setup complete will be sent on DCCH. Integrity and Ciphering related parameters and UE capability information will be sent back to SRNC

12: RRC: Initial Direct Transfer (CM Service Request) 

First NAS message is now sent by the UE. It indicates that a UE originated Voice call is required. The UE identity (TMSI) will also be passed in this message

13: RANAP: Initial UE Message (CM Service Request) 

The NAS message will be forwarded to appropriate CN Domain (CS Domain in this case). Along with the CM service request, it will also include LAI and SAI.

14: RANAP: Direct Transfer (Authentication Request) 

MSC/VLR needs to perform authentication to make sure that the UE is genuine. For this reason it will challenge the UE with a Authentication token and RAND (random number)

15: RRC: Downlink Direct Transfer (Authentication Request)

SRNC transfers the NAS message to the UE

16: RRC: Uplink Direct Transfer (Authentication Response)

UE computes the response (RES) and sends it back in the NAS message

17: RANAP: Direct Transfer [Authentication Response] 

SRNC relays the response to the MSC/VLR. The MSC/VLR will compare the response RES with the expected response XRES. If they are the same then the procedure will continue.

18: RANAP: Security Mode Command 

MSC/VLR sends the Security Mode Command to start Ciphering and Integrity Protection. Ciphering is optional while Integrity Protection is mandatory. The Algorithms, etc are known to the MSC/VLR and the UE and only the ones that are common between them are used.

19: RRC: Security Mode Command 

RRC Forwards the Security Mode command received from MSC/VLR to the UE.

20: RRC: Security Mode Complete 

The UE configures the Ciphering and Integrity Protection and responds back to the network. The response message is Integrity Protected for further safety. Ciphering is started at Ciphering activation time. Since this is a Circuit switched call, the Ciphering will be started in MAC. In case of AM and UM bearers it is started in RLC.

21: RANAP: Security Mode Complete 

The network forwards the Security Mode Complete message to MSC/VLR.

22: RANAP: Direct Transfer (TMSI Reallocation Command)

The network may decide to re-allocate the TMSI to the UE. It sends a DT message which includes the NAS TMSI Reallocation Command.

23: RRC: DL Direct Transfer (TMSI Reallocation Command)

The RNC relays the DT message to the UE.

24: RRC: UL Direct Transfer (TMSI Reallocation Complete)

The UE takes the new TMSI and responds with the Complete message

25: RANAP: Direct Transfer (TMSI Reallocation Complete)

The RNC relays the message to the CN domain

26: RRC: UL Direct Transfer (Setup)

The UE now sends the 'Setup' message in UL Direct Transfer message. This will include all the required parameters for setting up the voice call. It will include the number that UE wishes to be contacted and the bearer capability

27: RANAP: Direct Transfer (Setup)

The network relays the message to the MSC/VLR

28: RANAP: Direct Transfer (Call Proceeding)

The MSC/VLR sends Call Proceeding to the UE indicating that it is now starting with the RAB establishment procedure.

29: RRC: DL Direct Transfer (Call Proceeding)

The network relays it to the UE.

30: RANAP: RAB Assignment Request 

The CN initiates establishment of the Radio Access Bearer using the RAB Assignment Request message. This message includes the QoS of the call being established, the Transport Address, Iu Transport association, etc.

31: ALCAP: Establish REQ 

SRNC initiates the set-up of Iu Data Transport bearer using ALCAP protocol. The request contains the AAL2 Binding Identity to Bind the Iu Data Transport Bearer to the RAB. (Note that this is not done in case of PS RAB)

32: ALCAP: Establish CNF 

The CN responds with the ALCAP Establish CNF

33: NBAP: Radio Link Reconfiguration Prepare 

SRNC requests Node B to prepare establishment of DCH to carry the RAB. It passes the TFS, TFCS and Power Control Information in the message.

34: NBAP: Radio Link Reconfiguration Ready 

Node B allocates the resources and responds with the Ready message. It sends back the AAL2 address and the AAL2 binding Id for the Iub data transport bearer.

35: ALCAP: Establish REQ 

SRNC initiates setup of Iub Data Transport Bearer using ALCAP protocol. The request contains the AAL2 Binding Identity to bind the Iub Data Transport Bearer to DCH.

36: ALCAP: Establish CNF 

The Node B responds with the Establish Confirm.

37: DCH-FP: Downlink Synchronization 

The Node B and SRNC establish synchronism for the Iub Data Transport Bearer by means of exchange of the appropriate DCH frame protocol frames. SRNC sends the DL Synchronization frames.

38: DCH-FP: Uplink Synchronization 

The Node B responds with the UE Synchronization frames.

39: NBAP: Radio Link Reconfiguration Complete 

Finally the SRNC instructs the Node B of the CFN at which the new configuration will come into effect. 

40: RRC: Radio Bearer Setup 

SRNC sends the RB Setup message to add the new DCH's. The message will be received using the old configuration.

41: RRC: Radio Bearer Setup Response 

After the activation time the UE will respond with complete message using the new configuration.

42: RANAP: RAB Assignment Response 

The SRNC responds with the response to the MSC/VLR. 

43: ISUP: Initial Address Message 

MSC/VLR sends the Initial Address Message to the PSTN. The message tells the PSTN to reserve an idle trunk circuit from originating switch to the destination switch. 

44: ISUP: Address Complete Message 

The ACM message is sent to indicate that the remote end of the trunk circuit has been reserved.

45: RANAP: Direct Transfer (Alert)

The Alert message is sent to the SRNC. This message contains the ACM received from the PSTN.

46: RRC: Direct Transfer (Alert)

The Alert message is forwarded to the UE. The Alert message will initiate the ringing tone on the handset.

47: ISUP: Answer Message 

When the person that is being called picks up his phone, an Answer message is sent to the MSC/VLR. 

48: RANAP: Direct Transfer (Connect)

The MSC/VLR sends the Connect message to the SRNC via Direct Transfer message. The Connect message indicates that the End User has answered the call. 

49: RRC: DL Direct Transfer (Connect)

The SRNC forwards the Connect message to the UE.

50: RRC: UL Direct Transfer (Connect Acknowledge)

The UE confirms the reception of the Connect message using the Connect Acknowledge and sending it via Direct Transfer

51: RANAP: Direct Transfer (Connect Acknowledge)

The Network forwards the Connect Acknowledge to the MSC/VLR. The call has now been successfully established.

3G/UMTS complete message flow Mobile Originate Call Setup

Non-Access Stratum (NAS)

The non-access stratum(NAS) includes the protocols outside the access stratum,i.e. the protocols not related to the transport of user data or network signaling. They concern all data and signaling messages exchanged between the UE and the CN independently on the radio access technology implemented within the UMTS network. The UTRAN does not analyze these NAS messages and just plays the role of a relaying function. The user plane in NAS comprises basically user application protocols generating data streams to be transported by AS, that may or not adhere to GSM/UMTS standards. On the other hand, the NAS control plane encompasses all the protocols associated to Connection Management(CM) and Mobility Management (MM) functions for circuit-switched services, and Session Management(SM) and GPRS Mobility Management(GMM) functions for packet-switched services.

NAS (non-access stratum)

The NAS is a function layer running between the User Equipment(UE) and the Core Network(CN). The layer support traffic and signalling messages between CN and UE.

NAS(Non-Access Stratum)

Introduction to QoS

Quality of Service (QoS) is possibly the single most important concept in the field of optimization for Packet Switched networks. The Circuit Switched networks also have a mechanism to manage the quality of the service, which is well known and well established a long time ago. The dimensioning of the number of available circuits or channels in a given network node or associated interface is done according to the criteria known as blocking probability, which can be used in the Erlang formula. However, this approach no longer
serves the purpose of the packet switched networks, where multiple services are meant to use the same network resources while having essentially different characteristics and requirements. This fact was acknowledged a long time ago, and the basic IP protocol includes a field to mark every packet according to the type of service it is conveying, known as the differentiated services code point (DSCP), which is a 6-bit field in the IP header that determines the per hop behavior. Thus, the field can be used by the switches and routers in the network in order to prioritize traffic flows according to their tolerance to delay, jitter and packet losses. These were the known mechanisms, and the initial phase of deployment of radio access mobile networks, when GPRS appeared in the late 1990s and, soon after, UMTS, already had a more refined specification providing QoS mechanisms from its creation.

1. QoS Environment
It is clearly understood that in a mobile network the major constraints can be easily located in the radio access network, which is especially true in terms of QoS, where maximizing the utilization of the limited radio resources and prioritizing the different traffic flows according to their nature is a complex task. However, the QoS concept in a mobile packet core network is, in principle, easier to understand and build, at least conceptually. Nevertheless, current traffic volumes in most operators are such that the benefits of a QoS mechanism are not clearly perceived from a core network point of view. With current levels of utilization of the network nodes in terms of traffic, the most likely scenario is that the mobility management and session management procedures offer the most limiting load to the system, hitting the capacity roof of the network
nodes before the traffic volumes reach such levels that prioritization of traffic according to their nature can take place. This fact will have a major impact on the optimization process.

2. QoS Process
Specifications for 3G define four traffic classes ( conversational, streaming, interactive and background) and also specify in more detail other QoS attributes such as the maximum bit rate, guaranteed bit rate, maximum transfer delay, maximum delay variation and bit error rate. The specifications have actually been gathered in a table where the QoS requirements are defined in detail. This QoS detailed parameter table is the starting point of the QoS network implementation design and is closely related to the concept of service creation. Moreover, during the creation of a new mobile application, the QoS aspects are the major concern from the network point of view, since there is a need for an end-to-end approach for proper QoS deployment that cannot be limited to a given network subsystem. During the network planning phase, the QoS is one of the aspects to be considered, but from a rather general approach, ensuring its deployment and functionality from a network design perspective. Only when new mobile applications are to be introduced does the QoS concept trigger attention, especially with those applications that generate more demanding traffic flows, such as video streaming. The sensible process consists of verifying the capability of the packet core network nodes to deal with the traffic created with the introduction of a new application, which may end in a new dimensioning exercise. Once the verification and eventual re-dimensioning takes place, the packet core network is ready for the end-to-end QoS implementation for the given new application. In this process, the packet core network takes a secondary role, since the most restrictive subsystem is the radio access network. However, there is a need to consider the process from an end-to-end perspective; otherwise there is a substantial risk of missing a link in the complex chain. It can be argued that the QoS is either an essential optimization process or a powerful optimization tool, but it seems clear that the QoS is an end-to-end matter and can significantly contribute to increasing the network and end user performance in given situations.

3. Role of the Packet Core Network in the QoS Process
Normally, the main packet core network nodes, SGSN and GGSN, provide different treatments for the different traffic classes defined by 3GPP by means of implementing in those nodes some of the known functions in this area, such as queuing and shaping. The complexity is mostly in the network node design in order to deal with the expected traffic flows. Normally, there are few possibilities of tuning network node QoS parameters in order to increase the performance. Configuration of queues is one possibility, tuning the relative sizes of the queues for the different traffic classes according to the current traffic mix in terms of traffic classes. An other possibility is to tune or redefine the marking of the packets in the differentiated services code point (DSCP) field of the IP header in order to optimize the IP routing within a large and complex packet core backbone, perhaps also having multi protocol techniques in use such as the MPLS for a more efficient handling of backbone traffic. However, it is difficult to provide concrete advice
on this matter, since it is very dependent on the concrete network node implementation characteristics (some of which may not leave a margin for optimization) and the concrete backbone design (which in some cases may not be subjected to optimization).

4. Role of the HLR in the QoS Process
There is another network node that is not usually considered under the scope of a mobile packet core network but performs some of the fundamental functions and hosts some of the fundamental data for operation of the network. The HLR, one of the core network nodes, definitely plays a major role in the QoS process. It hosts all the QoS relevant parameters from a subscription point of view, at two levels: firstly, on a subscriber basis (which are determined combinations of QoS parameters), and, secondly, on an application basis (which are the QoS parameters required for a given application), normally defined per APN. The QoS parameters stored in the HLR are used during activation of the PDP context and are thus utilized for the duration of it, unless a PDP context modification takes place. When designing new services, the service subscription data stored in the HLR has to be carefully analyzed. A simplified structure of the QoS parameters is required in order to deal with the complexity of the possible combinations. Normally, a given set of parameters that are meaningful for that given application will be created as a QoS template or QoS profile, and that template will be re-used for a group of subscribers (e.g. premium, normal or prepaid) when using the given application (e.g. browsing, messaging or streaming). Thus, when a premium subscriber invokes a streaming service, he/she will be granted a PDP context with a certain set of parameters, which can be slightly different from those granted for a prepaid Subscriber when using that service if the operator has so defined the access differentiation. Alternatively, the data can be structured so that the differentiation is performed only based on the application. Since the only application data available in the HLR is the APN, it can be problematic to introduce QoS differentiation when more than one application shares a common APN. The problem can obviously be solved by allocating a dedicated APN per application. This solution, in turn, leaves the subscriber with a provisioning problem, giving him/her the responsibility of selecting the correct APN when using different mobile applications. This situation does not help the adoption of new services. In order to overcome this limitation, service awareness can be introduced, both in the mobile terminal and in the GGSN hosting the APN. In the latter case, new additional aspects should be considered during the planning phase of this type of GGSN node.

5.  QoS Performance Management
The previous section gives a good understanding of the complexity of handling QoS in the context of different users and different services, based on a simplified approach of utilizing templates or profiles for redetermined sets of QoS parameters. This complexity has been an inherent part of the concept from the standardization phase, a notable example being the different sets of parameters standardized in release 97/98 of the 3GPP specifications and the parameters standardized in release 99 of the same 3GPP specifications. Therefore, the different sets require a proper mapping between the parameters. However, the amount of parameters and their possible values, originally proposed for providing great flexibility during the service design, create such a large amount of possible combinations of parameters that it would potentially make the performance management of a given service impossible. In turn, without an adequate level of performance management capabilities, the task of ensuring consistent levels of service quality for a given application to subscribers is close to impossible. Moreover, without that kind of quality assurance, the ultimate goal of ensuring the quality of experience (QoE) of the subscriber is uncontrollable from the network perspective. Hence there is a need for an adequate setup for proper QoS performance management in the network. QoS performance management alone will not be sufficient to satisfy the QoE goals, since the QoE can only be quantified from the mobile station point of view, typically through end-to-end testing campaigns or mobile probes deployed in significant places of the network coverage. However, without QoS performance management, the perceived QoE is close to useless in the context of optimization, since no correlation can be studied between the QoS and QoE. The logic connection among those concepts can be expressed in the following process flow:
- The ultimate goal is to ensure a satisfactory QoE, measured through so-called QoE KPIs.
- The operator tool to ensure that goal is the mobile network.
- The closest perception of service performance in the mobile network is provided by the performance of the QoS, which can be quantified as QoS KPIs.
- The operator needs a simple mechanism to collect service based QoS KPIs.
- Once those service based QoS KPIs are collected from network elements and/or interfaces, they can be analyzed.
- The closest perception of service performance in the terminal side is the QoE, which can be quantified as QoE KPIs.
- The operator needs a simple mechanism to collect service based QoE KPIs. Currently the possibilities are field test campaigns and field probes.
- Once those service based QoE KPIs are collected from field probes or end-to-end testing campaigns, they can be analysed accordingly.
- Eventually, from both parallel analyses, correlations can be found and improvement actions can be decided within the reach of current possibilities.
The main difficulties are two:
      - to provide a simplified mechanism to collect those service based KPIs;
      - to build meaningful correlations between service based QoS KPIs and their corresponding service based QoE KPIs.
The first difficulty can only be partially solved through a thorough study and definition of the meaningful QoS attributes that are relevant from an end user perspective and deep alignment of the OSS concept with the network nodes. This will provide a simple context of a few meaningful KPIs that can be uniquely associated to a given service or application. Some vendors in the industry are already exploring this area, with promising results. The second one is certainly uncharted territory, where only experience can provide enough of a knowledge base for successful correlations. As an example, it is worth formulating the problem in concrete terms, as follows:
- QoE KPIs. An end-to-end measurement campaign for streaming with 100 service access requests during the busy hour of a weekday gives the result of a service accessibility of 97 %.
- QoS KPIs. During the same measurement period, the OSS registers for the aggregated streaming traffic a service accessibility of 99.6 %, out of a total of 5873 service requests. What kind of conclusions can be extracted from those KPIs? Is access to the streaming service performing well or badly? Can the fault be associated with a given fact, geographical location, type of terminal or even type of content accessed within the given service? Answers to these questions can only be given as a result of the correlation of QoS KPIs and QoE KPIs, which will be greatly influenced by local factors and may not easily be generalized. Certainly, as time goes by and operators accumulate experience, these questions will be at least partially solved. In this context, it is worth noting that by measuring QoE KPIs and evaluating them, the problem of improving the QoE, which is the ultimate goal, will not be solved.It is relatively easy in this complex environment to confuse the process with the goal and with the risk of finishing the process short of achieving the goal. Giving a pointer towards a generic cause of bad performance is part of the process (e.g. 97 % of service accessibility is not acceptable as the cause might be in the congested packet core network node). Fully identifying the cause and enabling the solution is certainly closer to achieving the goal (e.g. while the value of 97 % of service accessibility was registered in a given radio access area, the overall aggregated value of 99.6 % of service accessibility strongly suggests that this is closely related to the geographical area where the tests were performed, further investigation showing that the RNC under consideration presented some misconfigurations affecting the handling of QoS parameters that were under investigation). Additionally, this example also illustrates the necessity for an end-to-end approach to the QoS issues.

Introduction to QoS

The four classes of QoS in UMTS

UMTS QoS Classes

When defining the UMTS QoS classes, also referred to as traffic classes, the restrictions and limitations of the air interface have to be taken into account. It is not reasonable to define complex mechanisms as have been in fixed networks due to different error characteristics of the air interface. The QoS mechanisms provided in the cellular network have to be robust and capable of providing reasonable QoS resolution. Table 1 illustrates the QoS classes for UMTS.

There are four different QoS classes:

-    Conversational class;

-    streaming class;

-    Interactive class; and

-    Background class.

UMTS QoS classes