, even with active QoS measurements, for example when there are multiple flows over the same Internet access, they all share the available bandwidth (i.e. bitrates) in the downlink and uplink respectively. So, to have accurate results (e.g. for fixed broadband access) the link should be idle at the time when the installed probe generate test packets toward the servers (of the measurement platform). For example, if the user has 100 Mbit/s of bandwidth (i.e. link capacity) in downlink, and concurrently downloads 10 files with HTTP or FTP over the given Internet access link (with file sizes large enough to exists concurrently for period of several tens of seconds), then each TCP connection (i.e. each HTTP or FTP connection) will have less than 1/10th of the downlink bandwidth, i.e. less than 10 Mbit/s in this concrete example. That is due to the fairness in the design of the TCP because both HTTP and FTP (which typically are used for bitrate measurements) use the TCP/IP protocol stack. The TCP by itself is designed to provide congestion control on the two ends (TCP client and TCP server) by adapting its speed to the available bandwidth, which results in available access link capacity being split equally among different TCP flows over the same link. It is possible that some of 7 Broadband QoS Parameters, KPIs, and Measurements the TCP flows will experience lower bitrates due to bottleneck link on the end-to-end path between the client and the server. What about the QoS measurement of real-time services (i.e. services sensitive to delay) over broadband Internet access? Real-time Internet services such as OTT VoIP (Skype, Viber, WhatsApp, etc.) use RTP/UDP/IP for transfer of the user real-time data, while TCP can be used also in this case for control and management traffic (because signaling is important to be lossless, and TCP provides that for the applications running above it). However, UDP/IP flows do experience packet losses because UDP does not have retransmission mechanisms of the lost packets/datagrams (as TCP 