So, weil das Thema immer mal wieder aufkommt, aber meist eher off-topic ist, hier ein Thread um dieses Thema ausfuehrlich diskutieren zu koennen.
Hier mal ein Link zu einem Paper das ein Modell fuer die Kapazitaetsdimensionierung vorschlaegt:
https://account.scte.org/documents/5836/FTF22_WLINE06_Ulm_3748.pdf
The “Basic” formula shown below is a simple two-term equation. The first term (Nsub*Tavg) allocates
bandwidth capacity to ensure that the aggregate average bandwidth consumption generated by the number
of subscribers (Nsub) can be adequately carried by the service group’s bandwidth capacity. The first term
is viewed as the “Direct Current (DC) component” of traffic that tends to exist as a continuous flow of
traffic during the peak busy period. The growth rate of Tavg has seen much research.
“COMMSCOPE/CLOONAN’S CAPACITY EQUATION” Traffic Engineering Formula:
C ≥ (Nsub * Tavg) + (K * Tmax_max) (1)
where:
C is the required bandwidth capacity for the service group
Nsub is the total number of subscribers within the service group
Tavg is the average bandwidth consumed by a subscriber during the busy period
K is the QoE constant (larger values of K yield higher QoE levels)…
where 0 ≤ K ≤ infinity, but typically 1.0 ≤ K ≤ 1.2
Tmax_max is the highest Service Tier (i.e., Tmax) offered by the MSO
Figure 1 shows there are obviously fluctuations that occur (i.e., the “alternating current (AC) component”
of traffic) which can force the instantaneous traffic levels to both fall below and rise above the DC traffic
level. The second term (K*Tmax_max) is added to increase the probability that all subscribers experience
good QoE levels for most of the fluctuations that go above the DC traffic level.
The second term in the formula (K*Tmax_max) has an adjustable parameter defined by the K value. This
parameter allows MSOs to increase the K value and add bandwidth capacity headroom that provides
better QoE to their subscribers within a service group. In addition, the entire second term is scaled to be
proportional to the Tmax_
max value, which is the maximum service tier being offered to subscribers.
In previous papers [CLOONAN_2013, CLOONAN_2014, EMM_2014], found that a K value between
1.0 to 1.2 provides good QoE results for a 250 subscriber SG. Larger SGs need even larger values of K
while very small SGs might use a K value ≤1.0.
2.2. The “Modified” Traffic Engineering Formula
Over time, it was discovered that the optimum K value varies based on all the inputs: Nsub, Tavg and
Tmax_max. [ULM_2017] noted some of these limitations along with some refinements to the basic
formula above. This resulted in the following which is still algebraically equivalent to the basic formula:
Modified “COMMSCOPE/CLOONAN’S CAPACITY EQUATION” Traffic Eng Formula:
C ≥ (Nsub * Tavg) + (K-1) * Tmax_max + Tmax_max (2)
The subtle change is that there are now three main components to the traffic engineering formula:
1. Peak Busy Period Average Consumption (i.e., Nsub * Tavg)
2. Peak Busy Period Ripple for managing QoE (i.e. (K-1) * Tmax_max)
3. Headroom for maximum Service Tier Burst (i.e., 1 * Tmax_max)
D.h. sowohl der mittlere Durchsatz in der Primetime als auch die Varianz dieses "Grundumsatzes" (Ripple) als auch die maximale Vertragsrate spielen da eine Rolle.
Ein mir bekannter (W)ISP arbeitet susaetzlich mit der gleichzeitigkeitsannahme, dass etwa jeder 25-50 Nutzer versucht die Kapazitaet voll zu nutzen, was zu folgenden Formeln fuehrt:
C ≥ (Nsub * Tavg) + (K-1) * Tmax_max + (ceil(Nsub/25)) * Tmax_max (3)
C ≥ (Nsub * Tavg) + (K-1) * Tmax_max + (ceil(Nsub/50)) * Tmax_max (4)
der WISP peilt 25 an, erlaubt sich selber Overbooking bis 50 bevor er garantiert di Kapazitaet erweitert (oder Kunden auf andere Segmente legt). (sein K liegt bei 1.0, d.h. er kuemmert sich nicht gross um Ripple, weil der ceil(Nsub/50) Faktor das quasi mit einschliesst).
Bei typischen PON Segmenten im Bereich 16-64 muesste man 1-2 mal die maximale Vertragsrate Reserve haben... (zusaetzlich zur mittleren Auslastung und dem Ripple). Und das im Zugangsnetz, aber anteilig auch im Backbone...
