Passive measurements of network speed

Abstract

Disclosed herein are technologies for measuring the speed experience of a customer of a network provider. The technologies provide a quality of experience (QoE) speed metric that better characterizes the customer experience. The technologies use scheduling epoch statistics to replace or augment active speed measurements. The technologies further provide a new way to measure QoE speed metrics by adapting the measured network application speed experienced by a customer to incorporate customer demand. The disclosed QoE speed metrics can be used to determine a level of congestion in a communications network.

Description

PASSIVE MEASUREMENTS OF NETWORK SPEEDBACKGROUNDField

[0001] The present disclosure generally relates to determining speed metrics for network communications.Description of Related Art

[0002] Internet service providers (ISPs) offer network access to customers and may have different tiers of service with different advertised network speeds. Customers may decide on which ISP to use and to which tier to subscribe based at least in part on the offered network speeds. Network speed or throughput is typically measured using active measurement techniques. Active speed measurements involve introducing traffic into the network, or probe traffic, and tracking the probe traffic to measure network speed based at least in part on the time it takes the probe traffic to traverse one or more network links.SUMMARY

[0003] According to a number of implementations, the present disclosure relates to a method for passively measuring a speed metric for a service flow class. The method includes determining by a component of a communications system a service flow class that includes one or more service flows. The method also includes for each of a plurality of scheduling epochs, determining: a maximum burst byte length among the one or more service flows of the service flow class; a service flow class epoch speed, or SFC epoch speed, based at least in part on the maximum burst byte length; and a service flow class epoch weight, or SFC epoch weight, based at least in part on the maximum burst byte length. The method also includes calculating an interval speed experience for the service flow class, the interval speed experience corresponding to a network speed experienced by a service flow in the communications system, the interval speed experience being a weighted average of a plurality of SFC epoch speeds using a corresponding plurality of SFC epoch weights.

[0004] In some aspects, the method further includes computing a scheduling quantum, F, corresponding to a share of transmission capacity for aservice flow within the service flow class; and a weighted fair share, F weight, corresponding to a product of the scheduling quantum and a scheduling weight of the service flow class.

[0005] In some aspects, the method further includes calculating an interval speed offer for the service flow class, the interval speed offer corresponding to a network speed offered by a communications network, the interval speed offer calculated by: determining an epoch speed offer for each of the plurality of scheduling epochs, the epoch speed offer for each scheduling epoch being set equal to a smallest value between C, SFC_MSTR, and (SFC_MRTR + F_weight / T_E), where C is a carrier capacity of the communications system, SFC_MSTR is a maximum sustained transmission rate (MSTR) for the service flow class, SFC_MRTR is a minimum reserved transmission rate (MRTR) for the service flow class, and T_E is a duration of the scheduling epoch; and computing an average of the plurality of determined epoch speed offers.

[0006] In some aspects, each SFC epoch speed is equal to: a smallest value between C and SFC_MSTR responsive to the maximum burst byte length being less than F weight; and a smallest value between C, SFC_MSTR, and (SFC_MRTR + F_weight / T_E) responsive to the maximum burst byte length being greater than or equal to F weight.

[0007] In some aspects, each SFC epoch weight is equal to: the maximum burst byte length divided by C * T_E responsive to the maximum burst byte length being less than F weight; and a value of one responsive to the maximum burst byte length being greater than or equal to F weight.

[0008] In some aspects, a priority of the service flow class is designated as congested responsive to the maximum burst byte length being greater than or equal to the weighted fair share.

[0009] In some aspects, the interval speed experience approaches the interval speed offer responsive to an increase in the number of SFC epoch weights of the plurality of SFC epoch weights with a value of one.

[0010] In some aspects, the interval speed experience approaches the carrier capacity responsive to a decrease in the number of SFC epoch weights of the plurality of SFC epoch weights with a value of one.

[0011] In some aspects, the interval speed experience approaches the SFC_MSTR responsive to a decrease in the number of SFC epoch weights of the plurality of SFC epoch weights with a value of one.

[0012] In some aspects, the interval speed offer is determined without introducing additional network traffic into the communications system.

[0013] In some aspects, each service flow in the service flow class has the same quality of service configuration and scheduling weight.

[0014] In some aspects, each service flow in the service flow class has the same priority, minimum reserved transmission rate, maximum sustained transmission rate, and scheduling weight.

[0015] In some aspects, each service flow in the service flow class has the same service data flow ID, packet data flow ID, and weight triplet.

[0016] In some aspects, calculating the interval speed experience is performed by the component of the communications system.

[0017] In some aspects, the method further includes determining a service-level congestion index including the interval speed experience for the service flow class normalized by a target speed for the service flow class.

[0018] In some aspects, the method further includes, for each scheduling epoch, transmitting to a quality of service monitoring system the maximum burst byte length and a scheduling quantum, F, corresponding to a share of transmission capacity for a service flow within the service flow class.

[0019] In some aspects, calculating the interval speed experience is performed by the quality of service monitoring system.

[0020] According to a number of implementations, the present disclosure relates to a scheduler for a communications system that transmits data between a plurality of client devices and a network. The scheduler includes a network interface for communicating with the plurality of client devices and the network. The scheduler includes a non-transitory computer-readable medium storing processorexecutable instructions. The scheduler includes a processor communicatively coupled to the network interface and the non-transitory computer-readable medium, the processor-executable instructions configured to cause the processor to: determine a service flow class that includes one or more service flows; for each of a plurality of scheduling epochs, determine a maximum burst byte length among the one or more service flows of the service flow class, a service flow class epochspeed, or SFC epoch speed, based at least in part on the maximum burst byte length, and a service flow class epoch weight, or SFC epoch weight, based at least in part on the maximum burst byte length; and calculate an interval speed experience for the service flow class, the interval speed experience being a weighted average of a plurality of SFC epoch speeds using a corresponding plurality of SFC epoch weights.

[0021] According to a number of implementations, the present disclosure relates to a communications system configured to transmits data between a plurality of client devices and an external network. The communications system includes an access network that communicates data between the external network and the plurality of client devices. The communications system includes a gateway communicatively coupled to the access network and to the external network, the gateway configured to manage data transmissions to and from the plurality of client devices and to manage data transmissions to and from the external network. The communications system includes a scheduler communicatively coupled to the gateway. The scheduler is configured to determine a service flow class that includes one or more service flows; for each of a plurality of scheduling epochs, determine a maximum burst byte length among the one or more service flows of the service flow class, a service flow class epoch speed, or SFC epoch speed, based at least in part on the maximum burst byte length, and a service flow class epoch weight, or SFC epoch weight, based at least in part on the maximum burst byte length; and calculate an interval speed experience for the service flow class, the interval speed experience being a weighted average of a plurality of SFC epoch speeds using a corresponding plurality of SFC epoch weights.

[0022] In some aspects, the access network includes one or more satellites.

[0023] For purposes of summarizing the disclosure, certain aspects, advantages and novel features have been described herein. It is to be understood that not necessarily all such advantages may be achieved in accordance with any particular embodiment. Thus, the disclosed embodiments may be carried out in a manner that achieves or optimizes one advantage or group of advantages as taught herein without necessarily achieving other advantages as may be taught or suggested herein.BRIEF DESCRIPTION OF THE DRAWINGS

[0024] FIG. 1 A illustrates an example communications network that provides access to an external network (e.g., the Internet) to a plurality of clients.

[0025] FIG. 1 B illustrates an example satellite communications network.

[0026] FIGS. 2A, 2B, and 2C illustrate data delivery for a network application over a plurality of scheduling epochs.

[0027] FIG. 3 illustrates an example of data units from a plurality of service flows in a service flow class being transferred over a plurality of scheduling epochs.

[0028] FIG. 4 illustrates a flow chart of an example method for passively measuring a speed metric for a service flow class.

[0029] FIG. 5 illustrates a flow chart of an example method for determining a service flow class epoch speed.

[0030] FIG. 6 illustrates a flow chart of an example method for determining congestion in a communications network.

[0031] FIG. 7 illustrates a block diagram of a component of a communications system, such as a scheduler or gateway, examples of which are described herein with reference to FIGS. 1 A and 1 B.DETAILED DESCRIPTION OF SOME EMBODIMENTS

[0032] The headings provided herein, if any, are for convenience only and do not necessarily affect the scope or meaning of the claimed invention.Overview

[0033] Network speed is a system metric often used to measure or characterize a network carrier, where the network speed may correspond to a speed at which the network carrier can transfer data packets. However, network service providers are shifting away from thinking about network service in terms of upload and download speeds, or a quality-of-service (QoS), to focusing on a quality of experience (or QoE) for customers using various Internet applications. As used herein, the quality of experience, or QoE, can refer to the customer’s perceptions of a service provider’s network based on the customer’s experience using the service provider’s network. The QoE is influenced by the customer’s expectations and experiences which, in a network, relate to the expected network speed (e.g.,the bandwidth offered, advertised, or promised by the service provider) and the experienced network speed (e.g., the bandwidth actually experienced by the customer). To measure and understand the customer experience, then, it is desirable to define and to develop network speed metrics that more closely measure the quality of experience of the customer.

