Home Gateway Initiative

Transcription

1 Home Gateway Initiative HGI-GD013-R2 HGI Guideline Document: QoS white paper June 26, 2009 Abstract QoS is one of the major features of the HGI Residential Profile specification. It is a pragmatic scheme based on real business needs, which can support a wide and evolving mix of services. It recognizes both technology and organizational boundaries, and is powerful and flexible. The aim is to enable Service Providers to use QoS as part of the differentiation of their service offerings. While it is largely based on standard techniques, there are some novel features, and the scheme needs to be fully understood in order to gain the maximum benefit from it. This White Paper therefore explains the rationale for the approach adopted by the HGI, describes the functionality available, and then provides some real-world examples of how an HGI gateway can be configured to provide the QoS needed to support a wide variety of business needs. The target audience is both HG vendors so that they can understand the value of the QoS functionality and how they might implement it, and Service Providers to give guidance on how the functionality can be configured to support their services and provide market differentiation. Page 1 of 31

2 Contents 1 Introduction End to End Architecture Managed and unmanaged services The Need for Quality of Service in the Network HG/HN Congestion Points The Home Gateway - Upstream The HG - Downstream HG Transit Traffic Bridges and Switches in the Home Network (HNIDs) Possible Approaches to QoS The Different QoS management domains Possible Approaches to QoS End-device/application marking - local usage End-devices/application marking - end to end End-devices/application marking - co-ordinated Unco-ordinated, point solutions in trusted devices Conclusion The HGI QoS Approach Service classification Unused Classifiers Fragmentation and Classification Classification and NAT The Use of Classifiers in the Downstream Direction Transit classifiers Service Signature Configuration Static configuration management Session based QoS Performance Monitoring Data plane architecture and queue structure General Queuing Considerations Upstream Queue structure Downstream and Transit Queue Structure The Quantification of QoS Upstream delay and jitter Downstream delay and jitter Upstream voice overload Guest Access using excessive bandwidth PC-PC traffic limiting file-server data rates Example Use Cases Use Case 1: Upstream voice-data congestion Use Case 2: WiFi congestion Use Case 3: Admission control Use Case 4: Guest access Use Case 5 - Small Business IPR Statement, disclaimer and copyright Glossary Page 2 of 31

3 1 Introduction In the Residential Environment, Quality of Service is generally a means to an end for both the Service Provider and End User (EU), rather than being the basis of any quantified Service Level Agreement (SLA). From the Service Provider perspective, the aim is to deliver premium/managed services to end-devices with the necessary and consistent Quality of Experience, and thereby provide service differentiation with over the top (OTT) services (which correspond to Unmanaged Services in HGI terminology). Ideally this should be irrespective of what the end-user (EU) is doing on their Home Network for their own purposes. The SP will be hoping to gain some commercial benefit by doing this, and so a key aspect of any solution must be to minimise the number of support calls which could otherwise threaten the commercial viability of such a service. The user has no direct interest in, or in most cases knowledge of, Quality of Service in itself but he does care that each service is delivered to the appropriate device in a consistent fashion and without any noticeable disruption e.g. pixellation on IPTV, or break-up in a voice service. This needs to be done at a price that he is prepared to pay. 2 End to End Architecture 2.1 Managed and unmanaged services Quality of Service is associated with the concept of Managed Services. The HGI definition of managed services is as follows: A managed service is one where the Service Provider has assumed responsibility for the end to end service delivery, and is able to give preferential treatment to the delivery of that service, which often means providing the appropriate Quality of Service. In contrast, the SP assumes no responsibility for the delivery of an unmanaged service. Note that the steps needed to assure the delivery of a managed service may well have a detrimental impact on unmanaged services. 2.2 The Need for Quality of Service in the Network QoS becomes relevant when instantaneous network demand exceeds the available resource. This can occur at various network locations, but in particular: on the Customer Access link - especially in the upstream direction for ADSL based services in the aggregation network, when backhaul is contended in the Home network, when there is a mix of Access traffic and local LAN traffic. Note that sustained overload cannot be addressed by quality of service mechanisms, but instead needs congestion avoidance mechanisms which range from simple traffic engineering (network planning and monitoring), to more complex approaches such as connection admission control (CAC). A longer term solution is of course to upgrade the capacity of the bottleneck link which may involve a technology change or upgrade (e.g. going from b to 11n). While any QoS scheme has to take an end to end view, the focus of the HGI QoS activity is (almost by definition) the HG itself, and the Home Network. 2.3 HG/HN Congestion Points There are a number of potential congestion points in this part of the network, as shown in Figure 1. Note that the degree to which these are actual congestion points will depend (in part) on the technologies used. Page 3 of 31

4 HG 100 Mbps Low-rate upstream Access High-rate downstream Access High-rate to low-rate bridge Merging WAN-LAN and transit traffic 100 Mbps 100 Mbps Wireless LAN Ethernet-PLT bridge Ethernet Switch <10 Mbps 100 Mbps 100 Mbps Figure 1 HG/HN Congestion Points The Home Gateway - Upstream For certain Access technologies, in particular ADSL, the upstream rate is very much less than the rates of most home network technologies. Even where the Access physical layer upstream capacity is greater than that of the home network technology e.g. for a fibre Access network, the service rate may be constrained to a value which is again less. There may also be a commercial desire to allow the end-user to subscribe to more services than the upstream rate can simultaneously support The HG - Downstream The HG QoS solution needs to be access technology agnostic. For faster access technologies, e.g. ADSL2+, VDSL/VDSL2, Ethernet or fibre, the HG itself can become a downstream congestion point, particularly if the Access Node (or BRAS) is not configured to constrain the downstream bandwidth to the HG. Examples of this would be a ~20Mbps ADSL2+ access feeding into an b Wireless Network, or a fibre access going into virtually any Home Network technology. Note that this can also apply to the 2-box model, where the link between the 2-boxes is Ethernet and so can burst to 100 Mbps HG Transit Traffic One of the reasons for congestion is because of a mismatch between the physical rates of different technologies. This can occur in the HG itself, for example when it is acting as a bridge between wired and wireless Ethernet. The other potential transit problem is when bridged intra-home traffic is aggregated with the downstream Access Network traffic, and they are competing for access to one of the LAN-side ports. The LAN-LAN traffic can burst to very high rates, and so fill up buffers within the HG, thereby significantly delaying lower rate downstream traffic. Further, LAN-LAN traffic may well increase in the future with the proliferation of homenetwork devices, especially in the audio-video content sharing domain Bridges and Switches in the Home Network (HNIDs) Rate mismatches can also occur within the Home Network itself, for example in an in-line bridge device such as a PLT-Ethernet adaptor. While the physical line-rate of some Powerline Technologies can be well in excess of the 100 Mbps peak rate of wired 100BaseT, the payload Page 4 of 31

