 |
| 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.
|
Wednesday, January 30, 2013
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.
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) |
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.
Monday, January 21, 2013
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.
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.
Tuesday, January 15, 2013
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.
Subscribe to:
Posts (Atom)