[0034] Techniques exist that attempt to measure network speeds. For example, network speed measurements such as active speed measurements (ASM) or embedded service platform (ESP) speed tests can be used to provide information on certain aspects of the customer’s network speed on the service provider’s network. However, such measurements may not fully represent the network speed experienced by the customer. In addition, service providers may offer network speeds as part of service level agreements with customers and customers may expect to experience the offered network speeds. However, the offered network speed may not represent the network speed experienced by the customer when the customer does not have enough data demand to utilize the allocatable capacity, when the customer is experiencing high latency, and so forth.

[0035] Furthermore, although active speed measurements may accurately measure network speeds, such measurements introduce additional traffic into the network, which may be undesirable. In addition, active speed measurements may not accurately measure or reflect the network speed experienced by a customer due at least in part to the active speed measurements measuring only certain aspects of network speed over a communications system or over portions of the communications system.

[0036] Accordingly, to address these and other issues, disclosed herein are systems and methods for measuring the speed experience of a customer of a network service provider. The disclosed systems and methods provide a QoE speed metric that better characterizes the customer experience. The disclosed technologies use scheduling epoch statistics published by a scheduler and / or gateway in a communications network to replace or to augment active speed measurements. The technologies described herein further provide a way to measure a QoE speed metric for a customer by adapting the measured network application speed experienced by a customer to incorporate customer demand. In addition, the disclosed QoE speed metrics can advantageously be used to determine a level of congestion in a communications network. Moreover, the speedmeasurement techniques disclosed herein can be useful for communication and capacity management. For example, the measurement results can be used as feedback to control systems to manage network capacity. For example, network capacity below target offered speeds can be allocated during periods of low data demand.

[0037] The technologies described herein may determine a speed experience of a network application. The speed experience, as described herein, is a metric configured to represent the network speed experienced by a customer or the network speed from the point of view of the customer. The speed experience, then, is part of what affects or influences the quality of experience of the customer. The speed experience of a network application can be based on the consumption of data units as determined using statistics from a scheduler, a gateway, or other component or subsystem of a communications system. For example, a network application can consume a stream of data that is sufficiently small such that the entire stream of data is delivered in a single scheduling epoch, also referred to as a small data unit. The speed experience associated with that network application can be computed based on the byte length of the small data unit, the duration of transmission of the small data unit, and the carrier capacity. As another example, a network application can consume a stream of data that is sufficiently large such that the entire stream of data requires multiple scheduling epochs to be delivered, also referred to as a large data unit. In such instances, the stream of data can be divided into data chunks with each data chunk being sized so that it can be delivered in a single scheduling epoch. The speed experience associated with that network application can be computed based on the byte length of the large data unit, the byte lengths of the data chunks delivered in respective scheduling epochs, and the duration of a scheduling epoch. As another example, a network application can consume a stream of data that includes a mixture of small data units (e.g., data units that can be delivered within a single scheduling epoch) and large data units (e.g., data units that are delivered over a plurality of scheduling epochs). The speed experience associated with that network application can be computed based on the total number of transferred data unit bytes and the total transmission time of the data units.

[0038] Service flow classes can be used to extend the concept of the speed experience for a network application, a network application (e.g., a layer 3or 4 application) being associated with a service flow (a layer 2 connection). Although it is possible to measure the speed experience of individual network applications, this may introduce undesirable overhead for communications systems, or components in a communications system such as a scheduler or gateway. Thus, the disclosed technologies can define a service flow class that groups a plurality of similar service flows together. To define a service flow class, service flows can be grouped together based on shared characteristics such as, for example and without limitation, priority, minimum reserved transmission rate (MRTR), maximum sustained transmission rate (MSTR), scheduling weight, etc. For the service flow class, the disclosed technologies can be used to determine the speed experience of the service flow class (SFC), or the SFC speed experience. The SFC speed experience can then be used to represent the speed experience of each service flow (and associated network application) in the service flow class. To determine the SFC speed experience, an imaginary network application can be used to act as a representative network application of the service flow class. The characteristics (e.g., data unit size) of the imaginary network application are constructed using the characteristics of the service flows in the service flow class. For example, the data unit size of the imaginary network application in a particular scheduling epoch can be set to be equal to the largest data unit of the service flows in the scheduling epoch. This process can be repeated for each scheduling epoch to build the imaginary network application. This imaginary network application can then be used in the speed experience calculations described herein in place of the network application of a particular service flow to determine the SFC speed experience. Thus, the SFC speed experience is representative of the speed experience for individual service flows in the service flow class without requiring that the speed experience be calculated for each service flow. The SFC speed experience can be calculated for each scheduling epoch and, in some implementations, the SFC speed experience can be calculated over an interval comprising a plurality of scheduling epochs. By using the imaginary network application constructed in this manner, the SFC speed experience advantageously represents the lower bound speed experience of service flows within the service flow class. In other words, the SFC speed experience represents the speed experience of a service flow if that service flow had the longest data burst in each scheduling epoch within the service flow class.

[0039] As set forth herein, the quality of experience of a customer can be related to the customer’s expectations and experience. The speed experience metric described herein can be related to the customer’s experience. In addition, a speed offer metric can be related to the customer’s expectations. The speed offer can represent a customer’s share of network bandwidth or the network bandwidth made available to the customer. This does not necessarily mean that the customer will use the customer’s share of network bandwidth. The speed offer metric can be extended to represent the speed offer to service flows in a service flow class, or an SFC speed offer, similar to the relationship between the speed experience and the SFC speed experience. The SFC speed offer is a metric that represents a virtual pipe size (e.g., network capacity or bandwidth) through a communications system allocated to service flows in the service flow class. As described in greater detail herein, the SFC speed offer can be determined based on the carrier capacity of the communications system, a maximum sustained transmission rate (MSTR) for the service flows in the service flow class, and scheduling parameters of the service flow class.

[0040] Moreover, the speed experience metric and the speed offer metric can be calculated over an interval that includes multiple scheduling epochs to derive an interval speed experience metric and an interval speed offer metric. For example, the interval speed experience can be calculated by averaging the SFC speed experience for individual scheduling epochs over an interval that includes a plurality of scheduling epochs. Similarly, the interval speed offer can be calculated by averaging the SFC speed offer for individual scheduling epochs over an interval that includes a plurality of scheduling epochs. As the number of epochs with a demanding service flow class increases (e.g., a service flow class with lots of data to transfer), the interval speed experience approaches the interval speed offer. Relatedly, as the number of epochs with a demanding service flow class decreases, the interval speed experience approaches the smaller of the carrier capacity or the maximum sustained transmission rate of the service flow class.

[0041] To illustrate the relationship between the speed experience and offer metrics and the quality of experience of a customer, the following example is provided. A customer that is not using throughput-intensive applications will not experience a difference between the offered speed and the experienced speed. In other words, the network applications the customer uses will transfer data asexpected without experiencing unexpected delays or buffering because the bandwidth the customer is using is smaller than the bandwidth available to the customer. This translates to a high quality of experience for the customer because the customer cannot tell any difference between the experienced speed and the offered speed. This is true even though the customer may not be actually using the offered speed.

[0042] Advantageously, the speed experience metric and the speed offer metric described herein can be measured passively. For example, the measurement techniques do not require any additional probe traffic to be introduced into a communications system. Rather, service flow statistics are extracted from communication system components and / or subsystems and these service flow statistics are used to determine offered speeds and experienced speeds to better understand the speed experience of a customer on the communications network and to identify congestion.Example Communications Networks

[0043] FIG. 1 A illustrates an example communications network 100a that enables communication between a plurality of clients 1 10 and an external network 160 (e.g., the Internet). The communications network 100a includes a communications system 140a having a scheduler 130a, a gateway 150a, and a quality-of-service monitor 145. The communications system 140a is configured to manage network traffic between the plurality of clients 1 10 and the external network 160. In some embodiments, the communications system 140a can be a wireless communications system configured to wirelessly communicate at least a portion of the network traffic. In certain embodiments, the communications system 140a can be a terrestrial communications system. In various embodiments, the communications system 140a can be a satellite communications system. In some embodiments, the communications system 140a is a combination of terrestrial, wireless, and / or satellite communications systems.

[0044] The scheduler 130a is configured to manage network resources. To send data to the external network 160, the scheduler 130a allocates network resources to the plurality of clients 1 10, creating a schedule of transmission for devices. Then, based on the schedule, the individual clients of the plurality of clients 1 10 transmit data using the allocated resources. Similarly, to send data fromthe external network 160 to the plurality of clients 1 10, the scheduler 130a allocates network resources to network devices and components configured to transmit data over the communications system 140a to the plurality of clients 1 10, creating a schedule of transmission for those devices.