5 can be significantly less than this (depending on the mains topology, noise environment and number of users). Simple aggregation devices (e.g. an Ethernet switch) which have the same physical interface type and speed on all links, including the aggregating uplink, can also become congestion points. The HG may not have any knowledge of the presence of such devices. 3 Possible Approaches to QoS 3.1 The Different QoS management domains The 3 key potential network congestion points were identified in Section 2.2 as being the (upstream) access link, the (downstream) aggregation network, and the Home Network itself. As can be seen from Figure 2, these will often lie in different management domains, i.e. the enduser himself is responsible for the Home Network, the Retail SP for the HG, and the Wholesale Service Provider for the aggregation network. This needs to be taken into account when considering the most appropriate end to end solution. Managed Services VOIP2 User End management User Wholesale Access Network provider management IPTV VOIP1 HG D S L A Backhaul Network BNG SP edge d Internet Figure 2 QoS Management Domains Retail Service Provider Mgmt Possible Approaches to QoS 4 possible approaches to providing QoS were considered, although there is a degree of overlap between some of these: Packet marking by end-devices/application which are used locally by the HG and Home Network Packet marking by end-devices/applications and application servers which are used end to end Packet marking by end-devices/applications and application servers which are used end to end, and their use is co-ordinated by a centralised system e.g. IMS Unco-ordinated, point solutions at the key network congestion points, in trusted devices, especially the HG. Each of these will now be considered in more detail. Page 5 of 31

6 3.2.1 End-device/application marking - local usage There are several problems with this approach, namely: All the appropriate applications and end devices have to be able to support marking, currently very few do. There has to be an agreed, consistent set of markings over a wide range of device types and industry sectors. This has proved very difficult to achieve to date, with vendors proving reluctant to change markings that they have chosen. There is the need to trust end-devices/applications This only addresses the HN/HG aspects of the problem, not the end to end picture. Note that this approach is essentially the one being considered by the DLNA, and their activity on standardising markings may make it more viable in the longer term End-devices/application marking - end to end This has the first 3 disadvantage of the above approach, and while carrying and honouring the markings through the network can in principle solve the end to end problem, it means the concept of trust has to be extended across the different management domains described above. It is common practice to bleach QoS markings at the interface between the different domains shown in Figure End-devices/application marking - co-ordinated This has most of the disadvantages of the first 2 approaches, and while the coordination can address some of the trust issues, it introduces the overhead of a centralised co-ordinating system, which someone has to pay for and operate. Further, it may well lead to some significant real-time performance requirements. IMS is an example of a co-ordinated, end to end approach Unco-ordinated, point solutions in trusted devices The fact that there are often different management domains in an end to end system suggests that different, independent solutions for the various domains may be appropriate. Further, resolving upstream access link congestion addresses a large part of the problem. This can be done in the HG itself, and if the HG is a managed device, by the Retail SP. An HG-based solution can also address the transit and downstream problems. 3.3 Conclusion Having an SP-managed, HG-based solution avoids all the problems of end-device marking, marking consistency and end-device trust. So while this does not provide an end to end solution, it can form a key part of the solution, and can peacefully co-exist with whatever solutions are needed in the other domains. For these reasons, the HGI decided on a solution mainly based on managing the QoS of all the traffic that transits the HG. There are also extensions which address some of the QoS issues within the Home Network. Page 6 of 31

7 4 The HGI QoS Approach The HGI QoS approach is mainly concerned with managing QoS through the HG itself. It works on the basis of a packet by packet, service classification done by recognising a service signature. This service classification is used to assign the packet to the appropriate queue, and may be used to set the L2 markings for a particular HN technology. It is also possible to drop packets on the basis of the classification. Note that Service is used here in the sense of a specific commercial instance of a service. The main features of the solution are: identifying services on an (ingress) packet by packet basis by means of a service signature sending each packet to the appropriate queue providing multiple queues (per L2 interface) which support a configurable mixture of Strict Priority and Weighted Round Robin WRR queuing disciplines QoS-management of all traffic that transits the HG, in any of the following 3 directions HN-WAN WAN-HN HN-HN simple, static configuration, by the SP only relative, and class-based (as opposed to absolute and parameterised) no dependence on other network nodes peaceful co-existence with other QoS schemes, both within the home, and other parts of the network. 4.1 Service classification The key requirement for classification is to be able to classify a service rather than a traffic type. Queuing, scheduling, and dropping treatment are then based upon this service classification. The BSP/ASP wishes to deliver services with a particular quality. There may well be other traffic of the same type (e.g. VoIP) which should not be given any special treatment if it is not a valueadded service. Each packet is classified by inspecting one or more of its header fields. The combination of classifiers used to identify a service is known as the classification rule for that service. There are in fact rather different requirements for the classification of the three basic directions of traffic flow through the Gateway i.e. upstream, downstream and transit. The upstream classification needs to be the most fine-grained, as queuing and scheduling into what is normally the most significant congestion point needs the greatest degree of control. In the downstream direction little can be done to improve the QoS of arriving packets, and the main aim is to maintain this ingress QoS, and ensure that it is not compromised by either transit traffic, or the slow operation of any integrated HN technologies. The downstream and transit classifiers are therefore a subset of the upstream classifiers. The full set of classifiers is described below with a brief rationale as to when and how they might be used, and the downstream and transit subsets then noted. Each packet is classified on ingress and then allocated to the appropriate queue, or dropped. Packets can be marked or remarked; these markings can be used by other network components but with the exception of some HNIDs, the HGI approach does not require (or depend on) this. There is a wide range of classifiers (L1-L4) which can be used in arbitrary combinations. These are now described with an indication of the types of service for which they might typically be used. Note however that the scheme is completely flexible, and it is up to the service provider to determine both how each service is recognized, and then how it is treated. Page 7 of 31

8 IP address (Destination, Source and Subnet) The single most useful classifier is IP address. Many managed services go to a service border gateway (SBG) of some kind, and so the destination address of that SBG can be used to classify upstream traffic. This has the additional benefit that the end user cannot gain any QoS advantage for other traffic types by spoofing this address, as that traffic would then be going to the wrong destination. Examples of a service which might use this classifier are VoIP, in the case where the media goes to a SBG as opposed to being peer to peer. Note however that use of IP destination addresses may eventually suffer from scalability limitations as the number of possible destinations increases. It can also cause problems with network address maintenance e.g. server address renumbering would require a synchronized change to the rules contained in many HGs. This type of classifier is also useful for encrypted services which use an IPSec tunnel. Here it is not possible to use fields of the inner packet header to identify the service signature. However the entire tunnel can be given a higher priority, simply by the use of the tunnel destination address as the classifier. It might be thought that there could be no finer QoS granularity within the tunnel, but in fact this is not the case (see Packet Length below). Source IP address can be used as the classifier for a video streaming application. However the upstream traffic for such a service may also need high priority, e.g. when it is TCP based. The video server s destination address could therefore be used as the upstream classifier. Video services may come from a large number of possible servers, and it would be inconvenient to have to store and maintain a long list of addresses. In this case, the server subnet may be able to be used as the classifier. If the video servers are not in the same (or a small number of) subnet(s), then this approach would also become cumbersome. An alternative would be to use the IP address of the STB. There are 2 potential problems with this; it is under the control of the end-user and so could be spoofed. However in the upstream, it is primarily his own traffic he would be impacting. The more real concern is that this would require each HG to be configured with a different STB IP address, and this would normally be a private, dynamically assigned address. This is clearly impractical manually, but can be done automatically by the use of DHCP Options 60 and 77. The Gateway can recognize DHCP requests, and be configured to locally set a traffic classifier to the source IP address for the appropriate Option 82 value (which identifies the STB/video service). TCP/UDP S/D port or range Where there is no convenient SBG address, then another classifier is needed. Various applications can be identified by their port type and number. Again these may be able to be learned dynamically when that device receives its IP address. A coarse QoS distinction can be made on the basis of protocol type, i.e. UDP or TCP. MAC SA/DA Although the main purpose of HGI QoS is to provide support for managed services, it is recognized that LAN-LAN traffic within the home is likely to become greater in both volume and importance to the user; for example video or audio being streamed around the home from a NAS device. While it may not be in the SP s direct interest to give such traffic priority, it might increase the overall attractiveness of the HG of that SP. The problem is however how to recognize which part of the LAN-LAN traffic should be prioritized. There are two issues, firstly there are no easily configurable or learned IP addresses as discussed above which could be used as service signatures. Secondly, the LAN-LAN traffic may only go via a simple bridge in the HG and so not pass through the (L3) classification engine. The solution to both these is to go to a more device-based approach. If there are certain devices, again such as a NAS, which normally generate streaming video traffic, then if there is a simple way of identifying all the traffic from that device, it can be prioritized over traffic from other devices. This essentially requires a device (i.e. hardware) identifier, and so can be done on the basis of MAC address. Page 8 of 31

