飞鱼官网app下载|首页欢迎您!

  • <tr id='U8fUZm'><strong id='U8fUZm'></strong><small id='U8fUZm'></small><button id='U8fUZm'></button><li id='U8fUZm'><noscript id='U8fUZm'><big id='U8fUZm'></big><dt id='U8fUZm'></dt></noscript></li></tr><ol id='U8fUZm'><option id='U8fUZm'><table id='U8fUZm'><blockquote id='U8fUZm'><tbody id='U8fUZm'></tbody></blockquote></table></option></ol><u id='U8fUZm'></u><kbd id='U8fUZm'><kbd id='U8fUZm'></kbd></kbd>

    <code id='U8fUZm'><strong id='U8fUZm'></strong></code>

    <fieldset id='U8fUZm'></fieldset>
          <span id='U8fUZm'></span>

              <ins id='U8fUZm'></ins>
              <acronym id='U8fUZm'><em id='U8fUZm'></em><td id='U8fUZm'><div id='U8fUZm'></div></td></acronym><address id='U8fUZm'><big id='U8fUZm'><big id='U8fUZm'></big><legend id='U8fUZm'></legend></big></address>

              <i id='U8fUZm'><div id='U8fUZm'><ins id='U8fUZm'></ins></div></i>
              <i id='U8fUZm'></i>
            1. <dl id='U8fUZm'></dl>
              1. <blockquote id='U8fUZm'><q id='U8fUZm'><noscript id='U8fUZm'></noscript><dt id='U8fUZm'></dt></q></blockquote><noframes id='U8fUZm'><i id='U8fUZm'></i>
                設計 任務書 論文 開題 答辯 說明書 格式 模板 外文 翻譯 範文 資料 作品 文獻 課程 實習 指導 調研 下載 網絡教育 計算機 網站 網頁 小程序 商城 購物 訂餐 電影 安卓 Android Html Html5 SSM SSH Python 爬蟲 大數據 管理系統 圖書 校園網 考試 選題 網絡安全 推薦系統 機械 模具 夾具 自動化 數控 車床 汽車 故障 診斷 電機 建模 機械手 去殼機 千斤頂 變速器 減速器 圖紙 電氣 變電站 電子 Stm32 單片機 物聯網 監控 密碼鎖 Plc 組態 控制 智能 Matlab 土木 建築 結構 框架 教學樓 住宅樓 造價 施工 辦公樓 給水 排水 橋梁 剛構橋 水利 重力壩 水庫 采礦 環境 化工 固廢 工廠 視覺傳達 室內設計 產品設計 電子商務 物流 盈利 案例 分析 評估 報告 營銷 報銷 會計
                 首 頁 機械畢業設計 mile米乐集团 計算機畢業設計 土木工程畢業設計 視覺傳達畢業設計 理工論文 文科論文 畢設資料 幫助中心 設計流程 
                墊片
                您現在☆所在的位置:首頁 >>文科論文 >> 文章內容
                                 
                墊片
                   我們提供全套畢業設計和mile米乐体育服務,聯系點擊ζ 這裏給我發消息   1257590467   
                Transport protocols in multicast via satellite
                文章來源:www.biyezuopin.cc   發布者:學生畢◥業作品網站  

                In a wide variety of broadband applications, there is a need to distribute information to a potentially large number of receiver sites that are widely dispersed from each other. Communication satellites are a natural technology option and are extremely well suited for carrying such services because of the inherent broadcast capability of the satellite channel. Despite the potential of satellite multicast, there exists little support for multicast services over satellite networks. Although several multicast protocols have been proposed for use over the Internet, they are not optimized for satellite networks. One of the key multicast components that is affected when satellite networks are involved in the communication is the transport layer. In this paper, we attempt to provide an overview of the design space and the ways in which the network deployment and application requirements affect the solution space for transport layer schemes in a satellite environment. We also highlight some of the issues that are critical in the development of next generation satellite multicast services.

                1. Introduction

                In a wide variety of broadband applications, such as software updates, distributed computing, and multimedia content distribution, there is a need to distribute information to a potentially large number of receiver sites that are widely dispersed from each other. Communication satellites are a natural option for this because of the inherent broadcast capability of the satellite channel. Also, a satellite-based infrastructure can, in many cases, be established to offer widespread service provision with greater ease and simplicity than an infrastructure based on terrestrial broadband links, when the latter is not available. Hence, while much of the broadband communication today is carried via terrestrial links, satellites will come to play a greater and more important role, especially for point-to-multipoint services.

                Next-generation satellite communication systems utilizing higher frequency bands such as the Ka-band, spot-beam technology and on-board processing are currently under development。Ka-band is very desirable for satellite communication systems, because it offers abundant bandwidth. The use of spot-beam and on-board processing technologies enable the use of small, low-power, low-cost user terminals that offer two-way direct communication. These systems are likely to play an important role in the global communication infrastructure.

                Despite the potential of satellite multicast, there exists little support for multicast services over satellite networks. Although several multicast protocols have been proposed for use over the Internet, they are not optimized for satellite networks. Therefore, efficient integration of next generation satellite systems and multicast services requires the study and adaptation of these protocols. One of the key multicast components that is affected when satellite networks are involved in the communication is the transport layer.

                2.We consider two of the most common topologies for multicast service support involving broadband satellites

                (i) Satellite networks can be deployed as a backbone for interconnection of geographically distributed high-speed local area networks (LAN). In this scenario, LAN are connected to the satellite backbone through one or more gateway nodes that have satellite uplink capability (Figure 1(a)). This network topology gives rise to a hierarchical structure: satellite and gateway nodes acting as an overlay network for the LAN(s). In general, LAN(s) may also have access to a terrestrial core network. This network architecture provides unique opportunities for multicast distribution of data. In this scenario, the forward (downlink) feed may be used to efficiently distribute content to many sites, while the terrestrial links are used for transmission of out-of-band control information, user feedback, and data retransmissions.

                Figure 1. Satellite network topologies.

                (a) Case I: backbone deployment. (b) Case II: direct-to-home deployment.

                (ii) A direct-to-home (or direct-to-business) deployment, where the network consists of independent ground terminals with direct unit- or bi-directional connection to the satellite. In this scenario, network has a star topology and user terminals have no direct access to other networks. Ground terminals access the terrestrial core network through a gateway node located at the so-called network operations center (NOC) (Figure 1(b)). This architecture imposes additional challenges on the transport protocol, especially if reliable delivery of the data is required, because a satellite return channel is required and the transmission of user feedback, out-of-band control information, and data retransmission has to go through the satellite channel.

                3. Loss detection and feedback

                To provide reliability, a protocol needs to identify the packets that failed to reach a given destination. This is achieved through loss-notification (feedback) packets returned to the designated source  by the receivers. Traditionally, this feedback has been in one of the following forms:

                * Positive acknowledgments (ACK): Receivers return ACK packets to the designated source, indicating which packets have been received.

                * Negative acknowledgments (NACK): Receivers return NACK packets to the designated source, indicating only packets that are missing by a receiver.

                * A hybrid approach (both ACK(s) and NACK(s)).

                For multicast transport protocols, ACK-based loss-notification has been shown to lead to the ACK implosion problem. The problem arises when a large number of multicast receivers return an ACK packet for every packet they receive correctly, causing a serious network congestion around the links of the source. Another potential problem is that the source is required to keep track of the size, and the current state of the reporting receiver-set, in order to identify the last data packet correctly received by all receivers. In a large scale multicast application, the memory and processing load becomes prohibitive.

                NACK-based feedback alleviates some of the problems. The performance comparison study presented in Reference confirms that NACK-based multicast transport protocols deliver better performance than their ACK-based counterparts in wire line terrestrial networks. In NACK-based feedback, receivers detect missing packets by checking for gaps in the packet sequence numbers and report to the designated source. The source neither needs to know the size of the receiver-set at any point in time, nor keeps track of the current state of every receiver in its group. Also, the number of NACK packets is expected to be less than that of ACK packets at low error rates. A disadvantage is that it is more difficult for the source to know when it can free the transmission buffers, since NACK packets may be lost in transmission. For a satellite multicast application, the potential problems related to loss detection and user feedback are more pronounced. Due to high error rates over the satellite links and the potentially large number of receivers, even NACK-based feedback may lead to an implosion problem. Moreover, long propagation delays make retransmission of data in response to user feedback inefficient, if not impossible. In a backbone deployment, existence of terrestrial links allows the use of supporting mechanisms such as feedback aggregation and feedback suppression, which have been primarily developed with wire line terrestrial networks in mind. In a direct-to-home deployment, however, the applicability of these algorithms is limited, so we will further elaborate in Section 3.3.

                3.1 Loss reduction

                A packet recovery mechanism is an essential component of a reliable transport protocol.

                Automatic repeat request (ARQ) is a well-known technique for this purpose. In ARQ, sources respond to loss notification reports by retransmitting the missing packets. In a satellite multicast application, pure-ARQ for packet recovery turns out to be inefficient for several reasons. Long propagation delays associated with satellite links make the delay incurred during this repeat request process unacceptable for many delay sensitive applications (e.g. video streaming). The frequent and deep fades observed in satellite links result in high error rates and burst error patterns. Therefore, even if the feedback mechanism is efficient in returning the loss information back to the sources, in a typical wide area satellite deployment, considerable network bandwidth and processing time would be spent by retransmitting the different packets lost at different receivers. Several early papers exist on use of ARQ in satellite multicast applications

                3.2 Feedback suppression and aggregation

                Several existing multicast protocols adopt feedback suppression and feedback aggregation schemes to control the number and flow of feedback packets to avoid feedback implosion problem. Applicability of these methods in a satellite multicast application depends heavily on the   architecture of the deployed network.

                Feedback aggregation is applicable in networks where a logical or physical hierarchy is possible. Feedback aggregation relies on intermediate entities to collect, filter-out and combine feedback information towards the source. In a backbone scenario, it is possible for intermediate LAN routers to aggregate feedback packets from receiver nodes and to report only the aggregated feedback information to the satellite gateways. Gateway nodes can further aggregate reports from several routers to pass only single feedback information back to the source.

                3.3 Packet recovery

                In uncials communication, feedback reports are returned to sender and retransmissions are initiated by the sender. In order to avoid feedback implosion and traffic concentration at the sender and to reduce the packet recovery latency, several multicast protocols adopt local recovery methods. Local recovery allows designated nodes to buffer data packets, and initiate retransmissions on behalf of the sender. Therefore, receivers first try to recover missing packets through these nodes. If the missing packet can not be recovered through the use of designated nodes, then the retransmission request is forwarded to the sender. In networks where a logical or physical hierarchy is possible, intermediate routers can buffer the packets forwarded through them and initiate retransmission up on receiving a request. Coupled with feedback aggregation router-assisted local recovery is shown to improve the scalability and the performance of reliable multicast protocols

                Local recoveries of packets are particularly important in satellite networks because of the long propagation delays associated with satellite links. In a backbone deployment, satellite gateways are in a very good position to assist in the local recovery together with other intermediate routers. However, as it is the case with feedback aggregation, router-assisted local recovery requires support from intermediate network elements and its availability depends on existence of router extensions. A generalization of router-assisted local recovery is possible, if receiver nodes are also allowed to respond to retransmission requests. In this case, feedback packets need to be multicast to the set of receivers. However, efficient scoping of feedback and repair packets must be implemented to avoid flooding of network. In a direct-to-home deployment, all receivers receive packets directly from the satellite and there are no intermediate routers between satellite and the receivers. Therefore, it is difficult to implement local recovery for this type of networks.

                4. Protocol of data communications

                There is an effort in the research community to provide a ubiquitous end-to-end congestion control algorithm for hybrid satellite-terrestrial networks. This requires careful modification of the TCP protocol to match the characteristics of the satellite channels. Another approach is to split a connection at the terrestrial-satellite network interface, and to run TCP between the end nodes and the satellite network gateways, while running a customized algorithm in the satellite-only core network. The latter approach has several advantages in practice. It allows satellite provider to optimize the traffic flow inside the core network to achieve high utilization. Also, it makes it possible to push the congestion to the edges of the satellite network and let the TCP protocol’s congestion control mechanism to take care of the congestion in the terrestrial portion of the network. Inside the core network, the problem is reduced to a flow control problem rather than a congestion control problem since the satellite bandwidth is fixed and is to be shared among all the active connections. Hence, the satellite-only tier is isolated from the rest of the Internet, and flow control can be implemented by a simple window control mechanism. There is also no need to differentiate between losses due to congestion and losses due to link losses.

                Isolating the satellite network from the rest of the Internet would require additional functionality at the gateway nodes. However, we believe that satellite providers would be willing to go with this design, since the implementation will allow them to have full control of the traffic flow in their networks. Adding to this the challenges of having a TCP-like behavior for multicast services, we believe that, having a customized algorithm for the satellite network has considerable advantages.

                5. Conclusion

                In this chapter, we have presented a taxonomy and survey of various design alternatives for supporting multicast services, and discussed how the design space of various multicast transport protocol components are constrained in the context of satellite networks. Our classification is based on the IETF building blocks for multicast transport protocols, but highlights which components of a general transport protocol are affected by the two most common satellite network deployment scenarios.

                We also outlined some of the issues that are critical in the development of next generation satellite multicast services. Some of these problems, such as feedback implosion avoidance and packet level FEC coding at the transport layer, have counterparts in terrestrial networks, but they have to be addressed separately while taking into consideration the unique characteristics of satellite networks. We believe that efficient solutions to these problems and development of new technologies, such as on-board processing and buffering, would demonstrate the true value of satellite networks in the global communication infrastructure.

                  全套畢業設計論文現★成成品資料請咨詢點擊這裏給我發消息1257590467      返回首頁 如轉載請註明來Ψ源於www.biyezuopin.cc  

                                 

                打印本頁 | 關閉窗口
                本類最新文∴章
                全過程工程咨詢項目的投資管控研究 自信激揚力量 學習成就夢想——“ 中小企業品牌營銷研究mile米乐体育+開
                某服裝公司增值稅納稅籌劃方案設計 2021年會計畢業設計論文選題參 Transport protoc
                | 關於我們 | 友情鏈接 | 畢業▲設計招聘 |

                Email:biyeshejiba@163.com 在線QQ:   1257590467 mile米乐集团  
                本站畢業設計mile米乐体育資料均屬原創者所有,僅供學習交流之用,請勿轉載並做其他非法用途.如有侵犯您的版權有損您的利益,請聯系我們會立即改正或刪除有關內容!
                蜀ICP備10201305號-4

                mile米乐集团bms-sports.net

                mile米乐集团bms-sports.net