HTML5 Webook

172/182

an index of quality of telemetry. However, the BER does not show directly the IP packet arrival rate, which is neces-sary information for practical communication protocols. In general geostationary orbit satellite communication service including WINDS, there is no method for network applica-tions to obtain a parameter in real time, which shows the quality of satellite communication links such as BER. erefore, a tool to measure the transmission condition of satellite links is needed. To the best of our knowledge, however, no tools for measuring network conditions have addressed a geostationary orbit satellite link at more than 1 Gbps.In this paper, we propose a novel tool to measure the packet loss ratio (PLR) of satellite communication links and cyclic redundancy check (CRC) errors, named hperf. hperf is based on the HpFP socket library [3]. We evaluate the performance of hperf in the WINDS network.e remainder of this paper is organized as follows. Section 2 presents the results of data communication ex-periments for the bent-pipe mode of WINDS conducted in the past. In Section 3, we explain about hperf and imple-mentation of the CRC error detection. Section 4 presents the results of measurement of network conditions over WINDS. Finally, we outline future works and conclude the paper in Section 5.2WINDS with bent-pipe mode for data transmissionIn this section, we summarize and discuss the perfor-mance of the HpFP over WINDS with bent-pipe mode. e experiments on the WINDS with bent-pipe mode using HpFP were conducted in February 2016, as shown in Fig. 1 [2]. Figure 2 shows the conguration of our experimental system. We measured throughput from the sender to the receiver using the quality measurement tool, hperf. e modem was originally developed and used as a relay, as shown in Figs. 3 and 4 shows the results of throughput measured by hperf in the experimental system shown in Fig. 2. In Figures 4 (b) and (c), the throughput of HpFP in the case of round trip time (RTT) of 0 ms, 250 ms, and 4,000 ms for two and 50 connections are shown, respec-tively.In this paper, we discuss mainly the case of RTT of 250 ms, which is the same RTT as the case of geostationary satellites. e throughput of the HpFP protocol for a single connection is 1.65 Gbps, as shown in Fig. 4 (a). Typically, the maximum throughput ever reached for HpFP is about 10 Gbps using a jumbo frame (packet size is 9,000 bytes) between the sender and the receiver in Fig. 2 [3]. e throughput of 1.65 Gbps in Fig. 4 (a) is due to the xed packet size (maximum transmission unit, MTU) of 884 bytes of the modem specication in Fig. 3.On the other hand, for bulk communication of multiple HpFP, the throughputs for both cases of two and 50 con-nections in Figs. 4 (b) and (c) nearly achieved 2.56 Gbps, which is the maximum value for the WINDS with bent-pipe mode. Note that the weather of the day of experiments was clear as shown in Fig. 1, and the PLR measured by hperf was almost 0%.3CRC function for HpFP3.1Implementation of CRC function for HpFPAs mentioned in Section 1, errors cannot be detected by normal UDP in the data transmission link of WINDS. In dedicated communication devices for satellite networks, functions of the relay devices used in the Internet are not necessarily designed and implemented. Especially in design of the modem used for the WINDS with bent-pipe mode, the CRC eld in the UDP header is discarded. erefore, it is very dicult to detect errors at the user level (applica-tion layer).In this research, errors are detected by implementing a new function of CRC into HpFP. ere are many variants of CRC. We adopt CRC-16-IBM, which is one of the imple-mentations of CRC-16 with 16 bits in length. Using HpFP, the receiver transmits acknowledgement (ACK) to the sender at a certain interval (every 200 ms) [3]. e number of packets that arrived with bit error at the receiver in this FiF1　WINDS satellite communication experiment Nakatsugawa, Gifu Prefecture) in February 2016 when the sky was almost clear3 Ultra-High-Speed Satellite Communication Technology168　　　Journal of the National Institute of Information and Communications Technology Vol. 64 No. 2 (2017)