9 The problem then becomes how to automatically learn the MAC address of such devices, since again these would be very difficult for the SP to administer. The HGI QoS scheme supports MAC addresses as classifiers, and while it does not explicitly cover how they are learned, suggests that an application whereby the end-user could nominate particular devices (e.g. on a GUI which showed the networked devices), could be used together with an ARP. Alternatively DHCP Options 60/77 could again be used to identify device types and the MAC addresses then learnt automatically. Some HN devices will be general purpose, and so it might not be appropriate to prioritise all their traffic. However as both source and destination addresses can be used, this allows rather more discrimination and granularity e.g. all NAS traffic going to a particular PC. LAN interface type (Ethernet, Wifi) or instance Although in most cases a given LAN interface will be used for multiple different traffic types/services, it may be appropriate to apply the same treatment to an entire interface. Certain SPs may want to dedicate a physical interface to a single service in order to ensure the end to end quality, especially for IPTV. Although in some ways this approach is inflexible, and requires some knowledge and correct action on the part of the end-user e.g. plugging into the right LAN port, and only using a point to point connection (not adding an intervening hub), it can be made to work. Physical port (e.g. FXS) In one particular case the service is actually identified by the nature of the port, namely an FXS interface embedded into the HG. In this case there is an implicit classifier, but this still needs to be configured with the appropriate queue treatment. Wifi SSID A subset of physical port classification is to use a logical port within a physical port. A good example of this is wireless, where different SSIDs can be used to separate customers and give them different QoS treatment. This can for example be used to give guest access users a lower priority than the HG owner, as well as applying different security treatment in order to protect the Home Network itself from the Guest user. Packet length Where the same Source and Destination address are used for multiple applications, or more than one application shares an encrypted tunnel, then packet length can be used to discriminate between different services. This is particularly useful in the case of voice. Here the key requirement is that very long packets do not delay short media packets. This can be achieved by making one of the criteria for entry into the high priority queues that the packet must not exceed a certain length. This length needs to be configurable in order to cope with different voice codecs and packetisation times. The length classifier will normally be used in combination with one or more other criteria to fully identify the service. Note also that all the packets associated with an application would have to meet the length criterion, or there would be the potential for packet re-ordering. DSCP value Although in most cases the HG does not rely on ingress QoS markings, if these are trusted, they could be used as part of the service signature, especially for WAN ingress traffic where they may well have been set or checked by a trusted network component. This is not a key feature of the HGI QoS scheme, but can be used if required. ATM VC, Ethernet VLAN (WANside only) Finally the L2 connection ID (ATM VC or VLAN), can be used in the classification process for ingress traffic (on the WANside only) Unused Classifiers VLANs and/or.1p markings are not used in the HGI QoS scheme in the HN. This is because there may well be legacy HN equipment that does not support VLAN tagged frames and will Page 9 of 31

10 simply drop them. Further, the VLAN allocation would need to be managed, which is quite complex Fragmentation and Classification Some applications, for example video streaming, may use large UDP or TCP packets. When packets are greater than the configured MTU (e.g. greater than 1500 bytes), the IP layer will fragment them. Methods for determination of MTU size are beyond the scope of this paper. While each resulting fragment contains a Layer 2 header and an IP header, only the first fragment will contain the UDP and TCP headers. Therefore, fragments must be handled with particular care by those elements of the HG that normally use the full packet headers. This includes classification as well as NAT. Classification could treat fragments in various ways, e.g.: Re-assembly of arriving fragments in the HG so that all header fields, including UDP or TCP fields, are available to the classification logic. Classification on a fragment-by-fragment basis. In fact the HGI does not advocate either of these methods but to avoid ambiguity in classifier treatment of fragmented flows, it is recommended that either the ASP avoids the use of applications that result in fragmented flows to the HG, or that they only use Layer 2 and IP header fields for classifying such traffic Classification and NAT Classification treats arriving packets according to their header fields. However, NAT may subsequently alter the IP, TCP and UDP fields of these packets. The HGI does not specify if classification applies to pre- or post- NAT ed headers. It is recommended that the SP only uses classification based on header fields (e.g. IP Destination Address and UDP or TCP source port) that do not change during NAT The Use of Classifiers in the Downstream Direction The main requirement in the downstream direction is to be able to distinguish between managed and unmanaged services, and this can often be done on the basis of IP SA alone. This is not sufficient in all cases and so some, but not all, of the above classifiers are also needed for downstream traffic. However packet length, MAC address, and physical port are generally not - there is only 1 WAN port, and so the fact that it is downstream traffic can be taken into account without there needing to be an explicit classifier Transit classifiers The SP is not directly involved with transit traffic but wants to prevent it adversely impacting his managed services. This could be done by always separating out DS and transit traffic, and simply giving absolute priority to the DS traffic. However there may be an opportunity to distinguish between (transit) streaming and data traffic on the HN, and prioritize the former. The problem is that if this traffic is simply bridged, then it may not be seen by what is essentially a L3 classification engine. Further, if all such traffic were forced via the full classifier, this would require the classifier to be able to operate at a line rate of up to 100 Mbps. Finally, the BSP/ASP has no awareness of these LAN-LAN flows as services, which makes a service-based classifier hard to configure. Therefore there is a simple transit priority scheme, which is essentially device-based and uses MAC address pairs (SA and DA) to identify traffic which can be given higher priority. Separation between DS and transit traffic can still be maintained. 4.2 Service Signature Configuration Most service signature classifiers are downloaded into the HG as a rule-set by the Service Provider. A rule-set here simply means a list of classification rules, and the treatment that is to be applied to packets that match each of the rules. This would normally be done as a one-off static configuration, with additional rules being loaded only when a service was subscribed to. Page 10 of 31