[0045] The gateway 150a is configured to direct network traffic between the plurality of clients 1 10 and the external network 160. The gateway 150a can receive network traffic from network applications and direct the received network traffic to a targeted destination in the external network 160. Similarly, the gateway 150a can receive network traffic from the external network 160 and direct the network traffic to the intended recipient client of the plurality of clients 110. The gateway 150a can manage network traffic divided into service flows, as described herein.

[0046] The scheduler 130a can be configured to allocate network resources to service flows from the plurality of clients 1 10 and / or to allocate network resources to service flows destined for plurality of clients 1 10. In some implementations, the scheduler 130a can allocate resources using scheduling frames that divide time into discrete chunks referred to as scheduling epochs. Each scheduling frame can be divided into a plurality of scheduling epochs with each scheduling epoch having a duration (e.g., 1 ms, 5 ms, 20 ms, etc.). Within a scheduling epoch, resource blocks can be allocated to individual client devices. Each resource block can represent an allocation of network resources such as frequency and time. Each scheduling epoch is capable of transmitting a certain amount of network data within the scheduling epoch. The scheduler 130a can be configured to allocate network resources to multiple clients of the plurality of clients 110 within a single scheduling epoch.

[0047] The quality-of-service monitor 145 is configured to monitor network performance based on performance metrics associated with the scheduler 130a and the gateway 150a. In some implementations, the quality-of-service monitor 145 is configured to receive network performance parameters and statistics from the scheduler 130a and the gateway 150a and to derive speed metrics to monitor a quality of experience of the plurality of clients 1 10. The speed metrics and / or the quality of experience can be determined using the techniques disclosed herein. In some implementations, the scheduler 130a and / or the gateway 150a determine the speed metrics, which can then be shared with the quality-of-service monitor 145. In some implementations, the quality-of-service monitor 145 is configured to use speed metrics and / or other performance metrics to manage network performance in the communications system. This can be done to ensure a satisfactory quality of experience for the plurality of clients 110.

[0048] FIG. 1 B illustrates an example satellite communications network 100b. The satellite communications network 100b includes a satellite network 140b that communicatively couples client devices 1 10a, 1 10b and a gateway 150b to one another and to the external network 160 (such as the Internet). The satellite communications network 100b includes a scheduler 130b configured to allocate network resources to the client devices 1 10a, 1 10b. The gateway 150b is similar to the gateway 150a described herein with reference to FIG. 1 A and the scheduler 130b is similar to the scheduler 130a described herein with reference to FIG. 1 A.

[0049] The satellite communications network 100b may utilize various network architectures that include space and ground segments. For example, the space segment may include one or more satellites, while the ground segment may include one or more satellite user terminals, gateway terminals, network operations centers (NOCs), satellite and gateway terminal command centers, and / or the like. Some of these elements are not shown in the figure for clarity. The satellite network 140b can include a geosynchronous earth orbit (GEO) satellite or satellites, a medium earth orbit (MEO) satellite or satellites, and / or a low earth orbit (LEO) satellite or satellites.

[0050] The client devices 1 10a, 1 10b can include a router and can be configured to receive data to be routed over the satellite communications network 100b. The client devices 1 10a, 110b can include any type of consumer premises or mobile equipment (e.g., a telephone, modem, router, computer, set-top box, and the like).

[0051] The client devices 110a, 110b are configured to route data to the satellite network 140b (via respective customer satellite transceivers 120a, 120b). The satellite network 140b includes a forward link for sending information from the gateway 150b to the client devices 1 10a, 1 10b, and a return link for sending information from the client devices 110a, 1 10b to the gateway 150b. The forward link includes a transmission path from the gateway 150b through a gateway satellite transceiver 131 , through a satellite 105 via a satellite uplink channel, to the customer satellite transceivers 120a, 120b via a satellite downlink channel, and tothe client devices 1 10a, 110b. The return link includes a transmission path from the customer satellite transceivers 120a, 120b, to the satellite 105 via the satellite uplink channel, to the gateway satellite transceiver 131 via the satellite downlink channel, and to the gateway 150b. Each transmission channel may utilize multiple satellites and transceivers.

[0052] Each of the client devices 1 10a, 110b is configured to request return-link grants on the satellite network 140b from the scheduler 130b via the gateway 150b. The scheduler 130b determines a return-link allocation schedule and transmits it to each client device 1 10a, 1 10b via the gateway 150b. The scheduler 130b can utilize any suitable scheduling technique such as a demand assigned multiple access (DAMA) scheduling model, an enhanced mobile satellite services (EMSS) scheduling model, and the like. Responsive to receiving a request for bandwidth allocation from the client devices 1 10a, 1 10b, the scheduler 130b analyzes the request, network status, network congestion, prior requests, similar requests, and the like to determine a schedule for return-link bandwidth. Data may be transmitted from a particular client device 1 10a, 1 10b through the satellite 105 to the gateway 150b using bandwidth requested by the client devices 110a, 1 10b and allocated by the scheduler 130b.

[0053] Based on the allocated resource grants from the scheduler 130b, the client devices 110a, 1 10b transmit data to the gateway 150b through the satellite network 140b via the return link. After reaching the gateway 150b, the data can then be directed to the external network 160. Data from the external network 160 can be sent to the client devices 1 10a, 110b by the gateway 150b via the forward link of the satellite network 140b. The scheduler 130b can allocate network resources on the forward link similar to the return link, as described herein. In some implementations, part or all of the gateway 150b and / or the scheduler 130b can be located in a virtual device residing in a public or private computing cloud.

[0054] As discussed herein, the communications systems 140a and / or the satellite network 140b (or any component thereof such as the scheduler 130a, 130b, the gateway 150a, 150b, or the quality-of-service monitor 145) can be configured to passively determine speed measurements for network applications of a service flow. By way of example, the scheduler 130a, 130b can determine speed measurements or speed metrics as disclosed herein. As another example, the scheduler 130a, 130b can export relevant network statistics or parameters,such as the scheduling quantum, to the gateway 150a, 150b or the quality-of- service monitor 145. These components can then use the received parameters to determine speed measurements or speed metrics for service flow classes. The determined speed metrics may also be implemented for managing network traffic management. For example, the quality-of-service monitor 145 can use determined speed metrics as an input to a network control system.

[0055] The disclosed systems and methods function in any suitable network communications system. For example, the network communications system can be provided by satellites, by terrestrial-based equipment, or a combination of satellites and terrestrial networks. Thus, the concepts disclosed herein regarding passive speed measurements can be applied to service flows or similar logical network data structures provided by any variety of network communications systems.Passive Speed Measurements for a Network Application

[0056] To describe passive speed measurements for service flows, it is beneficial to first describe passive speed measurements for network applications. FIGS. 2A, 2B, and 2C illustrate data delivery for a network application over a plurality of scheduling epochs. Based on the different data delivery configurations, there may be different techniques for passively measuring a speed experience for the network application.

[0057] A typical network application consumes a data unit delivered over a network when the entire data unit is received. For example, a VoIP application can convert a digital voice sample to sound when the transmission of the entire data unit comprising the digital voice sample is complete (e.g., when an entirety of the data unit is transferred and received). The speed experienced by a network application consuming a data unit that can be delivered in a single scheduling epoch (e.g., a small data unit) can be measured by dividing the size of the data unit by the amount of time it took to transmit the data unit, an example of which is illustrated in FIG. 2A. This is beneficial because it accounts for the fact that all of the data was delivered over a short period of time. The resulting calculated speed experience thus reflects the speed experienced by the network application because data transfer speeds alone are only an aspect of the overall experience provided by the VoIP application.

[0058] Here, because the data unit is completely transferred each epoch, the speed experience, S_x, is:where B U is the byte length of the data unit, T U is the transmission time of the data unit, C is the carrier capacity of the communications network (e.g., measured in bits per second or symbols per second), and MSTR is the maximum sustained transmission rate (if defined) of the network application (e.g., measured in bits per second or symbols per second). MSTR may be defined for a network application or a service flow and may be included in quality-of-service parameters associated with the network application or service flow.

[0059] Thus, when a data unit is completely delivered in a scheduling epoch, the speed experience is either the promised or configured maximum sustained transmission rate or the carrier capacity of the communications network, if the carrier capacity is smaller than the maximum sustained transmission rate. In other words, the speed experience corresponds to the network speed available or reserved for the network application even though the full network capacity was unnecessary to transfer the data unit.

