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.
0 comments:
Post a Comment