11 An alternative approach would be to pre-load a common, more complete set of rules prior to service subscription and leave the application layer to control access to each service. Once this had been granted, then the appropriate QoS rules would automatically apply without the need for further HG configuration. Service classification is only part of the story. There then needs to be a configuration of the mapping of a service class to a queue type. There is deliberately no fixed or default mapping in order to leave the maximum opportunity for SP differentiation. It would also be very risky to allow the EU to control this classification and mapping because of its complexity, and the need to consider the impact on all services. However individual end-user preference can be accommodated by the use of profiles, but these are managed by the SP, not directly by the enduser. This could support different types of user, e.g. Homeworker, gamer etc. and could even be changed on a time of day basis. Although most of the rules will be downloaded by the SP, some have to be set locally, but again not by the end-user. These were mentioned in the above Classification Section and include local IP SAs learned during DHCP address acquisition, and local MAC addresses learned after the selection of preferred devices by the end user Static configuration management Management of the HG QoS capabilities, in particular the downloading of the service signature rulesets, is based on the Broadband Forum s TR-069 (CWMP) management protocol and TR- 098 Data Model. This is in line with the general HGI approach to use BBF management protocols wherever possible. Specific extensions to TR-098 to support the details of this QoS scheme have achieved through liaison with the Broadband Forum. These extensions include the CAC configuration parameters, the classifier for internally generated traffic, and the queue congestion statistics. 4.3 Session based QoS Although the HGI approach is essentially class-based, there are two service instance or session based (optional) additions which will now be described. Class-based means the QoS treatment is the same for all flows which have the same service signature. This is for the reasons of simplicity and scalability explained above. However the HGI scheme does also support some limited flow awareness. Flows are closely related to sessions, which have two possible uses in a QoS scheme; allowing a different per session QoS policy to be applied, and preventing new sessions if they would adversely impact existing ones. The basic requirement here is to provide the appropriate QoS for a service type; there is no reason to suppose this should be different on a session by session basis a given voice service always needs the same QoS. Therefore a static policy approach has been adopted. The potential downside of this is that there is no mechanism to prevent a new session overloading the class so that the entire class suffers. If overload is a genuine concern (as opposed to a theoretical possibility) then some kind of admission control system is needed. Admission control requires a decision to be made about resource availability before a session is established, and so involves signalling participation by the HG. This can be fairly complex, and so the HGI has developed a scheme which avoids this signalling dependency. The HG can provide a basic overload protection mechanism which allows a new service instance to be allowed on a trial basis to see whether or not it can be supported without impacting existing traffic. This mechanism works in the following fashion. Within a service class there is the concept of a recognised and an unrecognised service instance. The simplest way of doing this would be to classify the instance on the basis of the associated LAN IP or MAC address. Any packet with the known service class, but unknown instance would be put into a different queue to recognised instances. Each classification rule has an optional pointer to an Application Layer Logic (ALL). For overload protection, the ALL would check if this was a known service instance. If not, it would initiate a procedure which Page 11 of 31

12 checked (over a relatively short period of time) if this new instance could be accommodated without causing overload, as measured by excessive queue length. In addition to this simple overload protection mechanism, a more traditional Connection Admission Control (CAC) support function has also been defined. This prevents too many instances of a given service, by participating in (as opposed to snooping), the session signaling and rejecting a call if it would exceed the configured bandwidth limit for that class. So far this function has only been defined in detail for SIP based voice. 4.4 Performance Monitoring One of the problems with CAC is the difficulty of making the decision as to whether a new flow should be admitted. This is partly because both the actual usage and total capacity of a given link are likely to be time variant, and on different timescales. The former can be circumvented by call-counting, i.e. calculating what the usage should be on the basis of call-counting and knowledge of the required bandwidth per call. However it would make sense to periodically check this view by measuring the actual usage, to allow for calls which had been improperly terminated. The available (PHY) capacity is more difficult. The instantaneous value may vary considerably for technologies such as wireless or PLT, and so is of little value. Of more potential use is a history of performance over a timescale which is appropriate to the requested service e.g. minutes for voice, ~ 1 hour for video. The key parameter is the percentage of time during that period for which the PHY rate (significantly) exceeded the desired service rate. If the time and rate are configurable, then this mechanism can be used to asses the likely support for a variety of service types for any given interface. This could then be used in a number of ways, for example as part of a more comprehensive, possibly centralized, CAC system - the current HGI system just uses a configurable class bandwidth - or in deciding whether or not to allow an end-user to subscribe to a certain service. It would also have a more general purpose troubleshooting use. Other (related) troubleshooting aids which have been specified include a comprehensive set of queue depth monitors which can be used to help diagnose latency and packet drop issues. Page 12 of 31

13 5 Data plane architecture and queue structure 5.1 General Queuing Considerations There are 2 fundamentally different types of queue used in QoS management: strict priority and round robin. In fact there are multiple variants of the second type, weighted round robin, weighted fair queuing, weighted deficit round robin etc. In strict priority queuing, the queues are serviced in a fixed priority order, with a lower priority queue only being serviced when all the higher priority queues are empty. This has the great benefit of simplicity, there is no per queue configuration. It also allows a variety of applications with different low latency requirements to be supported with a fairly deterministic jitter. Its big disadvantage is that a single queue can completely starve all the lower queues. For this reason, SP queues are mainly used where the traffic is source-rate limited in some way; this therefore includes services such as video streaming and voice. It is also possible to do per queue policing to ensure that complete starvation is avoided, although this may cause a problem for video applications if the policer is not set (and works) accurately, and should be avoided if at all possible as it gets back to per queue configuration. The mechanism of starvation avoidance for the WRR queues must not introduce jitter on the SP queues. Round robin queues can be used to provide controlled sharing between services which are less delay sensitive. The difficulty is that each queue has to have a weight configured. Working out what these weights should be is non-trivial, and the actual performance for a given set of weights may be implementation dependent. To support a full mix of service classes both types of queue will generally be needed. However because the precise mix will depend on the services that a given service provider wishes to support, the HGI requirement is for a certain minimum number of queues, each of which can be configured to be of either type. The HGI QoS approach is class-based i.e. a service signature identifies a class and all members of that class share the same queue. The alternative would have been to have a queue per service instance, but this has several drawbacks, Firstly the number of queues is unbounded and could be large, and in the case of round robin queues, there would be many more weightings to configure. Secondly, identifying service instances is more difficult than classes, and cannot be done in advance. This means the static, management-based download of service signatures cannot be used, and so a more dynamic, locally autonomous approach would be needed, which is much harder to troubleshoot. Finally the allocation of service instances to queues is also more complex, and may involve business logic. Although the HGI approach is class-based, there is in fact a full set of queues per WAN side L2 interface to cope with multiple service providers, each having their own L2 pipe, or a single service provider requiring more than one L2 pipe. Multiple L2 pipes may be unlikely in ADSL, but as this is a general purpose QoS scheme, it needs to be applicable to other access types, e.g. VDSL and fibre, where having multiple Service Providers is more likely; indeed such access products already exist. 5.2 Upstream Queue structure In the upstream direction, the main requirement is to avoid excessive delay for voice, provide sufficient bandwidth for voice and video, and to prevent best-efforts traffic being completely starved by higher priority queues. There are 3 fundamentally different types of traffic with regard to QoS: voice, video and data. This would require 3 queues. However there is a need to further distinguish between at least 2 different types of data (e.g. for higher priority control data or to support a premium data service), Page 13 of 31