[0060] On the other hand, the speed experience of a network application that consumes a data unit that requires multiple scheduling epochs to be delivered (e.g., a large data unit) can be determined using a different computation, an example of which is illustrated in FIG. 2B. Because the data unit is too large to be delivered in a single scheduling epoch, the data unit can be divided into chunks and transmitted over multiple scheduling epochs. Here, because the data unit is not completely transferred in a single scheduling epoch but rather spans over a plurality of scheduling epochs, the speed experience, S_x, is:where B_U is the byte length of the data unit, B_K_i is the byte length of an individual chunk of the data unit transmitted in the i-th scheduling epoch, T il is the transmission time of the data unit, T_E is the duration of a scheduling epoch, S_K_i represents the chunk speed (B_K_i / T_E) of the i-th scheduling epoch, and T U / T E approximates the number of chunks of the data unit. Thus, the speed experience for large data units is determined by averaging the chunk speeds inindividual scheduling epochs over the transmission time of the data unit. As described in greater detail herein, the size of each data chunk may differ in each scheduling epoch even though the duration of each scheduling epoch may stay the same. This is due at least in part to a fair share of network resources calculated by the scheduler for a service flow.

[0061] These concepts can be extended to the speed experience of a network application that consumes a mix of small data units (e.g., data units that can be delivered in a single scheduling epoch) and large data units (e.g., data units that require multiple scheduling epochs to deliver), an example of which is illustrated in FIG. 2C. The speed experience of the network application in this situation can be determined by dividing the total size of the transferred data units by the total transmission time of the data units. In an example application that consumes a small data unit and a large data unit, a weighted average is calculated based on an epoch speed and an averaging weight used for each data unit or chunk of a data unit, essentially combining the techniques described above with respect to the examples illustrated in FIGS. 2A and 2B. The scheduling epoch speeds of each data unit or data chunk may then be used to generalize the speed experience of the network application.

[0062] Specifically, FIG. 2C illustrates an example where a network application consumes two data units, a small data unit that fits within a single scheduling epoch and a large data unit that spans multiple scheduling epochs. The small data unit has a byte length of B_U1 and a transmission duration of T_U1 and the large data unit has a byte length of B_U2 and a transmission duration of T_U2. In this situation, the speed experience, S_x, is:

[0063] To generalize the speed experience to a situation where a network application consumes data units with sizes that vary from small data units that can be completely delivered in a single scheduling epoch to larger data units that require multiple scheduling epochs to be delivered, the speed experience, S_x, can be determined using the following:where EB LJJ is the byte length of the i-th data unit, T UJ is the transmission duration of the i-th data unit, T_E is the duration of a scheduling epoch, S_K_i is the chunk speed in the i-th scheduling epoch (B_K_i / T_E), and T_K_i is the transmission duration of a chunk in the i-th scheduling epoch.Passive Speed Measurements for a Service Flow Class

[0064] The speed experience measurements described with respect to FIGS. 2A-2C apply to a network application. It is desirable to measure the speed experience of a network application over a service flow in the communications network to better manage network capacity and to monitor the customer experience. Unfortunately, performing the above measurements for each service flow is computationally intensive and would require excessive overhead in a scheduler or gateway. Accordingly, disclosed herein are systems and methods that measure the speed experience of a class of service flows (or a service flow class). The results of these measurements can be used to represent the speed experience of individual service flows in the service flow class.

[0065] As used herein, a service flow is a layer 2 connection that provides transport of packets on an uplink or on a downlink. A service flow is characterized by a set of QoS parameters. QoS parameters can include, for example and without limitation, priority, minimum reserved transmission rate (MRTR), maximum sustained transmission rate (MSTR), parameters specifying requested resources (e.g., bandwidth, latency, etc.), parameters specifying a level of service to be provided, and the like. A service flow can be identified by one or more identifiers such as, for example and without limitation, a service flow identifier (SFID), a service data flow identifier (SDFID) which is a description of the service flow type (e.g., web service, video, etc.), a connection identifier (CID), a packet data flow identifier, a weight, etc. Service flows allow network service providers to offer different services and segregate traffic flows having different QoS requirements. A service flow may be pre-provisioned or can be dynamically created and deleted without service outage.

[0066] As used herein, a service flow class includes a plurality of service flows that are logically grouped together because of certain shared characteristics. For example, service flows with the same QoS configuration can be logically grouped together into a service flow class. A QoS configuration can include, forexample and without limitation, a scheduling priority, a minimum reserved transmission rate (MRTR), a maximum sustained transmission rate (MSTR), and / or the like. As another example, service flows with the same QoS configuration and scheduling weight can be logically grouped together into a service flow class. Scheduling weight can be used to weight the allocation of network resources for service flows in different service flow classes. For example, a service flow with a higher scheduling weight will typically be assigned more network resources, if required, than a service flow with a lower scheduling weight. A scheduling priority can be used to allocate network resources to a higher priority service flow before allocating network resources to a lower priority service flow. As another example, service flows with the same SFID, SDFID, and weight can be logically grouped together into a service flow class. In some implementations, service flows are grouped into service flow classes where each service flow in a service flow class shares the same 1 ) scheduling priority, MRTR, MSTR, and scheduling weight or (2) service data flow ID (SDFID), service flow ID (SFID), and scheduling weight. Other service flow classes may also be defined or created. In some implementations, the disclosed techniques are used in conjunction with protocols and standards that utilize MRTR and MSTR. The disclosed techniques may be used to soft guarantee a minimum reserved transmission rate (MRTR) of a service flow and to limit a transmission rate to the maximum sustained transmission rate (MSTR) of a service flow if that value is smaller than the carrier capacity (otherwise the transmission rate is limited to the carrier capacity).

[0067] More specifically, the speed experience concept developed for a network application consuming a mix of small and large data units is extended to measure the speed experience of a network application over a service flow by combining service flows into a service flow class and determining the speed experience of the service flow class. The determined speed experience of the service flow class is then used to represent the speed experience of each service flow in the service flow class. This advantageously reduces the overhead of schedulers and gateways by passively determining speed metrics for a class of service flows rather than for individual service flows. For individual service flow classes, speed metrics can be determined at regular intervals. In some implementations, the speed experience of one or more service flows can be determined using the techniques described herein. This can be done instead of orin addition to determining the speed experience of the service flow class to which a service flow belongs.

[0068] FIG. 3 illustrates an example of data units from a plurality of service flows being transferred over a plurality of scheduling epochs, the plurality of service flows logically grouped into a service flow class. To determine a speed experience for the service flow class, or the SFC speed experience, an imaginary service flow is constructed. To construct the imaginary service flow, the data unit or burst with the largest byte length is identified in each scheduling epoch. The maximum data unit byte length among the service flows of the service flow class in each scheduling epoch is considered to be the data unit byte length of the imaginary service flow of the service flow class for that scheduling epoch. For each scheduling epoch, this is the data unit byte length that is used to measure the SFC speed experience, as described herein with reference to FIG. 2C. Thus, the determined SFC speed experience represents a lower bound speed experience of a service flow within the service flow class. This is due at least in part to the SFC speed experience being calculated in each scheduling epoch based on the service flow with the largest or longest data burst (e.g., the data unit with the largest byte length in the scheduling epoch).

[0069] As described in greater detail herein, for each scheduling epoch, an SFC speed offer and an SFC speed experience can be computed using the imaginary network application of the service flow class. In addition, the SFC speed offer and the SFC speed experience can be averaged over a designated interval to derive an interval speed offer and an interval speed experience. These speed offer metrics and speed experience metrics can be used as indicators of the quality of experience of a user or customer. In addition, these speed offer metrics and speed experience metrics can be used as indicators of network congestion. The speed offer metrics and speed experience metrics relate to the amount of network resources allocated to a customer and relate to the customer’s speed experience with those allocated network resources.

[0070] To derive the SFC speed experience and SFC speed offer metrics, it is useful to define a quantity referred to as a scheduling quantum, F. The scheduling quantum, F, can be computed for each scheduling priority level of a service flow and / or service flow class and can be re-computed intermittently or periodically (e.g., every n scheduling epochs, where n is 2, 3, 4, 5, 6, etc.). Thescheduling quantum represents a fair share of resources to be allocated among the service flows or service flow classes with the same scheduling priority level. In some implementations, all service flows or service flow classes with the same scheduling priority can share the same scheduling quantum for each scheduling epoch. The scheduling quantum is equal to the byte share per unit weight for the given service flow (e.g., the SFC speed offer is equal to the scheduling quantum times the scheduling weight divided by the duration of the scheduling epoch). The scheduling quantum can be used to control the amount of network resources allocated among service flows to ensure that a desirable outcome is achieved (e.g., higher priority traffic gets more bandwidth, bandwidth is distributed in a targeted way, etc.). The scheduling quantum can be used in conjunction with the scheduling weight to allocate resources.

