This Application claims priority benefit of German Patent Application 10 2011 011 400.9-31, which was filed on Feb. 17, 2011. The entire contents of the German Patent Application are hereby incorporated herein by reference.
The field of invention relates generally to Quality of Service (QoS).
The subscriber access line is a bottleneck for data transmission. At both sides of the line, within the public access network on one side and in the home network on the other side basically unlimited bandwidth is available. In the public network the backbone bandwidth is being increased by introduction of wavelength division multiplex (WDM) and in the public access network the introduction of gigabit Ethernet technology leads to considerable increase of bandwidth as well. In the home network next generation WLAN systems and Power-Line Communication (PLC) provide more and more bandwidth.
On the subscriber access line, also called first or last mile, a corresponding increase of bandwidth is not possible. Be it twisted pair copper, PLC (as access line) or any wireless technology the bandwidth is limited by physical limits (Shannon limit) and administrative limits (maximum transmit power, frequency bands). These limits can only be overcome by new physical technologies such as fiber optic, but this replacement by will need decades. Even some optical technologies such as Passive Optical Network (PON) have inherent bandwidth limits, especially in upstream direction.
Therefore we have today the scenario depicted in
Patent WO0309146A1 proposes a bandwidth reservation for the access network, especially for VoIP calls. The basic idea is again the concept that the network is the master. The difference is that request for bandwidth is not explicit, but the access network sniffs the signaling packets (SIP packets) exchanged between subscriber and VoIP provider and derives a reservation request from their content. Once the bandwidth is obtained the remaining procedure follows the POTS model. Subscriber data base and traffic management data base (
Also EP1453260 follows the POTS model. Central instance to manage resources in this case is the Edge Router.
In WO02/019055A2 an external Bandwidth Broker performs access control, but on behalf of the network. Hence this application follows the also the POTS model. Although the Bandwidth Broker seems to be similar to the Remote Resource Manager of this application there is a fundamental difference. The Remote Resource Manager acts on behalf of the subscriber via the Terminal Agents, while the Bandwidth Broker in WO02/019055A2 is the deciding instance of the network.
Several patents could be found describing methods and apparatus for bandwidth information management:
DE602004009677T2, U.S. Pat. No. 6,970,428B1, U.S. Pat. No. 5,905,715, US20090109976A1, US2011010444A1, U.S. Pat. No. 5,774,689.
These patents have a fundamental difference to the present application as they manage the total bandwidth on a link. In networking terms these are methods of the management plane, while this application is a method of the control plane. In the management plane the total bandwidth is statically configured, while in the control plane the dynamic sharing of the total bandwidth by the various flows on that link.
Therefore DE602004009677T2 und US2011010444A1 use layer 1 communication channels (Embedded Operations Channel EOC of DSL) or layer 2 communication channels (ATM Permanent Virtual Channel PVC) in U.S. Pat. No. 6,970,428B1 und US20090109976A1. This application operates at the layer 3, the Internet Protocol layer. It may use the methods of the mentioned patents to obtain the total bandwidth of a subscriber access line. Alternatively the so-called DSL speed test may be used to determine the total bandwidth of an access line.
The invention solves the problem exploiting the fact that the only remaining bottleneck in an end-to-end communication will be the subscriber access line. The new idea is that the subscriber is given control and responsibility over his access line to manage bandwidth sharing of application flows by himself. He does it according to the invention with the help of Terminal Agents in the terminals, a Remote Resource Manager and a Self-Sustaining Scheduler located at the bottlenecks of the data path, i.e. the endpoints of the subscriber access line.
The Self-Sustaining Scheduler has a well-known behavior in processing flows of different QoS classes, and this behavior is independent on load conditions. Hence it does not need any reconfiguration by the access network operator.
The Remote Resource Manager can be realized as Internet service acting as QoS service provider. It knows all flows of a customer and assures that no overload situation occurs in the Self-Sustaining Schedulers at both sides of the access line thanks to intelligent bandwidth management algorithms. A Remote Resource Manager can serve several customers/subscribers. It communicates with each customer via communication channels to Terminal Agents located in the terminals of a subscriber.
The Terminal Agents in the subscriber terminals can be realized as dedicated circuits, as software plug-in, as applet (App) or combinations of them. Pure software implementations have the advantage of being downloadable in existing equipment, while hardware implementations have higher performance. A Terminal Agent sends requests to the Remote Resource Manager and receives instructions how to enforce QoS methods locally within the terminal. QoS methods are basically flow send rates, flow packet marking and optionally remote control of flow receive rates.
Main advantage of the described solution is maintenance of network neutrality. Unlike existing “Triple Play” solutions QoS support is not limited to services offered by the access network provider, but can be provided for any application flow from everywhere in the world. The Remote Resource Manager is neutral to applications, as it does not need any information about the content of a service, only about its QoS parameters.
The Remote Resource Manager can be optimized for the purpose of bandwidth management and can offer QoS with high quality. Subscriber and service provider are relieved from this complex problem. Algorithms can be shared by all subscribers supported by a Remote Resource Manager. The access network operator is alleviated from the burden to guarantee the selected service class to the customer at any time. The only contribution of the access network operator is to install the Self-Sustaining Scheduler at the network side of the subscriber access line. The responsibility is finally at the subscriber assisted by the Remote Resource Manager via the Terminal Agents.
A further advantage of the invention is increased efficiency for data transmission. Today in case of overload at bottlenecks in the network packets are discarded and must be retransmitted end-to-end. The percentage of retransmitted packet is significant, as the prevailing Transmission Control Protocol (TCP) by intention uses packet losses as a measure to adjust the data rate. With an estimated power consumption of all Internet nodes of about 150 billion kWh per year reducing the amount of retransmission has a high potential of energy saving.
The solution proposed in this patent application differentiates in a key point from all known systems. In all network concepts, starting from the plain old telephone system (POTS) the network is the master. A subscriber requests a connection, for example by dialing, and either gets it assigned (he hears the ringing tone) or denied (he hears the busy tone). This “POTS Model” is used for mobile telephony as well and ITU-T planned to extend it for broadband networks under the denomination B-ISDN, but this was abandoned. Today a global solution for QoS over IP networks is in standardization by 3GPP (3rd Generation Partnership Project) under the denomination IMS (IP Multimedia Subsystem). Also IMS follows the POTS Model. This undertaking is even more complex than B-ISDN, so that a final solution is still far away.
In the present application the subscriber is the master. He has a set of resources assigned by the network and it is his decision which flow should be prioritized.
In the above mentioned Triple Play solution Internet, VoIP and TV/Video on Demand (VoD) are offered as a package with high quality. However, this solution only works if all three services are offered by the access network operator. Hence this solution disables network neutrality and unbundling. If a subscriber uses VoIP of another operator, Skype service or watches YouTube video the QoS is reduced to Best Effort.
B-ISDN solution could not cope with the fact that the content of one single web page can be composed by packet bursts from a manifold of servers. It is not practical to signal a dedicated connection for each burst. This application solves this problem by managing the bandwidth of all bursts at the destination point according to claim 12.
For VoIP there exists a setup procedure like in the POTS service using the Session Initiation Protocol (SIP), but it does not include QoS. The VoIP server basically communicates IP addresses only. There is no bandwidth reservation.
Embodiments of methods and apparatus for supporting QoS over subscriber access lines are described herein along with these Figures:
The whole concept is shown in
The end customer is subscribed at the Remote Resource Manager. All his terminals have Control Channels (K) from their Agents to the Remote Resource Manager. All bandwidth relevant information is communicated by the Terminal Agents to the Remote Resource Manager, so that is has at any moment the overview about the load situation of his customer.
The Self-Sustaining Scheduler is especially constructed to be configured statically. It operates based on the QoS marking in the data packets. QoS marking is done at the sources according to the directives of the Remote Resource Manager. Special fields in the IP packet header are used for marking.
The interworking of the components is described along with
In
Thanks to the precise bandwidth assignment for all application flows sharing the Self-Sustaining Scheduler by the Remote Resource Manager, the specified maximum load is not exceeded so that the applications can rely on the specified packet drop probabilities for each QoS class.
In case the available bandwidth is not sufficient to receive a video stream the Remote Resource Manager may decide to reduce other applications' bandwidth before enabling the video stream. This mechanism is described below with an example. The decision depends on preferences the customer has provided to the Remote Resource Manager at subscription time. Alternatively the video flow could also be rejected or delivered—with poor quality—using the lowest QoS class “Best Effort”.
The Remote Resource Manager has these tasks:
For the control channels to the terminals the Session Initiation Protocol (SIP) could be used. It is widely in use for VoIP, multimedia signaling and for mobile applications. With the optional embedded Session Description Protocol (SDP) it allows specification of QoS parameters. SIP would be ideal for a first implementation of the concept, as it is already available. Its drawback is the high parsing effort due to its plain text formats. For a volume introduction of the concept a more compact, binary coded control packet format would be more efficient. A preferred implementation is described below.
An example for intelligent bandwidth adjustment is described along with
The advantage of the present application becomes obvious in this example. Without intelligent bandwidth management the video source would just start sending packets at maximum speed. Due to packet collisions at the downstream scheduler both video stream and FTP packets would be dropped. Loss of FTP packets would lead to bandwidth reduction via TCP and then stepwise increase of FTP bandwidth until packet losses occur again. The two applications would permanently compete with each other with impairments for both applications.
An example for initiation of a video call is shown in
These functions are done by Terminal Agents.
In case of a VoIP phone with fixed bandwidth negotiation and packet rate adjustment are not needed. In this case the Remote Resource Manager would use a fixed bandwidth for VoIP channels. It is sufficient to know begin and end of the call. The SIP packets could be sent to the Remote Resource Manager which would act as VoIP server. Today's VoIP phones send packets with special QoS coding according to DiffServ, so that packet marking is not needed either.
In this example both subscribers have different Remote Resource Managers. They could also be subscribed at same Remote Resource Manager.
As can be seen from
In case the procedure of bandwidth assignment is too slow it could also done in parallel. Terminals start to exchange data immediately, but with packets marked with the lowest QoS class Best Effort. When the parallel process of bandwidth negotiation is concluded the assigned rate is adjusted by the terminals (via the Agents) and the packets are sent with the given QoS class. This procedure has the advantage that the subscriber immediately gets video and voice connectivity while the quality follows a bit later.
For bandwidth management the Remote Resource Manager needs the actual total bandwidth of the subscriber access line in up- and downstream direction. These values could be obtained via a so-called speed test initiated by the Remote Resource Manager and executed by an agent within the subscriber premises network.
For the application Internet browsing where data bursts are exchanged another mechanism is used for bandwidth control. Signaling available bandwidth to the sources would not be practical, as typical web sites are composed of data bursts coming from many different servers. TCP over IP is the basic protocol used for all web data transfer except audio/video data. TCP includes a flow control algorithm to limit the transmit rate to the processing rate of the receiver. By delaying TCP acknowledge packets (ACK) and/or by setting the Receive Window field in ACK packets the total receive bandwidth of all sources can be controlled. The TCP flow control loop has a certain latency which may lead to data burst accumulation in the Self-Sustaining Scheduler at the network side. Its buffer is dimensioned accordingly to buffer these bursts.
The Self-Sustaining Scheduler works autarkic with one fixed configuration which adapts automatically to changing load conditions. This is achieved by the preferred implementation according to
In
The 4 queues in
The Remote Resource Manager cooperates with the Self-Sustaining Scheduler of
The strict priority multiplexer serves queue 1 with highest priority. Only if queue 1 is empty queue 2 is served and only if queue 1 and 2 are empty the WRR multiplexer is served. This behavior can lead to starvation of the queues connected to lower priority inputs. Therefore the Remote Resource Manager uses peak rate reservation for the flows in queue 1 and 2, assuring that there is bandwidth left for flows forwarded by the other queues.
Queue 3 supports both streaming and burst applications. The latter are applications with so-called on-off traffic, as its generated for example by “classical” Internet browsing (without embedded video or audio) or by client-server computing. Peak reservation for on-off flows would be a waste of bandwidth resource, as their applications are not always sending data. For example in a web browser session a user could read a page for minutes and then click to the next page. During the silence period other applications could use the bandwidth. This is called statistical multiplexing. Reservation of minimum bandwidth assures that even if by coincidence of bursts from all applications there is still enough bandwidth for each application to continue to work. Some applications need a minimum bandwidth to work. For example in client-server computing acknowledge signals should not exceed certain time values. In an Internet browsing session a minimum rate is given by the patience of the user.
Hence the maximum size of queue 3 is combines peak rate reserved streaming flows and minimum rate reserved on-off flows. Using statistical methods the Remote Resource Manager keeps bandwidth reservation below a certain limit, so that packet drop probability due to overflow is maintained below a given limit, in the preferred implementation 10−7. For on-off flows this drop rate is guaranteed only for rates up to the guaranteed minimum rate; packets exceeding the minimum rate must be marked by the source with low importance. These are allowed to fill queue 3 up to the threshold, but are discarded when the fill level is beyond the threshold. In other words less important packets are forwarded only if queue 3 is almost empty.
The correct marking of packet importance must be assured by the terminal either content agnostic or content aware. In the content aware option the application provides important and less important packets. For example a video source could mark packets of the basic video stream as important, while packets of the enhancement stream could be marked as less important. The rate of the basic video stream would have to be reserved. In the content unaware option the Terminal Agent does the marking by rate measurement without looking at the content.
Loss of basic stream packet could lead to loss of picture synchronization and hence cause a severe distortion with picture breakdown, while the loss of an enhancement packet would only temporarily reduce picture sharpness in a part of the picture. Similarly a data stream could be split at the source in important and less important packets. For example a web page could have important data such as the list of articles and prices, while background image could be marked as less important.
The threshold of queue 3 hence is essential for statistical multiplexing. Locating at about 10% of maximum size (preferred implementation) has two effects, obtained from statistical calculus:
The lowest priority QoS class is called Best Effort. It has no guarantees in delay and drop probability, but a minimum serving rate is guaranteed by the WRR multiplexer. In the preferred implementation about 3% of queue 3 serving rate is used for queue 4. This seems to be a low value, but as all applications are assigned the QoS class and the bandwidth they need only few packets will use queue 4.
In the current Internet all packets are treated with the same priority. If network operators would provide high and low priority support everyone would send data with high priority only. Hence an enforcing function such as QoS flow rate policing per subscriber would be needed. This is part of the classical POTS-like approach. The concept of this invention exploits the fact that each subscriber is responsible for his own traffic. He is motivated to mark packets correctly with the priority assigned by the Remote Resource Manager to assure optimum QoS for all flows.
All queue sizes are guaranteed by the Self-Sustaining Scheduler in absolute time values, with the preferred time values given in Table 1. It is realized by receive time stamps for each packet which are checked when the packet is read from the queue for transmission. If the delay exceeds the given value for the queue the packet is discarded. This has the advantage for the application that it must not wait more than a given time for a packet. In a streaming application it might be abandoned while in data applications retransmission will be requested.
For the threshold of queue 3 also a time value is specified, but it is checked by a different mechanism. When a packet of low importance arrives its arrival time is compared with the arrival time of the longest waiting packet in queue 3 and if this value exceeds the given maximum the packet is dropped.
Absolute time values have the advantage that no re-adjustment is necessary. Time limits and the special arrangement of strict priority and WRR schedulers constitute the Self-Sustaining Scheduler.
The preferred implementation of the QoS classes also includes maximum packet size values (Table 1). Optionally the Self-Sustaining Scheduler could also supervise these values and discard exceeding packets.
Specification of QoS classes must fit to the Self-Sustaining Scheduler and also to the bandwidth reservation algorithms of the Remote Resource Manager.
In the preferred implementation 4 QoS classes are specified with one of them (EL) having 2 importance levels as shown in Table 1.
Table 1 contains the maximum latency and drop probability values which are guaranteed when the packet size does not exceed the maximum allowed value. In the DiffServ column the preferred mapping of DSCP values to the QoS classes is specified. The DiffServ standard RFC4594 specifies 64 DSCP values with 63 having highest (relative) priority and 0 the lowest. In Table 1 DSCP value ranges are assigned to the 4 classes and importance levels.
Split of EL class into 2 importance levels allows statistical multiplexing with minimum guaranteed bandwidth reservation as described with the Self-Sustaining Scheduler above.
The preferred QoS class selection of Table 1 has these advantages:
The QoS classes are a key part of the concept. The Remote Resource Manager assigns peak or guaranteed minimum bandwidth to the applications and the Agents in the terminals must control the send rates of each flow and mark the packets with the right DSCP coding. In case of EL class the marking can also be dynamic (tagging) depending on send rate. If the bandwidth conditions are fulfilled the Self-Sustaining Scheduler guarantees the packet drop rates.
The QoS of a packet stream can be completely described using three orthogonal parameters Guaranteed Rate, QoS Class and Retention Priority.
The Guaranteed Rate is the bandwidth to be reserved by the Remote Resource Manager and it is used by the Terminal Agents to shape the sent packet streams. A Guaranteed Rate for the low importance EL stream must not be specified or maintained.
The QoS class is assigned to the application flows by the Remote Resource Manager knowing the customer preferences. Optionally the Terminal Agents can hide the application and provide the QoS parameters to the Remote Resource Manager which then has to check the available bandwidth and optionally modify existing flow rates according to the customer preferences. The Self-Sustaining Scheduler uses QoS class and importance level for scheduling.
The Retention Priority of a flow is needed by the Remote Resource Manager only to solve bandwidth conflicts as described above with the example of
Table 2 shows a preferred coding of the 3 QoS parameters.
For the Guaranteed Rate multiples of 100 kbit/s are proposed. A 16 bit value allows specification of guaranteed rate values up to 65 Mbit/s.
For the 4 QoS classes 2 bit are sufficient, as the 2 importance levels of the EL class must not be specified. The Guaranteed Rate is always related to the high importance stream.
For the Retention Priority a 4 bit value allows 16 different values.
The Remote Resource Manager is in some embodiments indicated as being external to the network where the data is forwarded. However, this does not exclude the option that the Remote Resource Manager is in the subscriber network, the home network. In this case the Remote Resource Manager might favorably be included in the modem or home gateway, which could also contain some Terminal Agents acting as proxy for terminals which do not include Terminal Agents.
This option is based on the idea to make the classifier in the Self-Sustaining Scheduler more intelligent, more complex, but still self-sustaining. The flow classifier in
As a remedy a configurable classifier in the Self-Sustaining Scheduler could explicitly learn from the subscriber which flows which flows should be prioritized. All other flows would be assigned to the default QoS class (Best Effort). If a subscriber wants to receive an incoming flow with higher priority the respective Terminal Agent identifies the packets by a suitable combination of header fields and sends this identification back in upstream direction to the DSLAM together with the desired QoS class.
The other part of the process, bandwidth assignment by the Remote Resource Manager and transfer of this information to the involved terminals is unchanged.
At the network side of the DSL line the Self-Sustaining Scheduler is enhanced by a configurable classifier as shown in
The configurable classifier can learn a given number of flows, for example 100 flows per subscriber. For this purpose it contains a table of 100 entries consisting of flow identification and the associated QoS class. The classifier as well as the whole Self-Sustaining Scheduler is assigned uniquely to one subscriber.
The flow identification in case of IPv6 could be the Flow Label, a 20 bit field in the IPv6 packet header. According to RFC3697 Flow Labels should be assigned in such a way that different flows do not receive the same Flow Label. Hence the combination of IP source address and Flow Label is a unique identifier for an IPv6 packet flow. Advantage of the Flow Label field is that it is not included in IPsec protection and hence can be modified in between endpoints, for example by the home gateway. In case of IPv4 a combination of IP source address, DSCP and TCP/UDP port number could be used for flow identification.
The classifier must explicitly learn the labels and the associated QoS class. For this purpose a control channel from Terminal Agents to the classifier in the Self-Sustaining Scheduler is used, preferably with a compact packet format. For Ethernet access networks a layer two frame with a suitable Ether-type value could be used. The protocol does not need acknowledgement, as the result can be noticed. In case of a lost control packet it would be retransmitted after timeout.
The classifier maintains the list of entries in a self-sustaining way. If the user asks for more entries than available the oldest exiting entry is replaced by the new one. Similar to Ethernet MAC tables unused entries would age out after a certain time. When a user packet is received the classifier checks all entries and if the flow identification is not found the packet is forwarded with default QoS class, typically Best Effort.
The above description of illustrated embodiments of the invention, including what is defined in the Abstract, is not intended to be exhaustive or to limit the invention to the precise forms disclosed. While specific embodiments of, and examples for, the invention are described herein for illustrative purposes various equivalent modifications are possible within the scope of the invention, as those skilled in the relevant art will recognize.
These modifications can be made to the invention in light of the above detailed description. The terms used in the following claims should not be construed to limit the invention to the specific embodiments disclosed in the specification and the drawings. Rather, the scope of the invention is to be determined entirely by the following claims, which are to be construed in accordance with established doctrines of claim interpretation.
Number | Date | Country | Kind |
---|---|---|---|
102011011400.9-31 | Feb 2011 | DE | national |