14 Further, the overload protection mechanism mentioned above requires an additional queue, making the total number of queues required at least 5. In this minimum queue set, there are at least 2 strict priority queues with the remainder being WRR. The highest priority queue is served to exhaustion. The second strict priority queue is served when the highest priority queue is empty, and the scheduling is such that the jitter on the highest priority queue due to all other queues is limited to a single packet. The highest priority queue would normally be used for voice, with the second queue being used for other CBR applications which were less jitter sensitive. While queues are nominally associated with particular traffic types, any service can be mapped to any queue, and the scheduling behaviour is configurable by means of the round-robin weightings. The overall aggregate can be shaped to a rate which can be configured to be less than the physical line rate, and there is also a per queue shaper for the WRR queues. This could be used for example to limit the maximum upstream rate of an Internet service. Figure 3 shows the data plane architecture for the upstream traffic in the case of 5 queues. The same model can be applied for a greater number of queues (there is an optional HGI requirement for 8 queues), by simple adding more queue instances of one or both types. Queue 1 - SP Packets sent from LAN to a Layer 2 WAN port Queue 2 - SP Scheduler Packets sent Classifier WRR with starvation prevention mechanism (Minimum bandwidth) Sending Queue Shaping L2 WAN egress port Queue 3 WRR Weight 1 Shaping Scheduler Queue 4 WRR Weight 2 Shaping Queue 5 WRR Weight 3 Shaping Figure 3 Upstream Queue Structure 5.3 Downstream and Transit Queue Structure In the downstream direction there are 2 concerns, ensuring that WAN traffic is not blocked by transit traffic, and if there is downstream congestion due to a rate mismatch caused by a slow HN technology, that the managed traffic gets priority. There may be two different types of transit traffic, simple data and streaming e.g. from a media player. The downstream needs a somewhat simpler queue structure, with 4 queues (WAN Managed Services, WAN Best Effort, LAN media Services, LAN Best Effort) per LAN port. Figure 4 shows the data plane architecture for the downstream traffic for the case of 4 queues, but as for the upstream model, this is extensible to an arbitrary number of queues. Packets sent to LAN from WAN or LAN Queue 1 - SP Queue 2 - SP Scheduler Packets sent LAN egress port Classifier WRR Sending Queue Queue 3 WRR Weight 1 Scheduler Queue 4 WRR Weight 2 Page 14 of 31

15 Figure 4 Downstream and transit Queue Structure Page 15 of 31

16 6 The Quantification of QoS This Section quantifies the major QoS related issues in a fairly generic way, although in some cases they are service type specific. Section 7 then considers specific Use Cases with regard to which of these potential issues is of actual concern, with a proposed QoS configuration to address them. 6.1 Upstream delay and jitter Any HN PC may be doing a large upload, e.g. an with an attachment, sending a file to WAN-based storage. If this is TCP based, then the upstream (upload) rate will tend towards the physical line rate. Therefore any single PC can potentially consume all the available upstream bandwidth. In the absence of any QoS, the upstream delay will simply depend on how large an upstream data burst the HG can buffer. This may of course also result in packet loss when the buffers become full and this matters much more for voice than data as retransmission is not appropriate. Two applications in particular will suffer from excessive upstream delay, voice and a TCP-acknowledged video service. The delay per maximum-length packet, and as a function of buffer size is shown in the below Table for each of the 3 given upstream ADSL rates. The buffer size calculation takes into account the fact that only whole packets can be stored, and so the delay is that due the maximum number of whole packets that can be stored, which may be smaller than that due to the entire buffer size. Note that these are generally applicable values which do not take into account a particular queue structure or queuing discipline. Single packet Delay as a function of buffer size (ms) delay (ms) US Rate (kbps) 4 kbytes 8kbytes 16kbytes 32kbytes Delay matters for voice because at some point it impairs normal conversational interaction. This is typically at least ~300 msec for the complete end to end path. However well below this figure, the (de-)jitter buffer size and echo canceller tail-length are likely to be exceeded, which can result in packet drops and/or poor echo cancellation. There are no hard rules on the acceptable network delay, but it is certainly tens rather than hundreds of milliseconds. From the above Table, it can be seen that even the single packet delay is of this order, and that any significant buffer size can result in delays greater than 100 ms. Note that this Table just contains the delays that can be incurred at this single network queuing point. There are many other factors that need to be included in the total end-to-end delay budget, e.g. coding/decoding, backhaul, service platform processing etc. The jitter requirements for video TCP ACKS are likely to be even more stringent. 6.2 Downstream delay and jitter While nothing can be done at the HG to reduce the delay already incurred by downstream packets, it is important that it is not made worse. The major issue here is the potential impact of transit traffic, on either the wireless AP or the Ethernet ports, which in the absence of HGI QoS, could delay the access packets if there is significant HG buffer capacity. The following table considers a range of payload rates for the downstream interfaces from the HG. The range considered - 1, 2, 5, 10, 25 and 100 Mbps - covers a wireless network operating at a payload rate of between 1 and 25 Mbps, and the case of a 10/100 Ethernet interface. Page 16 of 31

17 Delay as a function of buffer size (ms) Rate (Mbps) Single packet delay (ms) 4kbytes 8kbytes 16kbytes 32kbytes It can be seen that for downstream interface rates of 25 Mbps+, the delay experienced by downstream packets is minimal from the voice perspective, but certain types of streamed video may be more jitter sensitive. Even for voice, the delay can become significant for the lower rates, albeit much less so than for the upstream access link. The problem is that the rate at which a wireless interface will run is impossible to predict. Since it is possible that the link will run at a rate such that there is a problem, it would be advisable to configure the QoS scheme to address this issue in case it does happen. 6.3 Upstream voice overload The bit rate of a voice call depends primarily on the codec and packet size; short packets result in less packetisation delay, but incur a higher overhead. Common schemes result in rates in the range kbps. For example, UMA voice using a GSM6.6 codec with 10 ms of speech per IP datagram results in 52 kbps of IP traffic in both directions. G.711 with 10 ms packets produces 106 kbps. In the residential environment, given the observed number of call minutes, the probability of even 2 concurrent calls is fairly low, and 3 is vanishingly small. This is also a function of the relatively low (and declining) average occupancy per household (2.37 in the UK). Therefore even the most bandwidth hungry voice calls would be unlikely to overload the upstream, at least for upstream rates of >~400 kbps. In the business environment this may or may not be the case; there is far more scope for concurrent calls, but the upstream will often be higher (~800kbps). If the call rate and upstream bitrate are such that overload is a real possibility, then local CAC can be used to prevent this happening in a graceful fashion. Currently this functionality is defined by the HGI for SIP based voice only. 6.4 Guest Access using excessive bandwidth Since many download and upload applications use TCP, the data transfer rate will try to increase until it hits some limit, which will often be the upstream access rate; in some cases it may be the downstream rate, although this is less likely. Therefore in the absence of QoS, a single guest could monopolise much of the access bandwidth. It might be thought that at the very least all users would get a fair share of the available bandwidth; e.g. if a single TCP connection is saturating the link, then a second, new connection will gradually get more until they are sharing equally. In practice there are well-known (if not fully understood) mechanisms which result in bandwidth hogging and very unequal sharing. Therefore it is necessary to impose some defined sharing control in order to restrict Guest access. 6.5 PC-PC traffic limiting file-server data rates There may be certain LAN-LAN traffic which needs to be given priority. In the residential environment this could be video streamed from a NAS, and this may have some fairly hard delay limits. In the Small Business case, it may be a somewhat softer, application related requirement, e.g. ensuring that access to the common file server gets priority over PC to PC traffic. The requirement here may be to constrain delay, or simply to give absolute or weighted priority to certain connectivity types. It is hard to quantify this in much detail, but the above Table gives some idea of the delays that can arise. Page 17 of 31