[0071] The scheduling quantum can be related to determining whether a service level objective or service level agreement has been satisfied. For example, the scheduling quantum can be used to determine the SFC speed offer for a service flow class and the SFC speed experience can be calculated to determine whether the service level agreement has been satisfied. For example, if a service flow is using less than a fair share of their bandwidth, which is related to the scheduling quantum, that service flow can be considered to have received network speed that satisfies the corresponding service level agreement. Stated in another way, speed experience is not necessarily related to the amount of data delivered in a scheduling epoch, which may appear to correspond to a network speed below an advertised speed for the corresponding customer. Rather, the speed experience advantageously takes into account the amount of data transferred and the portion of the scheduling epoch used to transfer that data.

[0072] Thus, where there are a number of active service flows in a scheduling epoch, a fair share of network resources can be divided based on the scheduling weight. Where there are a number of active service flows in a scheduling epoch that do not use their fair share of network resources, the excess network resources can be redistributed to other active service flows. The scheduling quantum thus represents a fair share of resources computed for a service flow with a weight of 1 . Belatedly, the product of the scheduling quantum and the scheduling weight, also referred to as the weighted fair share, or F weight, corresponds to the maximum data rate the scheduler will schedule if thecorresponding service flow has data to send, even if the amount of data requested to be sent in that epoch would require a data rate that exceeds that product. That is, the scheduler will only schedule up to F*weight amount of data in a scheduling epoch for a service flow.

[0073] By way of example, in each scheduling epoch, the product of the scheduling quantum, F, and the scheduling weight, SFC. weight, of the service flow class is computed. That result is compared to the maximum amount of data that can be transferred in the scheduling epoch (corresponding to the product of the maximum sustained transmission rate of the service flow class, SFC.MSTR, and the epoch duration, T_E), and the queue length of a service flow of the service flow class that has the longest queue in bytes when the scheduling epoch starts, SFC.queue. A minimum of these values is determined and added to the amount of data corresponding to a minimum reserved data amount (corresponding to the product of the minimum reserved transmission rate of the service flow class, SFC.MRTR, and the epoch duration, T_E). This represents the amount of data allocated to a service flow class:SFC. MRTR * TE+ min(F * SFC. weight, SFC. MSTR * TE,SFC. queue).

[0074] Thus, even if the network is not congested for this service flow class, e.g., there is sufficient bandwidth to deliver all of the data in the queue, the maximum amount of data that can be allocated is the amount corresponding to the promised MSTR. If the demand for bandwidth is less than MSTR, less bandwidth is allocated.

[0075] For an individual service flow class, the SFC speed offer (SFC.speedOffr) can be calculated as follows:where FJ corresponds to the scheduling quantum of the i-th scheduling epoch, SFC.weight corresponds to the scheduling weight of the service flow class, C corresponds to the carrier capacity, SFC.MSTR corresponds to the maximum sustained transmission rate of the service flow class, SFC.MRTR corresponds to the minimum reserved transmission rate of the service flow class, and T_E corresponds to the duration of the scheduling epoch. In some implementations, FJ is computed every n times the epoch length, where n is an integer greater than 2. For example, for an epoch length of 5 ms and for n equal to 4, the scheduler cancompute FJ every 20 ms. FJ can be computed considering the traffic load of every service flow of the carrier at the time. The frequency with which FJ is computed can be tailored to achieve a desired level of accuracy for the fair share computation considering the demand for the network resources balanced with the required overhead to compute FJ. The offered speed may or may not be fully utilized by the SFC based on its traffic load of the scheduling epoch.

[0076] Relatedly, for an individual service flow class, the SFC speed experience can be calculated in each scheduling epoch as follows, where SFC.queueJ denotes the queue length of a service flow of the service flow class that has the longest queue in bytes when the i-th scheduling epoch starts. In a first case, when at least one service flow in the service flow class has a number of bytes of data in the queue that is greater than or equal to FJ times SFC.weight in the scheduling i-th epoch, the service flow class experiences the following speed for this epoch and this scheduling epoch is SFC. priority congested (e.g., the scheduling epoch cannot transfer all data bytes in queue for the service flows with this particular scheduling priority). This situation is indicated by the epoch weight for the service flow class, SFC. epochWeight, being set to a value of 1 (where the epoch weight is the averaging weight of the epoch when multiple epochs are used to determine an average or interval speed experience):SFC. epochWeighti = 1

[0077] In a second case, when no service flow of a service flow class has more bytes of data in the queue than FJ times SFC.weight in the i-th scheduling epoch, the service flow class has a speed experience, SFC. epochSpeed, for a fraction of the epoch indicated by the epoch weight, SFC.epochWeight, and this scheduling epoch may or may not be SFC. priority congested:SFC. epochSpeedi = min(C, SFC. MSTR) SFC . epochWeighti = SFC . queuei / CTE')

[0078] In a third case, when no service flow of a service flow class has data in the i-th scheduling epoch (i.e., SFC.queueJ = 0), there is no speed measurement in this epoch and this scheduling epoch may or may not be SFC. priority congested:SFC . epochSpeedi = 0 SFC. epochWeighti = 0

