Software Guide

Advanced Configuration
Tsunami
®
800 & 8000 Series - Software Management Guide 133
It is important to note that for each SFC with CIR > 0, there are effectively two absolute traffic priorities alloted (total 16
priorities for the 8 SFC entries). The higher priority is used as long as the throughput of the traffic being sent through SFC is
below or equal to the CIR, and the lower priority is used for the rest of the traffic, taking MIR configuration as the second
priority. This switching of the priorities is done automatically by the scheduler, which makes sure that lower priority traffic gets
transported only after all the higher priorities are transported successfully.
The device tries to deliver the packets within the specified latency and jitter requirements, relative to the moment of receiving
the packets in the device. For all types of traffic, the device will try to keep the jitter within the range 0 to configured Jitter
value in milliseconds(ms). In order to allow the device maintain the traffic within the configured jitter range, each packet is
buffered until a time interval equal to the difference between Latency and jitter (Latency Jitter) has elapsed. When this
interval elapses, the receiving device will deliver the packet. The delay of the packets is kept in the range (Latency Jitter) to
configured Latency value in millisecond(ms), that in turn maintains the jitter within the range 0 to configured Jitter value in
milliseconds(ms).
However, possible retransmissions can increase maximum delay of the packet beyond Latency milliseconds, which can result
in increased jitter as well. If the SFC’s scheduling type is real-time polling (RtPS) and the packet is not delivered out from the
transmitting unit within the time period equal to the Latency milliseconds, then the packet will be discarded on transmitting
device. This can lead to loss of packets without reaching the maximum throughput of the wireless link. For example, when
the packets arrive in bursts on the Ethernet interface and the wireless interface is momentarily maxed out, then the packets at
the “end” of the burst may be timed out before they can be sent. Therefore RtPS type of polling must be used only if it is
absolutely necessary.
Users can set up their own traffic characteristics (MIR, CIR, latency, jitter, etc.) per service flow class to meet their unique
requirements. A good example is provided by the 8 predefined SFCs:
1. UL-Unlimited BE
a. Scheduling Type = Best Effort
b. Service Flow Direction = Uplink
c. Entry Status = Enable
d. Maximum Sustained Data Rate = 102400 Mbps
e. Traffic Priority = 0
2. DL-Unlimited BE (same as UL-Unlimited BE, except Service Flow Direction = Downlink)
3. DL-L2 Broadcast BE (same as UL-Unlimited BE, except Service Flow Direction = Downlink)
4. UL-G711 20 ms VoIP RTPS
a. Schedule type = RTPS (Real time Polling Service)
b. Service Flow Direction = Uplink
c. Entry Status = Enable
d. Maximum Sustained Data Rate = 88 Kbps
e. Minimum Reserved Traffic Rate = 88 Kbps
f. Maximum Latency = 20 milliseconds
g. Traffic Priority = 1
5. DL-G711 20 ms VoIP rtPS (same as UL-G711 20ms VoIP rtPS, except Service Flow Direction = Downlink)
6. UL-G729 20 ms VoIP rtPS (same as UL-G711 20ms VoIP rtPS, except Maximum Sustained Data Rate and Committed
Information rate = 66 Kbps)
7. DL-G729 20 ms VoIP rtPS (same as UL-G729 20ms VoIP rtPS, except Service Flow Direction = Downlink)
8. DL-2Mbps Video
a. Schedule type = Real time Polling
b. Service Flow Direction = Downlink
c. Initialization State = Active
d. Maximum Sustained Data Rate = 2 Mbps