18 7 Example Use Cases This Section provides a number of use cases. For each of these, the appropriate generic issues detailed in Section 6 are identified, and then a possible QoS solution is proposed. This consists of: which services need to be identified the appropriate service signature for each the mapping of services to queues, including different services sharing a queue if appropriate (virtual service class) the type of queue, priority and weighting (if appropriate) the expected performance improvement (where quantifiable) This is done in Tabular form for conciseness and ease of comparison. Note that both the service identification and treatment are completely flexible, allowing the Service Provider to tailor service offerings in any way he chooses. 7.1 Use Case 1: Upstream voice-data congestion This use case shows a typical example of upstream congestion. Laptop 1 Laptop 2 UMA phone WIFI Home Segment Analog phone WiFi Phone HOME GATEWAY ADSL access TV PLT Home Segment STB NAS Fixed PC The following services are simultaneously active, Page 18 of 31

19 - A VoIP call using the FXS port and legacy voice terminal (Example DECT phone) -> red flow - A UMA phone call from the Home Zone with the phone therefore connected to the WiFi interface -> blue flow - Peer to peer file sharing or FTP server hosting from a fixed PC on the home network -> green flow The problem is therefore that TCP based upstream data can use all of the available upstream bandwidth and cause excessive delay or packet drops to the voice Proposed Solution The following legend applies to the below Tables: u = upstream, d = downstream, SP = Strict Priority, WRR = Weighted Round Robin The numerical suffix denotes the queue number which in the case of Strict Priority queues is also the queue priority. Therefore usp1 for example means the highest priority, upstream, strict priority queue. Application Flow HG QoS req Service Signature Queue Weighting Analogue Voice Red LAN-WAN Physical (FXS) port usp1 UMA voice Blue LAN-WAN IP tunnel DA usp1 File upload Green LAN-WAN Any unknown signature usp2 Notes: In this case there is no transit traffic. The only flows that need to be classified are in fact the voice calls; they can then be given priority over any other traffic, which will include the upstream data traffic. The 2 types of voice need to be identified via different voice signatures, but there is no real need to treat them differently from each other; if there were to be such a need then they could simply be put in different strict priority queues. In this simple example, only Strict Priority queues are needed; this avoids the need to configure a queue weighting, which would have no effect anyway. It is always necessary to specify the queuing behaviour required for packets with no recognised service signature. In general this will be the lowest priority queue, although it could be dropping the packet. In these Tables, SP means Strict Priority rather than Service Provider. Performance Improvement (delay) Assumptions: 8k buffer size, 448kbps US Page 19 of 31

20 Flow Upstream voice (red or blue) single call Upstream voice (red or blue) 2 calls Max Delay without QoS 137ms 140ms Max Delay with QoS 27ms 30ms Notes: The additional delay for 2 calls is because a voice packet from one stream may get delayed behind a voice packet from the other. In addition to the reduction in delay, the use of separated queues also makes voice packet drop less likely 7.2 Use Case 2: WiFi congestion This use case provides an example of congestion occurring on the WiFi home segment due to in-home transit traffic. Laptop 1 Laptop 2 UMA phone WIFI Home Segment Analog phone WiFi Phone HOME GATEWAY ADSL access TV PLT Home Segment STB NAS Fixed PC An ADSL2+ line with a maximum of 20 Mbps downstream rate is used with rate adaptive or fixed profiles. Simultaneous usage of the following services is assumed: - A UMA phone call while UMA mobile is present in the Home Zone and connected to the WiFi interface -> blue flow - Intensive web browsing including large file downloading -> green flow Page 20 of 31

21 - Laptop displaying HD content stored on an Ethernet hard disk drive acting as a DLNA media center -> red flow. This is assumed to be WMV HD type content, with a resolution as high as 1080p, which results in maximum MTU size packets at a bit rate of up to 8.5 Mbps. The DS access rate and the in-home PLT rate may well be higher than the in-home Wifi rate depending on the instantaneous wireless transmission environment. The potential issues here are therefore: The wireless may become a bottleneck in the downstream direction, in which case the data download may delay the downstream voice. The wireless may also become a bottleneck in the transit direction, with the download delaying the transiting media stream. Although there is no explicit data upload in this scenario, even the US TCP ACKs from the data download may be sufficient to disrupt the upstream voice if nothing is done. Proposed Solution Note that in the Downstream direction, there are a set of queues for each LAN port. In the case of Ethernet these are the individual, physical switch ports, whereas for a shared media interface, e.g. wireless, there will be a single set of queues per interface type. The queues are therefore those pertaining to the appropriate port. Application Flow HG QoS req Service Signature UMA voice Blue WAN-LAN IP tunnel SA (Packet length) Queue dsp1 Weighting Any other DS data - WAN-LAN Any unrecognised signatures dsp3 NAS video streaming Red LAN-LAN MAC address of NAS dsp2 Any other transit data Orange LAN-LAN Any unrecognised signatures dsp4 UMA voice Blue LAN-WAN IP tunnel DA usp1 Any other US data - LAN-WAN Any unrecognised signatures usp2 Performance Improvement The US Voice improvements are the same as in the above Tables. The DS voice and transit improvements are as follows, and given as a function of the LAN rate. Page 21 of 31

22 Flow Max Delay w/o QoS Max Delay with QoS Max Delay w/o QoS Max Delay with QoS Max Delay w/o QoS Max Delay with QoS Wireless rate 1Mbps 5Mbps 10Mbps Downstream or transit voice/video 61ms 12ms 12ms 3ms 6ms 1ms 7.3 Use Case 3: Admission control The HGI Residential Profile includes an optional admission control mechanism intended for use with upstream conversational services. This uses the concept of a CAC Class which is a conceptual grouping of services, which are admission-controlled within a configurable per-class, bandwidth limit. The normal QoS Classifiers are used to identify flows as belonging to a CAC class, with the addition of a mechanism to track the number of flow instances. A running total of the bandwidth being used within each CAC Class is calculated based on simple call counting. This determines how much bandwidth remains, and therefore whether a new flow can be admitted. In addition to the per CAC class bandwidth limit, an overall bandwidth limit can also be set. The figure below illustrates the use case for the CAC mechanism operating on a voice application. Laptop 1 Laptop 2 UMA phone Analog phone WIFI Home Segment WiFi Phone WiFi Phone HOME GATEWAY ADSL access TV PLT Home Segment STB NAS Fixed PC The following end devices and services are assumed to be active in the home network: Page 22 of 31