[0079] In summary: if ( SFC. queue^ == 0)SFC. epochSpeedi — 0 SFC. epochWeighti = 0 else if ( SFC. queuei < FiSFC. weight) SFC. epochSpeedi=min(C, SFC. MSTR) SFC . epochWeighti = SFC. queuei / (CTEelseSFC. epochSpeedi( FiSFC. weight\= min C, SFC. MSTR, SFC. MRTR + - —V TEJSFC. epochWeighti=1

[0080] By way of explanation, a difference between an offered speed (e.g., SFC.speedOffr) and an experienced speed (e.g., SFC.epochSpeed) is that when there is congestion or high demand in a scheduling epoch, large data units are transferred that take up the whole epoch. This results in a speed experience that is the same as the speed offered - there is no more speed available because the whole epoch is taken. When there is low demand or little congestion in a scheduling epoch, small data units are transferred that only take up a fraction of the scheduling epoch, this results in a speed experience that approaches the maximum available to the SFC, the maximum being the smaller of the carrier capacity or the MSTR.Interval Speed Measurements for a Service Flow Class

[0081] It may be useful or advantageous to determine offered speeds and experienced speeds over a given interval. An interval speed metric corresponds to an average of the epoch speed metric (e.g., speed offer and speed experience) over a period of time spanning a plurality of scheduling epochs. This may help in determining an accurate speed experience because the interval speed offer and the interval speed experience smooth out variations that may appear over short time frames due to short periods of intense activity.

[0082] The interval speed offered for a service flow class for a given interval, SFC. intervalSpeedOffr, can be computed by averaging the speed offered for each epoch within the interval. This quantity is similar to what flooding-based active speed measurements (ASM) measure for a service plan, except that no extra traffic is introduced into the system.SFC. intervalSpeedOffr avg

[0083] The interval speed experienced by a service flow class for a given interval, SFC.intervalSpeedExp, can be computed from the scheduling epoch speed records of the service flow class. For example, the interval speed experience can be determined by computing a weighted average of all epoch speeds of the interval:

[0084] The interval over which the averages are computed for the offered and experienced speeds can depend on the characteristics of the network communications system in which the disclosed technologies are implemented. For example, the interval can be related to a number of scheduling epochs (e.g., 5, 10, 20, 50, etc.). As another example, the interval can be related to a latency in the network communications system (e.g., where round trip times are about 600 ms, the interval can be about 5 seconds). The interval and epoch speed experiences disclosed herein advantageously help to express the congestion experience of a customer in a bursty system. In some implementations, it is advantageous to compare speed experiences to determine or estimate network congestion.Example Methods for Passively Measuring Network Speeds

[0085] FIG. 4 illustrates a flow chart of an example method 400 for passively measuring a speed metric for a service flow class. The method 400 can be performed in any of the schedulers or other component of a communications system described herein with reference to FIGS. 1 A, 1 B, and 7. For ease of description, the method 400 will be described as being performed by a scheduler. This is not to be understood to limit the scope of the disclosure. Rather, any step or portion of the method 400 can be performed by any component or combination of components of the communications systems described herein.

[0086] In block 405, the scheduler determines a service flow class that includes one or more service flows. As described herein, a service flow class includes one or more service flows with shared characteristics. The shared characteristics can include QoS parameters such as priority, maximum sustained transmission rate, and minimum reserved transmission rate. The shared characteristics can also include a scheduling weight. The shared characteristics can include shared identification numbers, such as a service data flow ID and / or a packet data flow ID. The shared characteristics can also include a combination of a scheduling weight, service flow ID, and service data flow ID at the scheduler or gateway.

[0087] In block 410, the scheduler determines, for each of a plurality of scheduling epochs, a maximum burst byte length among the one or more service flows of the service flow class; a service flow class epoch speed, or SFC epoch speed, based at least in part on the maximum burst byte length; and a service flow class epoch weight, or SFC epoch weight, based at least in part on the maximum burst byte length. Each of these values has been described in greater detail herein.

[0088] In block 415, the scheduler calculates an interval speed experience for the service flow class. The interval speed experience is a weighted average of a plurality of SFC epoch speeds using a corresponding plurality of SFC epoch weights. Calculation of the interval speed experience has been described in greater detail herein.

[0089] FIG. 5 illustrates a flow chart of an example method 500 for determining a service flow class epoch speed. The method 500 can be performed in any of the schedulers or other component of a communications system described herein with reference to FIGS. 1A, 1 B, and 7. For ease of description, the method 500 will be described as being performed by a scheduler. This is not to be understood to limit the scope of the disclosure. Rather, any step or portion of the method 500 can be performed by any component or combination of components of the communications systems described herein.

[0090] In block 501 , the scheduler receives a carrier capacity, C, of the communications network in which the scheduler operates. In block 502, the scheduler computes or receives a maximum sustained transmission rate (MSTR) for the service flow class, SFC_MSTR. In block 503, the scheduler computes or receives a minimum reserved transmission rate (MRTR) for the service flow class,SFC_MRTR. In block 504, the scheduler computes or receives a scheduling weight of the service flow class, SFC. weight. In block 505, the scheduler computes or receives a scheduling quantum, F, corresponding to a fair share of transmission capacity for a service flow within the service flow class. In some implementations, the scheduler computes a weighted fair share, F weight, corresponding to a product of the scheduling quantum, F, and the scheduling weight of the service flow class, SFC.weight. In block 506, the scheduler computes or receives an epoch duration, T_E.

[0091] In block 510, the scheduler determines an epoch speed offer for each of the plurality of scheduling epochs. The epoch speed offer for each scheduling epoch is set equal to a smallest value between C, SFC_MSTR, and (SFC_MRTR + F_weight / T_E), as described in greater detail herein. In block 515, the scheduler determines a maximum burst byte length, SFC. queue, for the service flow class for each scheduling epoch.

[0092] In block 520, the scheduler determines an SFC epoch speed experience and SFC epoch weight by performing the processes in blocks 525, 530, 535, 540, and / or 545. In block 525, the scheduler determines if the maximum burst byte length, SFC. queue, is smaller than the weighted fair share. Responsive to determining that SFC. queue < F weight, the scheduler sets the SFC epoch speed to a smallest value between C and SFC.MSTR in block 530 and the scheduler sets the SFC epoch weight to SFC.queue / (C*T_E) in block 535. Responsive to determining that SFC. queue > F weight, the scheduler sets the SFC epoch speed to the smallest value between C, SFC.MSTR, and (SFC.MRTR + F*SFC.weight / T_E) in block 540 and the scheduler sets the SFC epoch weight to 1 in block 545. Each of these calculations is described in greater detail herein.

[0093] In some implementations, a priority of the service flow class is designated as congested responsive to the maximum burst byte length being greater than or equal to the weighted fair share.

[0094] FIG. 6 illustrates a flow chart of an example method 600 for determining congestion in a communications network. The method 600 can be performed in any of the schedulers or other component of a communications system described herein with reference to FIGS. 1 A, 1 B, and 7. For ease of description, the method 600 will be described as being performed by a scheduler. This is not to be understood to limit the scope of the disclosure. Rather, any stepor portion of the method 600 can be performed by any component or combination of components of the communications systems described herein.

[0095] In addition to computing or receiving the values indicated in blocks 501 to 506, described herein with reference to FIG. 5, the scheduler computes or receives an epoch speed in block 607 and an epoch weight in block 608.

[0096] In block 610, the scheduler determines an interval speed offer for the service flow class by computing an average of the determined epoch speed offers over an interval. The interval includes a plurality of scheduling epochs. In some implementations, the interval includes at least 5 scheduling epochs. The plurality of determined epoch speed offers are determined using the method 500, described herein with reference to FIG. 5 (e.g., see block 510).

[0097] In block 615, the scheduler determines an interval speed experience for the service flow class by computing a weighted average of the determined epoch speed experiences over the same interval indicated in block 610. The plurality of determined epoch speed offers are determined using the method 500, described herein with reference to FIG. 5 (e.g., see blocks 520-545).

[0098] In block 620, the scheduler determines a service-level congestion index. The service-level congestion index is defined as the interval speed experience determined in block 615 divided by a target speed of the service flow class. The target speed can be the speed advertised by an ISP to a customer, as part of a service plan or service level agreement, for example.Examples of Offered and Experienced Network Speeds for a Service Flow Class

[0099] Presented below are example tables illustrating calculations of offered and experienced speeds for individual scheduling epochs and averaged over an interval of 5 scheduling epochs. In the tables, the capacity of the satellite carrier, C, is 100 Mbps, the quanta for each scheduling epoch, F, is 0.5, SFC.MRTR = 0, SFC.MSTR > 100 Mbps, SFC.weight = 1 , T E is 0.02 seconds. This means that the interval speed offer is 25 Mbps (because the minimum of C, SFC.MSTR and SFC.MRTR+(F_i SFC.weight) / T_E) is 0.5*1 / 0.02 which equals 25). Note that the offered interval speed is fixed when the above parameters are fixed. In contrast, the experienced interval speed changes with changes to the experienced epoch speed and the epoch weight.

[0100] Example Table 1 shows that the epoch speed and the interval speed of a high-demanding service flow class in a congested carrier has more demand than per-flow share of the bandwidth for all 5 epochs. This is reflected by the epoch weight being 1 for each scheduling epoch. Example Table 4 shows that the epoch speed and the interval speed of a light-demanding service flow class has a demand that is less than a per-flow share in all 5 epochs. This is reflected by the epoch weight being less than 1 for each scheduling epoch. The Example Tables illustrate that the interval speed experience of a service flow class approaches the offered speed as the number of the demanding epochs increases (e.g., as the number of epoch weights with a value of 1 increases), and to the minimum of the carrier capacity (C) and the maximum sustained transmission rate (SFC.MSTR) as the number of the demanding epochs decreases (e.g., as the number of epoch weights with a value less than 1 increases).

[0101] For each table, the above parameters are provided as input along with the maximum burst byte length of the SFC in each epoch, labeled SFC. queue. Using these values as input, the speed experience for the SFC in each epoch is calculated as described herein with reference to FIG. 3, labeled SFC. epochSpeed, the weight for the SFC in each scheduling epoch is calculated as described herein with reference to FIG. 3, labeled SFC. Weight, and the interval speed experience for the SFC is calculated as described herein, labeled SFC.IntervalSpeedExp, using all five scheduling epochs as the interval and the epoch weights (SFC. epochWeight) as the weights used in the weighted average.

[0102] The average interval speed offered for SFC can be considered to replace ASM speed samples for service plans using the SFC. An alternative option is to use SFC speed experience of a desired measurement interval when most of the scheduling epochs are congested for the SFC. The top left table in the previous section shows that the experienced speed converges to the offered speed as most of the scheduling epochs of the interval is becoming congested for the SFC.

[0103] Because the SFC speed experience may vary from scheduling epoch to scheduling epoch, it may be desirable to also determine an interval speed experience that corresponds to a rolling average of the SFC speed experience taken over a plurality of scheduling epochs. The average SFC speed offered by the system for a desired measurement interval (e.g., about 5 seconds) can be used to replace or augment an active speed measurement of a service plan using the SFC for the interval. Flooding-based active speed measurement methods tries to infer / estimate the speed offered for a service plan for a given evaluation interval by measuring throughput of a test service flow over which data is flooded. However, ASM cannot accurately measure the average speed offered for the service plansince it changes the system state (i.e., the quanta Fi) due to the additional test traffic. The average interval speed offered for SFC can be considered to replace ASM speed samples for service plans using the SFC. An alternative option is to use SFC speed experience of a desired measurement interval when most of the scheduling epochs are congested for the SFC. The top left table in the previous section shows that the experienced speed converges to the offered speed as most of the scheduling epochs of the interval is becoming congested for the SFC.Determining Network Congestion Using Passive Speed Measurements

[0104] As described with respect to FIG. 6, the interval speed experience can be used to determine an index indicative of congestion in the communications network. This index can be used to manage network capacity, for example. Example Table 5 uses the results from Example Tables 1 -4 to derive an example service-level congestion index where the service flow class has a target speed of 50 Mbps. In some implementations, the SFC speed experience measured for a desired measurement interval (e.g., 5 seconds) can be used as a service-level congestion index when normalize by the target speed of the plan using the service flow class.

[0105] The disclosed techniques for passively measuring speed for a network application of a service flow can be used as a tool to understand congestion levels of each service flow. In addition, these congestion levels can be based on experienced speeds over a particular interval. For example, a service flow with a high priority and a high weight has little or no congestion whereas a service flow with lower priority and lower weight has at least some congestion, so that the levels of congestion differ among service flows. If there are two service flows splitting 100 Mbps between them (e.g., 50 Mbps each), there is some congestion, but it is not the same as 100 service flows splitting that same 100 Mbps. Accordingly, the disclosed passive speed measurements may be used to estimate, approximate, and / or quantify congestion levels for service flows. Asdescribed herein, service flow classes can be used to determine congestion in the network, which can then be used to manage network capacity. Thus, the disclosed speed measurements for service flow classes can be understood as a way to quantify congestion. In some implementations, the disclosed passive speed measurements do not measure end-to-end network speed, rather the measurements determine network speed provided by a communications system or a portion of a communications network. For example, an internet service provider can use the disclosed techniques to determine the network speed over the portion of the network that the ISP controls or provides. For certain ISPs, such as providers that use one or more satellite links, it may be particularly beneficial to quantify or understand the resource that is in contention (e.g., the satellite link) and the service impact on the shared resource (e.g., the satellite link).

[0106] By way of example, if an advertised speed is 50 Mbps and a client device uses 1 Mbps, the communications system can be said to have successfully satisfied the advertised speed because the client device is not using what is available. This is due to the congestion level being such that the client device cannot tell the difference. Thus, the service provider can claim to have met the service level agreement with the client device. However, if the advertised speed (or service level agreement) is 1 Mbps and the client device requires 1 .2 Mbps, an instantaneous measurement of speed experience may indicate that the service level agreement has not been satisfied. The disclosed speed measurement techniques can be useful in such situations because the interval speed experience can be used to do a weighted average of the speed experience over an interval (e.g., about 5 seconds, about 10 seconds, etc.) which may be less than or equal to the advertised 1 Mbps. Thus, the service provider can claim to have met the service level agreement with the client device based on the interval speed experience of the client device. The interval can be long enough to account for any temporary spikes in network traffic while being short enough for a client to feel that the advertised speed is being provided.Example Component of a Communications System

[0107] FIG. 7 illustrates a block diagram of a subsystem 770 of a communications system, such as a scheduler or gateway, examples of which are described herein with reference to FIGS. 1 A and 1 B. The subsystem 770 isconfigured to manage network capacity and network resource allocation based at least in part on speed metrics determined as described herein. The subsystem 770 can employ any method described herein for passively measuring network speeds and managing network communication, such as the example methods 400, 500, and 600 described herein with reference to FIGS. 4, 5, and 6, respectively.

[0108] The subsystem 770 can include hardware, software, and / or firmware components for managing resource grant allocations. The subsystem 770 includes a data store 771 , one or more processors 773, one or more network interfaces 775, a service flow module 772, and an epoch module 774, an interval module 776, and a congestion module 778. Components of the subsystem 770 can communicate with one another, with external systems, and with other components of a network using communication bus 779. The subsystem 770 can be implemented using one or more computing devices. For example, the subsystem 770 can be implemented using a single computing device, multiple computing devices, a distributed computing environment, or it can be located in a virtual device residing in a public or private computing cloud. In a distributed computing environment, one or more computing devices can be configured to provide the modules 772, 774, 776, 778 to provide the described functionality.

[0109] The subsystem 770 includes the service flow module 772 to determine service flow classes by grouping service flows with shared characteristics, as described herein. The subsystem 770 includes the epoch module 774 to determine offered speeds and experienced speeds for a scheduling epoch, as described herein. The subsystem 770 includes the interval module 776 to determine offered speeds and experienced speeds for an interval spanning multiple scheduling epochs, as described herein. The subsystem 770 includes the congestion module 778 to determine a congestion level based on determined speed metrics, as described herein.

[0110] In some implementations, the speed metrics and congestion metrics disclosed herein can be calculated by a first component of a communications system, such as a scheduler, and exported to other components of the communications system, such as a gateway of quality-of-service monitor. In some implementations, scheduling parameters can be exported by a first component of a communications system, such as a scheduler, and exported to other components of the communications system to determined the disclosedspeed and congestion metrics. For example, it may be advantageous to export the size of the data units, SFC. queue, and the scheduling quantum, F, of each scheduling epoch. This would allow other components, systems, or applications to compute the speed metrics as needed.

[0111] In some implementations, a list of service flow classes to collect scheduling epoch speeds can be configured at the subsystem 770. In some implementations, the list can support about 100 service flow classes. As described herein, one option to determine a service flow class is based on priority, MRTR, MSTR, and scheduling weight of service flows at the subsystem 770. As described herein, another option to determine a service flow class is based on Service Data Flow ID (SDF ID), Packet Data Flow ID (PDF ID), and weight triplet of service flows at the subsystem 770. This option may incur a configuration overhead as service flows with different SDF ID and PDF ID pairs may have the same priority, MRTR and MSTR. For example, each service plan may have its own SDF ID and PDF ID pair for web service flows even when they have the same priority, MRTR and MSTR configurations. However, it may be advantageous to determine service flows using SDF ID and PDF ID pair mapping because these values may not change for the lifetime of the service plan while priority, MSTR and MRTR configuration of the pair may change during the lifetime of the service plan.

[0112] The subsystem 770 includes one or more processors 773 that are configured to control operation of the modules 772, 774, 776, 778 and the data store 771 . The one or more processors 773 implement and utilize the software modules, hardware components, and / or firmware elements configured to schedule and randomize resource grant allocations. The one or more processors 773 can include any suitable computer processors, application-specific integrated circuits (ASICs), field programmable gate array (FPGAs), or other suitable microprocessors. The one or more processors 773 can include other computing components configured to interface with the various modules and data stores of the subsystem 770.

[0113] The subsystem 770 includes the data store 771 configured to store configuration data, user requirements, network statuses, network characteristics and capabilities, control commands, databases, algorithms, executable instructions (e.g., instructions for the one or more processors 773), and the like. The data store 771 can be any suitable data storage device or combinationof devices that include, for example and without limitation, random access memory, read-only memory, solid-state disks, hard drives, flash drives, bubble memory, and the like. The data store 771 can be a non-transitory computer-readable medium. The data store 771 can store processor-executable instructions to implement one or more of the modules 772, 774, 776, 778 and / or the methods 400, 500, and 600.Additional Embodiments and Terminology

[0114] The present disclosure describes various features, no single one of which is solely responsible for the benefits described herein. It will be understood that various features described herein may be combined, modified, or omitted, as would be apparent to one of ordinary skill. Other combinations and subcombinations than those specifically described herein will be apparent to one of ordinary skill, and are intended to form a part of this disclosure. Various methods are described herein in connection with various flowchart steps and / or phases. It will be understood that in many cases, certain steps and / or phases may be combined together such that multiple steps and / or phases shown in the flowcharts can be performed as a single step and / or phase. Also, certain steps and / or phases can be broken into additional sub-components to be performed separately. In some instances, the order of the steps and / or phases can be rearranged and certain steps and / or phases may be omitted entirely. Also, the methods described herein are to be understood to be open-ended, such that additional steps and / or phases to those shown and described herein can also be performed.

[0115] Some aspects of the systems and methods described herein can advantageously be implemented using, for example, computer software, hardware, firmware, or any combination of computer software, hardware, and firmware. Computer software can comprise computer executable code stored in a computer readable medium (e.g., non-transitory computer readable medium) that, when executed, performs the functions described herein. In some embodiments, computer-executable code is executed by one or more general purpose computer processors. A skilled artisan will appreciate, in light of this disclosure, that any feature or function that can be implemented using software to be executed on a general purpose computer can also be implemented using a different combination of hardware, software, or firmware. For example, such a module can be implemented completely in hardware using a combination of integrated circuits.Alternatively or additionally, such a feature or function can be implemented completely or partially using specialized computers designed to perform the particular functions described herein rather than by general purpose computers.

[0116] Multiple distributed computing devices can be substituted for any one computing device described herein. In such distributed embodiments, the functions of the one computing device are distributed (e.g., over a network) such that some functions are performed on each of the distributed computing devices.

[0117] Some embodiments may be described with reference to equations, algorithms, and / or flowchart illustrations. These methods may be implemented using computer program instructions executable on one or more computers. These methods may also be implemented as computer program products either separately, or as a component of an apparatus or system. In this regard, each equation, algorithm, block, or step of a flowchart, and combinations thereof, may be implemented by hardware, firmware, and / or software including one or more computer program instructions embodied in computer-readable program code logic. As will be appreciated, any such computer program instructions may be loaded onto one or more computers, including without limitation a general purpose computer or special purpose computer, or other programmable processing apparatus to produce a machine, such that the computer program instructions which execute on the computer(s) or other programmable processing device(s) implement the functions specified in the equations, algorithms, and / or flowcharts. It will also be understood that each equation, algorithm, and / or block in flowchart illustrations, and combinations thereof, may be implemented by special purpose hardware-based computer systems which perform the specified functions or steps, or combinations of special purpose hardware and computer-readable program code logic means.

[0118] Furthermore, computer program instructions, such as embodied in computer-readable program code logic, may also be stored in a computer readable memory (e.g., a non-transitory computer readable medium) that can direct one or more computers or other programmable processing devices to function in a particular manner, such that the instructions stored in the computer- readable memory implement the function(s) specified in the block(s) of the flowchart(s). The computer program instructions may also be loaded onto one or more computers or other programmable computing devices to cause a series ofoperational steps to be performed on the one or more computers or other programmable computing devices to produce a computer-implemented process such that the instructions which execute on the computer or other programmable processing apparatus provide steps for implementing the functions specified in the equation(s), algorithm(s), and / or block(s) of the flowchart(s).

[0119] Some or all of the methods and tasks described herein may be performed and fully automated by a computer system. The computer system may, in some cases, include multiple distinct computers or computing devices (e.g., physical servers, workstations, storage arrays, etc.) that communicate and interoperate over a network to perform the described functions. Each such computing device typically includes a processor (or multiple processors) that executes program instructions or modules stored in a memory or other non- transitory computer-readable storage medium or device. The various functions disclosed herein may be embodied in such program instructions, although some or all of the disclosed functions may alternatively be implemented in applicationspecific circuitry (e.g., ASICs or FPGAs) of the computer system. Where the computer system includes multiple computing devices, these devices may, but need not, be co-located. The results of the disclosed methods and tasks may be persistently stored by transforming physical storage devices, such as solid state memory chips and / or magnetic disks, into a different state.

[0120] Unless the context clearly requires otherwise, throughout the description and the claims, the words “comprise,” “comprising,” and the like are to be construed in an inclusive sense, as opposed to an exclusive or exhaustive sense; that is to say, in the sense of “including, but not limited to.” The word “coupled”, as generally used herein, refers to two or more elements that may be either directly connected, or connected by way of one or more intermediate elements. Additionally, the words “herein,” “above,” “below,” and words of similar import, when used in this application, shall refer to this application as a whole and not to any particular portions of this application. Where the context permits, words in the above Detailed Description using the singular or plural number may also include the plural or singular number respectively. The word “or” in reference to a list of two or more items, that word covers all of the following interpretations of the word: any of the items in the list, all of the items in the list, and any combination of the items in the list. The word “exemplary” is used exclusively herein to mean“serving as an example, instance, or illustration.” Any implementation described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other implementations.

[0121] The disclosure is not intended to be limited to the implementations shown herein. Various modifications to the implementations described in this disclosure may be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other implementations without departing from the spirit or scope of this disclosure. The teachings of the invention provided herein can be applied to other methods and systems, and are not limited to the methods and systems described above, and elements and acts of the various embodiments described above can be combined to provide further embodiments. Accordingly, the novel methods and systems described herein may be embodied in a variety of other forms; furthermore, various omissions, substitutions and changes in the form of the methods and systems described herein may be made without departing from the spirit of the disclosure. The accompanying claims and their equivalents are intended to cover such forms or modifications as would fall within the scope and spirit of the disclosure.

Claims

WHAT IS CLAIMED IS:1 . A method for passively measuring a speed metric for a service flow class, the method comprising: determining by a component of a communications system a service flow class that includes one or more service flows; for each of a plurality of scheduling epochs, determining: a maximum burst byte length among the one or more service flows of the service flow class; a service flow class epoch speed, or SFC epoch speed, based at least in part on the maximum burst byte length; and a service flow class epoch weight, or SFC epoch weight, based at least in part on the maximum burst byte length; and calculating an interval speed experience for the service flow class, the interval speed experience corresponding to a network speed experienced by a service flow in the communications system, the interval speed experience being a weighted average of a plurality of SFC epoch speeds using a corresponding plurality of SFC epoch weights.

2. The method of claim 1 further comprising: computing a scheduling quantum, F, corresponding to a share of transmission capacity for a service flow within the service flow class; and a weighted fair share, F weight, corresponding to a product of the scheduling quantum and a scheduling weight of the service flow class.

3. The method of claim 2 further comprising calculating an interval speed offer for the service flow class, the interval speed offer corresponding to a network speed offered by a communications network, the interval speed offer calculated by: determining an epoch speed offer for each of the plurality of scheduling epochs, the epoch speed offer for each scheduling epoch being set equal to a smallest value between C, SFC_MSTR, and (SFC_MRTR + F_weight / T_E), where C is a carrier capacity of the communications system, SFC_MSTR is a maximum sustained transmission rate (MSTR) for the service flow class, SFC_MRTR is a minimum reserved transmission rate(MRTR) for the service flow class, and T_E is a duration of the scheduling epoch; and computing an average of the plurality of determined epoch speed offers.

4. The method of claim 3, wherein each SFC epoch speed is equal to: a smallest value between C and SFC_MSTR responsive to the maximum burst byte length being less than F weight; and a smallest value between C, SFC_MSTR, and (SFC_MRTR + F_weight / T_E) responsive to the maximum burst byte length being greater than or equal to F weight.

5. The method of claim 4, wherein each SFC epoch weight is equal to: the maximum burst byte length divided by C * T_E responsive to the maximum burst byte length being less than F weight; and a value of one responsive to the maximum burst byte length being greater than or equal to F weight.

6. The method of claim 5, wherein a priority of the service flow class is designated as congested responsive to the maximum burst byte length being greater than or equal to the weighted fair share.

7. The method of any one of claims 3-6, wherein the interval speed experience approaches the interval speed offer responsive to an increase in a number of SFC epoch weights of the plurality of SFC epoch weights with a value of one.

8. The method of claim 7, wherein the interval speed experience approaches the carrier capacity responsive to a decrease in the number of SFC epoch weights of the plurality of SFC epoch weights with a value of one.

9. The method of any one of claims 7 and 8, wherein the interval speed experience approaches the SFC_MSTR responsive to a decrease in the number of SFC epoch weights of the plurality of SFC epoch weights with a value of one.

10. The method of any one of claims 3-9, wherein the interval speed offer is determined without introducing additional network traffic into the communications system.1 1 . The method of any one of claims 1 -10, wherein each service flow in the service flow class has a same quality of service configuration and scheduling weight.

12. The method of any one of claims 1 -10, wherein each service flow in the service flow class has a same priority, minimum reserved transmission rate, maximum sustained transmission rate, and scheduling weight.

13. The method of any one of claims 1 -10, wherein each service flow in the service flow class has a same service data flow ID, packet data flow ID, and weight triplet.

14. The method of any one of claims 1 -10, wherein calculating the interval speed experience is performed by the component of the communications system.

15. The method of any one of claims 1 -10 further comprising determining a service-level congestion index comprising the interval speed experience for the service flow class normalized by a target speed for the service flow class.

16. The method of any one of claims 1 -10 further comprising, for each scheduling epoch, transmitting to a quality of service monitoring system the maximum burst byte length and a scheduling quantum, F, corresponding to a share of transmission capacity for a service flow within the service flow class.

17. The method of claim 16, wherein calculating the interval speed experience is performed by the quality of service monitoring system.

18. A scheduler for a communications system that transmits data between a plurality of client devices and a network, the scheduler comprising: a network interface for communicating with the plurality of client devices and the network;a non-transitory computer-readable medium storing processorexecutable instructions; and a processor communicatively coupled to the network interface and the non-transitory computer-readable medium, the processor-executable instructions configured to cause the processor to: determine a service flow class that includes one or more service flows; for each of a plurality of scheduling epochs, determine a maximum burst byte length among the one or more service flows of the service flow class, a service flow class epoch speed, or SFC epoch speed, based at least in part on the maximum burst byte length, and a service flow class epoch weight, or SFC epoch weight, based at least in part on the maximum burst byte length; and calculate an interval speed experience for the service flow class, the interval speed experience being a weighted average of a plurality of SFC epoch speeds using a corresponding plurality of SFC epoch weights.

19. A communications system configured to transmits data between a plurality of client devices and an external network, the communications system comprising: an access network that communicates data between the external network and the plurality of client devices; a gateway communicatively coupled to the access network and to the external network, the gateway configured to manage data transmissions to and from the plurality of client devices and to manage data transmissions to and from the external network; and a scheduler communicatively coupled to the gateway, the scheduler configured to: determine a service flow class that includes one or more service flows; for each of a plurality of scheduling epochs, determine a maximum burst byte length among the one or more service flows of the service flow class, a service flow class epoch speed, or SFC epoch speed, based atleast in part on the maximum burst byte length, and a service flow class epoch weight, or SFC epoch weight, based at least in part on the maximum burst byte length; and calculate an interval speed experience for the service flow class, the interval speed experience being a weighted average of a plurality of SFC epoch speeds using a corresponding plurality of SFC epoch weights.

20. The communications system of claim 19, wherein the access network comprises one or more satellites.

Images