23 - A VoIP call using FXS port and legacy voice terminal (e.g. DECT phone) - A UMA phone call with the UMA phone connected to the WiFi interface - A smart mobile phone with a WiFi interface and a SIP UA. A certain amount of upstream bandwidth is allocated for voice; note that this is not sterilised bandwidth and can be used by other applications when there is no voice present. Note that just as there is the concept of a service class, i.e. a set of services that all receive the same queuing treatment, there can also be a CAC class, i.e. a set of voice services which have a common bandwidth limit for CAC purposes. Currently these would all need to be SIP-based. The bandwidth limit for a CAC class is configurable, and could either be set based on a number of calls, or so as to always leave a significant percentage of the upstream bandwidth available for other purposes. The potential Issues here are therefore: ensuring that the US voice gets priority over other US traffic. limiting the number of calls to less than the US rate, thereby leaving some bandwidth for US data or ACKs Proposed Solution Application HG QoS req Service Signature Queue Weighting Analogue voice LAN-WAN Physical (FXS) port usp1 Wifi phone LAN-WAN IP DA of SIP SBG usp2 UMA voice LAN-WAN IP tunnel DA usp3 Any other US data LAN-WAN Any unrecognised signatures usp4 Notes: In this case, the proposed solution actually separates out the different voice applications. Whether or not this is sensible is partly a business decision, but is also related to the way the CAC function works, i.e. only on SIP-voice. The Wifi phones are the only type which actually use SIP and therefore may be subject to call rejection. This traffic is therefore given priority over UMA voice traffic, so it is not penalised twice in the event of overload (which can still occur). However the analogue voice is also subject to a kind of CAC of its own, due to the limited number of FXS ports (2). Since there may be a user expectation that this type of phone can always be used for emergency calls, these are given the top priority. Performance Improvement (delay) Assumptions: 8kbyte buffer size, 448kbps US Page 23 of 31

24 Flow Max Delay without QoS Max Delay with QoS Upstream voice 1 call 137ms 27ms Upstream voice 2 calls 140ms 30ms Upstream voice 3 calls 142ms 32ms Upstream voice 4 calls 145ms 35ms Notes: The additional delay for more than one call is because a voice packet from one stream may get delayed behind a voice packet from one or more of the others. In addition to the reduction in delay, the use of separate queues also makes voice packet drop less likely. 7.4 Use Case 4: Guest access This use case is a typical example of a guest access implementation. The WiFi home segment is divided into two different (private and public) virtual networks. The Access point supports multiple SSIDs, and uses two of these to provide the separation between these two user types. This prevents any traffic flowing between the two networks, and in particular stops the Guest User gaining any access to data or devices on the Home Network. Guest WiFi Phone WIFI Home Segment 1 Guest Laptop UMA phone Analog phone Laptop 1 WIFI Home Segment 1 ADSL access Laptop 2 HOME GATEWAY TV PLT Home Segment STB NAS Fixed PC The following devices and services are assumed to be active. Page 24 of 31

25 Private WiFi network - UMA phone call via the WiFi interface - Several laptops Guest access - WiFi SIP phone connected to the WiFi guest access - One laptop The bandwidth sharing rules are: - the upstream bandwidth sharing split between private zone and guest access is configurable but assumed to be 80:20 for this example. - in the case where there is no traffic in the private zone, guests can have 100 % of the upstream bandwidth The issues here are: ensuring that the Guest User gets a limited, maximum share of the bandwidth under congestion ensuring that the US voice gets priority over data ensuring that the private voice gets priority over Guest voice. Proposed Solution Application Flow HG QoS req Service Signature Queue Weighting Analogue Voice LAN-WAN Physical (FXS) port usp1 SB VoIP LAN-WAN IP DA SIP SBG usp1 SB UMA voice Blue LAN-WAN Private SSID Packet length< usp2 Guest UMA voice Red LAN-WAN Guest SSID Packet length< usp3 SB US wireless data Blue LAN-WAN Private SSID Packet length> uwrr1 80 SB US wired data Green (dashed) LAN-WAN Any Ethernet port uwrr1 80 Guest US data Red LAN-WAN Guest SSID Packet length uwrr2 20 File server access Green LAN-LAN MAC SA or DA of file server dsp2 Any other transit data LAN-LAN Any unrecognised signatures dsp4 SB VoIP WAN-LAN IP SA SIP SBG dsp1 Page 25 of 31

26 Notes The only downstream prioritisation in this case is being done on the SB VoIP, and it is debatable whether even this is necessary if it is going onto a Fast Ethernet LAN. There is no need to prioritize the analogue voice, as it is not queued in the HG in the DS direction. The other types of DS wireless voice could be prioritized, but unlike in the US, where SSID and packet length are used, the SSID here is not known until egress, and so this cannot be used as an ingress classifier. Note however that the packet does have to be sent out on the appropriate SSID, and so there has to be some identifier in order to be able to carry out this basic forwarding; this could be IP address, in which case this could also be as the service classifier. In addition to the service signatures, CAC can be done on any SIP based voice service. It would be sensible to do this separately on the SB and Guest voice access, i.e. specifying separate bandwidth limits for these two services. Indeed it might be appropriate to only do CAC on the Guest Access voice. In contrast to a previous example, even if the Guest Voice is Admissioncontrolled, it should remain the lowest priority voice. Performance Improvement The voice delay improvement is the same as in the above cases. The other improvement is that the guest data is limited to 20% of the capacity when there is congestion, but can get the full upstream and downstream bandwidth when there is no congestion. If a hard limit is required, this can be done by configuring a shaper on uwrr Use Case 5 - Small Business A typical Small Business Use Case is shown in the below figure. This has some overlap with the above Guest Access Use Case, in that there are 2 classes of users that need to be treated differently from both the QoS and security point of view, but there are significant differences. Firstly there are more PCs, and in order to connect all of these an external hub is needed in addition to the (4) embedded HG Ethernet ports; this means that not all the LAN traffic will transit the hub. There will be less emphasis on video services, although there may well be a central file server, which is in some ways is just another version of a NAS. The most significant difference is likely to be the number of phones (of various types) that the system is supporting. There will be both SB employee and Guest Wifi attached UMA phones, 1 or 2 analogue phones (for legacy analogue equipment such as faxes) connected directly to the hub, and wired- Ethernet attached VoIP phones. In addition to the greater number of phones, the total number of call minutes is likely to be higher than in the residential environment, and depending on the number of employees, there may be a much higher average number of concurrent calls. The example data flows shown in the Figure are follows: the Guest s PC is connected to his own corporate network via a secure tunnel. Forwarding rules within the HG prevent anything with the Guest SSID from being able to connect to the SB LAN. This is nothing to do with QoS as such, but the SSID is also used for QoS purposes as described below. the Guest UMA phone connects to the HG via WiFi, and then out over the Broadband link, ultimately to the GSM network. The connectivity is again restricted to the WAN connection. In the (far from unlikely) event of the call being to a phone within that same location, it is still routed via the Access and GSM network; there is no local turnaround for this (or any other) Guest traffic, as the security issues far outweigh any access bandwidth saving that might arise. there are 5 fixed PCs and 1 laptop on the SB LAN. Three of these are accessing the Internet, one is accessing the file server via the HG and the hub, and 2 are communicating directly via the Ethernet hub only, not the HG. a number of phone calls from the VoIP phones are also in progress, all to the external network, but the resulting flows have not been shown in order to keep the figure from becoming too complicated. Page 26 of 31

27 The issues to be addressed for this use case are as follows. ensuring that the Guest User gets a limited maximum share of the bandwidth under congestion ensuring that US voice gets priority over data ensuring that the SB voice gets priority over Guest voice. ensuring that admission control is applied separately to SB and guest access voice. prioritising the file server traffic Proposed Solution Application Flow HG QoS req Service Signature Queue Weighting Analogue Voice LAN-WAN Physical (FXS) port usp1 SB VoIP LAN-WAN IP DA SIP SBG usp1 SB UMA voice Blue LAN-WAN Private SSID Packet length< usp2 Guest UMA Red LAN-WAN Guest SSID usp3 Page 27 of 31

28 voice SB US wireless data Packet length< Blue LAN-WAN Private SSID Packet length> uwrr1 80 SB US wired data Green (dashed) LAN-WAN Any Ethernet port uwrr1 80 Guest US data Red LAN-WAN Guest SSID Packet length uwrr2 20 File server access Green LAN-LAN MAC SA or DA of file server dsp2 Any other transit data LAN-LAN Any unrecognised signatures dsp4 SB VoIP WAN-LAN IP SA SIP SBG dsp1 Notes The only downstream prioritisation in this case is being done on the SB VoIP, and it is debatable whether even this is necessary if it is going onto a Fast Ethernet LAN. There is no need to prioritize the analogue voice, as it is not queued in the HG in the DS direction. The other types of DS wireless voice could be prioritized, but unlike in the US, where SSID and packet length are used, the SSID here is not known until egress, and so this cannot be used as an ingress classifier. Note however that the packet does have to be sent out on the appropriate SSID, and so there has to be some identifier in order to be able to carry out this basic forwarding; this could be IP address, in which case this could also be as the service classifier. In addition to the service signatures, CAC can be done on any SIP based voice service. It would be sensible to do this separately on the SB and Guest voice access, i.e. specifying separate bandwidth limits for these two services. Indeed it might be appropriate to only do CAC on the Guest Access voice. In contrast to a previous example, even if the Guest Voice is CACed, it should remain the lowest priority voice. Performance Improvement This is a fairly complex scenario, but the benefits are essentially the same as those quantified in the previous scenarios. However these benefits will be relevant far more often, as the overall network use, and in particular the number of voice calls, is likely to be far higher than in the residential environment. The SB and Guest voice are admission controlled independently, but even without CAC, the SB voice can be protected. Page 28 of 31

29 8 IPR Statement, disclaimer and copyright The Home Gateway Initiative (HGI), formed in 2004, is an industry forum of Service Providers and Home Gateway, chip, software and other vendors, driving the architecture for the Home Network. HGI sets the technical requirements for Home Gateways and Home Networks that meet the service and business needs of Service Providers. The intention is to increase the costeffectiveness of Home Gateways and Home Networks by taking a global approach, involving the worldwide vendor and Service Provider community, referring to existing standards wherever possible, and working alongside other standard development organizations wherever gaps and inconsistencies in or between existing standards are identified. More about HGI can be found at This document is the output of the Working Groups of the HGI and its members as of the date of release. Readers of this document must be aware that it can be revised, edited or have its status changed according to the HGI working procedures. The HGI makes no representation or warranty on the contents, completeness and accuracy of this publication. This document, though formally approved by the HGI member companies, is not binding in any part on the HGI members. IPRs essential or potentially essential to the present document may have been declared in conformance to the HGI IPR Policy and Statutes available at the HGI website Any parts of this document may be freely reproduced (for example in RFPs and ITTs) by HGI and non-hgi members subject only to the following: HGI Requirement numbers not being changed an acknowledgement to the HGI being given in the resulting document. Trademarks and copyrights mentioned in this document are the property of their respective owners. The HGI membership list as of the date of the formal review of this document is: 2 Wire, Inc., Alcatel-Lucent, Arcor, AVM, Belgacom, BeWAN, Broadcom, BT, Cisco, Comtrend, Deutsche Telekom, D-Link Corporation, DS2, DSP Group, Echelon EMEA, Entropic Communications, Ericsson AB, Fastweb SpA, France Telecom, Freescale Semiconductor, Gigaset, Gigle Semiconductor, Huawei, Ikanos, Infineon Technologies AG, Intel, Intellon, JDSU, Jungo Software Technologies, KDDI, LG-Nortel Co Ltd, Marvell Semiconductors, Microsoft, Mitsubishi, NEC Corporation, Netgear, NTT, Philips, Pirelli Broadband Solutions, Portugal Telecom, Sagem, Sercomm, SoftAtHome, SiConnect, Spidcom, Swisscom AG, Telecom Italia, Telefonica, Telekom Slovenije, Telekom Malaysia, Telekomunikacja Polska, Telenor, TeliaSonera, Telstra, Thomson, Tilgin AB, TNO, U4EA Technologies Limited, Vtech, Zarlink, ZTE, ZyXEL Page 29 of 31

30 9 Glossary ADSL Asymmetric Digital Subscriber Line ALG Application Layer Gateway ALL Application Layer Logic ASP Application Service Provider ATM Asynchronous Transfer Mode BBF Broadband Forum BRAS Broadband Remote Access Server BSP Broadband Service Provider CAC Connection Admission Control CBR Constant Bit Rate DHCP Dynamic Host Configuration Protocol DLNA Digital Living Network Alliance DSCP Diffserv Codepoint EU End User GSM Global System Mobile GUI Graphical User Interface HD High Definition HG Home Gateway HN Home Network HNID Home Network Infrastructure Device IMS Internet Multimedia Subsystem LAN Local Area Network MAC Media Access Control MTU Maximum Transmission Unit NAS Network Attached Storage NAT Network Address Translation OTT Over The Top (e.g. Internet based service) PHY Physical (Layer) PLT Powerline Technology QoS Quality of Service SBG Service Border Gateway SIP Session Initiation Protocol SLA Service Level Agreement SP Strict Priority SP Service Provider SSID Service Set Identifier STB Set Top Box Page 30 of 31

31 TCP Transmission Control Protocol UDP User Datagram Protocol UMA Unlicensed Mobile Access VLAN Virtual LAN VoIP Voice over Internet Protocol WAN Wide Area Network WRR Weighted Round Robin Page 31 of 31