A Simple Fragmentation Protocol for Satellite Telemetry Transmission of Large Telemetry from the MIST Satellite

Total Page:16

File Type:pdf, Size:1020Kb

A Simple Fragmentation Protocol for Satellite Telemetry Transmission of Large Telemetry from the MIST Satellite DEGREE PROJECT IN TECHNOLOGY, FIRST CYCLE, 15 CREDITS STOCKHOLM, SWEDEN 2020 A simple fragmentation protocol for satellite telemetry Transmission of large telemetry from the MIST satellite ERIK FLINK KTH ROYAL INSTITUTE OF TECHNOLOGY SCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE A simple fragmentation protocol for satellite telemetry Transmission of large telemetry from the MIST satellite ERIK FLINK Degree Programme in Information and Communication Technology Date: June 7, 2020 Supervisor: Johan Montelius Examiner: Markus Hidell School of Electrical Engineering and Computer Science Host organization: MIST project Swedish title: Ett enkelt fragmenteringsprotokoll för satellit-telemetri Swedish subtitle: Sändning av stor telemetri från MIST-satelliten A simple fragmentation protocol for satellite telemetry / Ett enkelt fragmenteringsprotokoll för satellit-telemetri c 2020 Erik Flink Abstract | i Abstract MIniature STudent satellite(MIST) is a project at the Royal Institute of Technology (KTH) in Stockholm where students build a satellite. The satellite will be placed into orbit around the earth carrying six experiments. One of the experiments on-board the MIST satellite will need to send larger units of data than the radio on-board can send at a time. Therefore, the data will need to be fragmented before it is sent and then defragmented when it is received. The fragmentation protocol to be used, and its implementation, will need to meet the MIST satellite’s requirements and limitations. It should add as little overhead and complexity as possible. This thesis proposes a fragmentation protocol and presents an implementa- tion that enables experiments on-board the MIST satellite to send larger units of data than on-board radio allows. The design of the protocol is based on existing network protocols, but tailored for use on the MIST satellite. The proposed protocol may be possible to use in other satellites or embedded systems applications. This may however require some modifications. Keywords fragmentation, network, protocol, satellite, communication ii | Abstract Sammanfattning | iii Sammanfattning MIniature STudent satellite(MIST) är ett projekt på Kungliga Tekniska Högskolan(KTH) i Stockholm där studenter bygger en satellit. Satelliten kommer att placeras i omloppsbana runt jorden med sex experiment ombord. Ett av experimenten ombord på MIST-satelliten behöver skicka större data än vad radiomodulen ombord kan sända åt gången. Därför behöver datan fragmenteras innan den skickas och sedan defragmenteras då den tas emot. Fragmenteringsprotokollet som ska användas, och dess implementation, behöver uppfylla MIST-satellitens krav och begränsningar. Protokollet bör tillföra så lite overhead och komplexitet som möjligt. Detta examensarbete föreslår ett fragmenteringsprotokoll och presenterar en implementation som möjliggör för experimenten ombord MIST-satelliten att sända större data än vad radiomodulen tillåter. Protokollets design är baserat på existerande nätverksprotokoll, men skräddarsytt för att användas av MIST- satelliten. Det föreslagna protokollet kan användas av andra satelliter eller inbyggda system. Detta kan dock kräva vissa anpassningar. Nyckelord fragmentering, nätverk, protokoll, satellit, kommunikation iv | Sammanfattning Acknowledgments | v Acknowledgments I would like to thank MIST project manager Sven Grahn, MIST OBC team supervisor John Wikman and all other members of MIST team 11 who helped me during the thesis project. I would also like to thank MIST OBC team supervisor David Broman for introducing me to the MIST project and this topic. Due to the ongoing COVID-19 pandemic, work on this thesis was done from home without access to OBC hardware and ground station equipment. John Wikman made the equipment remotely available from his home, for which I am very grateful. Lastly I want to thank Johan Montelius for being my supervisor, supporting me during my thesis work, and those who have helped me to proofread this report. Stockholm, June 2020 Erik Flink vi | Acknowledgments CONTENTS | vii Contents 1 Introduction1 1.1 Background...........................1 1.2 Problem.............................2 1.3 Purpose.............................2 1.4 Goal...............................2 1.5 Methodology..........................3 1.6 Delimitations..........................3 1.7 Sustainability and ethics....................3 1.8 Structure of the thesis......................4 2 Background5 2.1 Network communication protocols...............5 2.2 Cube satellites..........................7 2.3 The MIST project........................7 2.4 Technologies used during the project.............. 12 3 Methodology 13 3.1 Identification of requirements and limitations......... 13 3.2 Examination of existing protocols............... 13 3.3 Design.............................. 14 3.4 Implementation......................... 14 3.5 Evaluation............................ 14 4 Existing Protocols 17 4.1 User Datagram Protocol (UDP) and Internet Protocol (IP)... 17 4.2 Transmission Control Protocol (TCP)............. 18 4.3 Reliable Data Protocol (RDP).................. 19 4.4 Cubesat Space Protocol (CSP)................. 19 4.5 Summary and Applicability................... 20 viii | Contents 5 Design 21 5.1 Design considerations...................... 21 5.2 Header fields.......................... 22 5.3 Fragmentation.......................... 24 5.4 Defragmentation........................ 25 6 Implementation 33 6.1 On-board software implementation............... 33 6.2 Ground station implementation................. 34 7 Analysis 37 7.1 Time complexity analysis.................... 37 7.2 Protocol overhead........................ 39 7.3 Theoretical net data rate..................... 39 8 Discussion 41 8.1 Time complexity........................ 41 8.2 Overhead............................ 41 8.3 Data rate............................. 42 8.4 Reliability............................ 42 8.5 Other use cases......................... 42 8.6 Conclusions........................... 43 8.7 Future work........................... 43 References 45 LIST OF FIGURES | ix List of Figures 2.1 Total Nanosatellites & CubeSats Launched [1].........7 5.1 Fragmentation protocol fields.................. 22 5.2 Pseudocode for generating fragments from a data block.... 25 5.3 Pseudocode for processing received fragments......... 28 5.4 Pseudocode for creating a new block buffer.......... 29 5.5 Pseudocode for inserting a fragment in an existing block buffer 30 5.6 Pseudocode for creating a block object from a block buffer.. 31 x | LIST OF FIGURES LIST OF TABLES | xi List of Tables 2.1 Experiments on-board the MIST satellite [2]..........8 2.2 BER over a typical ground station pass............. 11 7.1 Fragmentation protocol overhead for different block sizes with a fragment size of 214 bytes.................. 39 7.2 Theoretical net data rate for different block sizes with a fragment size of 214 bytes................... 40 xii | LIST OF TABLES LISTINGS | xiii Listings 6.1 The fragmenter struct...................... 33 6.2 Fragmentation API....................... 34 6.3 Defragmenter fields....................... 35 6.4 BlockBuffer fields........................ 35 6.5 Block fields........................... 35 6.6 Defragmentation API...................... 36 xiv | LISTINGS List of acronyms and abbreviations | xv List of acronyms and abbreviations Eb=N0 energy per bit to noise power spectral density ratio AAUSat3 Aalborg University CubeSat-3 API Application Programming Interface APID Application Process ID AX.25 Amateur X.25 BER Bit Error Ratio BPSK Binary Phase Shift Keying CCSDS Consultative Committee for Space Data Systems CSP Cubesat Space Protocol CUBES CubeSat x-ray Explorer using Scintillators ECSS European Cooperation for Space Standardization IETF Internet Engineering Task Force IP Internet Protocol ISIS Innovative Solutions In Space KTH Kungliga Tekniska Högskolan MIST MIniature STudent satellite MTU Maximum Transmission Unit OBC On-Board Computer PUS Packet Utilization Standard RDP Reliable Data Protocol RFC Request for Comments xvi | List of acronyms and abbreviations SFP Small Fragmentation Protocol SST Service Subtype ST Service Type TCP Transmission Control Protocol TRXVU ISIS Transceiver, UHF Transmitter and VHF Receiver TT&C Telemetry, Tracking and Command TTL Time To Live UDP User Datagram Protocol UHF Ultra High Frequency VHF Very High Frequency Introduction | 1 Chapter 1 Introduction In this thesis, a protocol for fragmenting data sent over a limited connection is proposed, examined and implemented for usage in the MIniature STudent satellite(MIST) satellite. This chapter first gives some background to and describes the problem that is addressed. The purpose and goals are then presented. The methodology and the delimitations are also described. 1.1 Background Cube satellites, or CubeSats, are a standardized type of small satellites that consists of one or more 10 ∗ 10 ∗ 10 centimeter cube units weighing 1.33 kg each [3]. The MIST project is a project at KTH where student teams build a three-unit (3U) CubeSat. The satellite will be launched into orbit around the earth carrying six experiments owned by different entities. The MIST satellite will be controlled by a On-Board Computer(OBC) that is purchased from Innovative Solutions In Space(ISIS), but the software is developed by a MIST sub-team at KTH. The OBC will collect data from the satellite’s experiments and sub-systems and send it down to a ground station located at KTH Campus in Stockholm. Data will be sent
Recommended publications
  • Uila Supported Apps
    Uila Supported Applications and Protocols updated Oct 2020 Application/Protocol Name Full Description 01net.com 01net website, a French high-tech news site. 050 plus is a Japanese embedded smartphone application dedicated to 050 plus audio-conferencing. 0zz0.com 0zz0 is an online solution to store, send and share files 10050.net China Railcom group web portal. This protocol plug-in classifies the http traffic to the host 10086.cn. It also 10086.cn classifies the ssl traffic to the Common Name 10086.cn. 104.com Web site dedicated to job research. 1111.com.tw Website dedicated to job research in Taiwan. 114la.com Chinese web portal operated by YLMF Computer Technology Co. Chinese cloud storing system of the 115 website. It is operated by YLMF 115.com Computer Technology Co. 118114.cn Chinese booking and reservation portal. 11st.co.kr Korean shopping website 11st. It is operated by SK Planet Co. 1337x.org Bittorrent tracker search engine 139mail 139mail is a chinese webmail powered by China Mobile. 15min.lt Lithuanian news portal Chinese web portal 163. It is operated by NetEase, a company which 163.com pioneered the development of Internet in China. 17173.com Website distributing Chinese games. 17u.com Chinese online travel booking website. 20 minutes is a free, daily newspaper available in France, Spain and 20minutes Switzerland. This plugin classifies websites. 24h.com.vn Vietnamese news portal 24ora.com Aruban news portal 24sata.hr Croatian news portal 24SevenOffice 24SevenOffice is a web-based Enterprise resource planning (ERP) systems. 24ur.com Slovenian news portal 2ch.net Japanese adult videos web site 2Shared 2shared is an online space for sharing and storage.
    [Show full text]
  • A Reliable Real-Time Transport Protocol for Networked Control
    AReliableReal-TimeTransportProtocolforNetworked Control Systems over Wireless Networks (Research Master) ATHESISSUBMITTEDTO THE SCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE OF QUEENSLAND UNIVERSITY OF TECHNOLOGY IN FULFILMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF INFORMATION TECHNOLOGY (RESEARCH) Xiaohan Shi School of Electrical Engineering and Computer Science Queensland University of Technology December 11, 2012 Copyright in Relation to This Thesis !c Copyright 2012 by Xiaohan Shi. All rights reserved. Statement of Original Authorship The work contained in this thesis has not been previously submitted to meet requirements for an award at this or any other higher education institution. To the best of my knowledge and belief, the thesis contains no material previously published or written by another person except where due reference is made. Signature: QUT Verified Signature Date: i ii To my family iii iv Abstract Deploying wireless networks in networked control systems (NCSs) has become more and more popular during the last few years. As a typical type of real-time control systems, an NCS is sensitive to long and nondeterministic time delay and packetlosses.However,thenatureof the wireless channel has the potential to degrade the performance of NCS networks in many aspects, particularly in time delay and packet losses. Transport layer protocols could play an important role in providing both reliable and fast transmission service to fulfill NCS’s real-time transmission requirements. Unfortunately, none of the existing transport protocols, including the Transport Control Protocol (TCP) and the User Datagram Protocol (UDP), was designed for real-time control applications. Moreover, periodic data and sporadic data are two types of real-time data traffic with different priorities in an NCS.Duetothelackofsupportfor prioritized transmission service, the real-time performance for periodic and sporadic data in an NCS network is often degraded significantly, particularly under congested network conditions.
    [Show full text]
  • High Speed WAN Data Transfers for Science
    1 Breaking the 1 GByte/sec Barrier? High speed WAN data transfers for science S. Ravot, J. Bunn, H. Newman, Y. Xia, D. Nae, X. Su, California Institute of Technology 1200 E California Blvd, Pasadena CA 91125 O. Martin CERN 1211 Geneva 23, Switzerland In this paper we describe the current state of the art in when the bandwidth and the latency increase. In particular, equipment, software and methods for transferring large TCP’s additive increase policy limits its ability to use spare scientific datasets at high speed around the globe. We bandwidth. first present a short introductory history of the use of In this paper we describe experiments that illustrate TCP’s networking in HEP, some details on the evolution, limitations. We report on our measurements using the current status and plans for the LHCnet, one of the largest network testbeds available Caltech/CERN/DataTAG transAtlantic link, and a today, having 10 Gb/s links connecting CERN in Geneva, description of the topology and capabilities of the Starlight in Chicago and the Caltech campus in Pasadena. research networks between CERN and HEP institutes In light of TCP’s limitations, we then explain how we have in the USA. We follow this with some detailed material tuned the end-systems and TCP Reno parameters to achieve on the hardware and software environments we have record breaking data transfers. Finally, we present an used in collaboration with international partners experiment currently underway in our group to transfer (including CERN and DataTAG) to break several High Energy Physics data files from a disk server at CERN Internet2 land speed records over the last couple of via a 10Gb/s network path to a disk server at Caltech (a years.
    [Show full text]
  • The Impact of Transport Protocol, Packet Size, and Connection Type on the Round Trip Time
    Bachelor of Science in Computer Science with specialization in Game Programming June 2017 The impact of transport protocol, packet size, and connection type on the round trip time Tobias Kling Faculty of Computing Blekinge Institute of Technology SE–371 79 Karlskrona, Sweden i This thesis is submitted to the Faculty of Computing at Blekinge Institute of Technology in partial fulfillment of the requirements for the degree of Degree of Bachelor of Science in Computer Science with specialization in Game Programming. The thesis is equivalent to 10 weeks of full-time studies. Contact Information: Author(s): Tobias Kling E-mail: [email protected] University Advisor: Francisco Lopez Luro Department of Creative Technologies Faculty of Computing Internet : www.bth.se Blekinge Institute of Technology Phone : +46 455 38 50 00 SE–371 79 Karlskrona, Sweden Fax : +46 455 38 50 57 Abstract While developing networking for games and applications, developers have a list of network specific requirements to be met as well as decide how to meet them. It is not always easy to decide what protocol is best suited for a given network configuration, or what is the best size of a data packet. By performing a comparative analysis, it becomes possible to identify how proto- cols, packet size, and network configuration impact the one-way travel time and throughput of a given implementation. The result shows how the different implementations compared against each other and the analysis tries to determine why they perform as they do. This gives a good overview of the pros and cons of how TCP, TCP(N), UDP, and RakNet, behave and perform over LANs and WLANs with varying packet size.
    [Show full text]
  • Network Protocols Handbook
    Third Edition Network Protocols TCP/IP Ethernet ATM Handbook Frame Relay WAN LAN MAN WLAN SS7/C7 VOIP Security VPN SAN VLAN IEEE IETF ISO Javvin Technologies,ITU-T Inc. ANSI Cisco IBM Apple Microsoft Novell I Table of Contents Table of Contents Network Communication Architecture and Protocols•••••••••••••••••••••••••••••••••••••••••••••1 OSI Network Architecture 7 Layers Model•••••••••••••••••••••••••••••••••••••••••••••••••••••••••2 TCP/IP Four Layers Archiitecture Model••••••••••••••••••••••••••••••••••••••••••••••••••••••••••5 Other Network Architecture Models: IBM SNA•••••••••••••••••••••••••••••••••••••••••••••••••7 Network Protocols: Definition and Overview•••••••••••••••••••••••••••••••••••••••••••••••••••••9 Protocols Guide••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••11 TCP/IP Protocols••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••11 Application Layer Protocols••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••13 BOOTP: Bootstrap Protocol•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••13 DCAP: Data Link Switching Client Access Protocol••••••••••••••••••••••••••••••••••••••••••••••••••••••14 DHCP: Dynamic Host Configuration Protocol•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••15 DNS: Domain Name System (Service) Protocol•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••16 FTP: File Transfer Protocol••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••17
    [Show full text]
  • Rethinking the NTCIP Design and Protocols Analyzing the Issues
    Rethinking the NTCIP Design and Protocols Analyzing the Issues 24-Apr-19951 prepared by Abstract This working paper discusses the issues involved in changing the current draft NTCIP standard from an X.25-based protocol stack to an Internet-based protocol stack. It contains a methodology which could be used to change NTCIP’s base protocols. This paper also includes background information on the current NTCIP draft standard and the Internet network architecture to build a common vocabulary for discussion and to present a review of those topics. 1Comments on this document should be addressed to: Joel Snyder, [email protected], +1 602 324 0494, via FAX to +1 602 324 0495, or via post to Opus One, 1404 East Lind Road, Tucson, Arizona 85719. March 3, 1998 Page 1 Introduction The Monza implementation team has been tasked with discussing relevant considerations to the use of the Internet Protocol (IP) suite of communication protocols instead of the X.25 suite. In order to best explain the issues involved, it's first necessary to define the role both IP and X.25 present to a networked system, and then examine the differences that the IP suite introduces to such a system. This document was prepared as a result of user response solicited by FHWA. The Monza team has no doubt that the current NTCIP draft represents an implementable and complete protocol description. However, the use of a different technology base inside of the NTCIP protocol may present additional advantages beyond those offered in the current system. Modern networked systems are discussed with regard to how their various parts represent the OSI Reference Model of networking, also referred to as the Seven Layer Model.
    [Show full text]
  • ETG Template
    WELCOME!!!!! 11.05.2011 The Ethernet Fieldbus Joey Stubbs, PE, PMP North American Representative EtherCAT Technology Group 11.05.2011 Ethernet Overview: CSMA/CD, TCP/IP & others • Architecture • Physical Layer: Signal, Cables + Wiring • Media Access Control • Name Resolution • Routing • IP, TCP + UDP This diagram was hand drawn by Robert M. Metcalfe and photographed by Dave R. Boggs in 1976 to produce a 35mm slide used to present Ethernet to the National Computer Conference in June of that year. 11.05.2011 ETG EtherCAT Training Class Ethernet Definition (Wikipedia) • Ethernet is a frame-based computer networking technology for local area networks (LANs). • It defines wiring and signaling for the physical layer, and frame formats and protocols for the media access control (MAC)/data link layer of the OSI model. • Ethernet is mostly standardized as IEEE's 802.3. • It has become the most widespread LAN technology in use during the 1990s to the present, and has largely replaced all other LAN standards such as token ring, FDDI, and ARCNET. 11.05.2011 ETG EtherCAT Training Class ISO/OSI, IEEE 802 and TCP/IP ISO/OSI - Model TCP/IP - Model 7 Application Layer 5 Application Layer: contains a variety of commonly used protocols, such as file HTTP, FTP, rlogin, Telnet, DHCP,... transfer, virtual terminal, and email 6 Presentation Layer manages the syntax and semantics of the information transmitted between two computers 5 Session Layer establishes and manages sessions, conversions, or dialogues between two computers 4 Transport Layer 4 Transport Layer: TCP + UDP splits data from the session layer into smaller packets for Handles communication among programs on a network.
    [Show full text]
  • QBIKGDP Through RXE
    QBIKGDP through RXE • QBIKGDP, page 4 • QFT, page 5 • QMQP, page 6 • QMTP, page 7 • QNX, page 8 • QOTD, page 9 • QQLIVE, page 10 • QRH, page 11 • QUOTAD, page 12 • RADIUS, page 13 • RADMIN-PORT, page 14 • RAP, page 15 • RCP, page 16 • RDA, page 17 • RDB-DBS-DISP, page 18 • RDP, page 19 • RDT, page 20 • REALMEDIA, page 21 • REALM-RUSD, page 22 • RE-MAIL-CK, page 23 • REMOTEFS, page 24 • REMOTE-KIS, page 25 • REPCMD, page 26 • REPSCMD, page 27 NBAR2 Protocol Pack 7.0.0 1 QBIKGDP through RXE • RESCAP, page 28 • RHAPSODY, page 29 • RIP, page 30 • RIPNG, page 31 • RIS, page 32 • RIS-CM, page 34 • RJE, page 35 • RLP, page 36 • RLZDBASE, page 37 • RMC, page 38 • RMIACTIVATION, page 39 • RMIREGISTRY, page 40 • RMONITOR, page 41 • RMT, page 42 • RPC2PORTMAP, page 43 • RRH, page 44 • RRP, page 45 • RSH-SPX, page 46 • RSVD, page 47 • RSVP, page 48 • RSVP_TUNNEL, page 49 • RSVP-E2E-IGNORE, page 50 • RSVP-ENCAP-1, page 51 • RSVP-ENCAP-2, page 52 • RSYNC, page 53 • RTCP, page 54 • RTELNET, page 55 • RTIP, page 56 • RTMP, page 57 • RTMPE, page 58 • RTMPT, page 59 • RTP, page 60 • RTSP, page 61 NBAR2 Protocol Pack 7.0.0 2 QBIKGDP through RXE • RTSPS, page 62 • RUSHD, page 63 • RVD, page 64 • RXE, page 65 NBAR2 Protocol Pack 7.0.0 3 QBIKGDP through RXE QBIKGDP QBIKGDP Name/CLI Keyword qbikgdp Full Name Qbik GDP Description Generic Discovery Protocol (GDP) is a protocol developed for finding or discovering Internet connectivity servers (such as WinGate).
    [Show full text]
  • Recent Advances in Reliable Transport Protocols∗
    Recent Advances in Reliable Transport Protocols∗ Costin Raiciu, Janardhan Iyengar, Olivier Bonaventure Abstract Transport protocols play a critical role in today’s Internet. This chapter first looks at the recent of the reliable transport protocols. It then explains the growing impact of middleboxes on the evolvability of these protocols. Two recent protocol extensions, Multipath TCP and Minion, which were both designed to extend the current Transport Layer in the Internet are then described. 1 Introduction The first computer networks often used ad-hoc and proprietary protocols to interconnect different hosts. During the 1970s and 1980s, the architecture of many of these networks evolved towards a layered architec- ture. The two most popular ones are the seven-layer OSI reference model [119] and the five-layer Internet architecture [27]. In these architectures, the transport layer plays a key role. It enables applications to re- liably exchange data. A transport protocol can be characterized by the service that it provides to the upper layer (usually the application). Several transport services have been defined: • a connectionless service • a connection-oriented bytestream service • a connection-oriented message-oriented service • a message-oriented request-response service • an unreliable delivery service for multimedia applications The connectionless service is the simplest service that can be provided by a transport layer protocol. The User Datagram Protocol (UDP) [87] is an example of a protocol that provides this service. Over the years, the connection-oriented bytestream service has proven to be the transport layer service used by most applications. This service is currently provided by the Transmission Control Protocol (TCP) [89] in the Internet.
    [Show full text]
  • Ts 102 127 V8.0.0 (2018-08)
    ETSI TS 102 127 V8.0.0 (2018-08) TECHNICAL SPECIFICATION Smart Cards; Transport protocol for CAT applications; Stage 2 (Release 8) Release 8 2 ETSI TS 102 127 V8.0.0 (2018-08) Reference RTS/SCP-T0015rcv800 Keywords protocol, smart card, transport ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N° 348 623 562 00017 - NAF 742 C Association à but non lucratif enregistrée à la Sous-Préfecture de Grasse (06) N° 7803/88 Important notice The present document can be downloaded from: http://www.etsi.org/standards-search The present document may be made available in electronic versions and/or in print. The content of any electronic and/or print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx If you find errors in the present document, please send your comment to one of the following services: https://portal.etsi.org/People/CommiteeSupportStaff.aspx Copyright Notification No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm except as authorized by written permission of ETSI.
    [Show full text]
  • Reliable User Datagram Protocol As a Solution to Latencies in Network Games
    electronics Article Reliable User Datagram Protocol as a Solution to Latencies in Network Games Jun-Ho Huh Department of Software, Catholic University of Pusan, Geumjeong-gu, 57 Oryundae-ro, Busan 46252, Korea; [email protected] or [email protected]; Tel.: +82-51-510-0662 Received: 20 September 2018; Accepted: 31 October 2018; Published: 2 November 2018 Abstract: One of the major problems in network games has been that of latency (lagging) that game technology researchers are still tackling. Latency largely affects user satisfaction and it is often caused by insufficient hardware capacity or the internet speed that the user is employing. Even though online games are becoming more complex and the number of participants in these games is increasing continuously, users cannot properly deal with the requirements to play these games, as system upgrades and subscription changes to a higher speed internet service are costly. Instead of passing such a burden on to the users, the game companies should instead invest in providing an improved communication algorithm. Thus, the reliable user datagram protocol (RUDP)-based communication system design has been considered in this research instead of transmission control protocol (TCP) or user datagram protocol (UDP)-based systems. This could be a viable alternative system model. Many researchers agree that RUDP is a better protocol for the transport layer, but it seems that the large-scale testbeds that could support such an idea and carry out direct tests are very scarce, meaning that actual experimental implementation is difficult to achieve. This suggests that game designers or researchers need to rely on a small-scale testbed to collect performance data.
    [Show full text]
  • Market Data Network Architecture (MDNA) Overview
    Market Data Network Architecture (MDNA) Overview Scope The scope of the Market Data Network Architecture (MDNA) includes the sources for market data streams (stock exchanges), the Financial Service Providers (FSP) and the final consumers of the data (Brokerage Houses). The network design and strategy for the Brokerage houses is consistent with the Trading Floor Architecture which is described in the Trading Floor Architecture document. Industry Stakeholders in Financial Services This section lists the key stakeholders that support and would implement a converged and standardized MDNA. See Figure 1. Corporate Headquarters: Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA Copyright © 2008 Cisco Systems, Inc. All rights reserved. Industry Stakeholders in Financial Services Figure 1 Market Data Distribution Players Content Content Content Provider Provider Provider Financial Services Provider Brokerage Brokerage Brokerage 225299 Stock Exchanges and Future/Option Exchanges Stock exchanges and future/options exchanges are the content providers (CPs) for market data. Financial Service Providers Financial Service Providers (FSPs) are specialized Service Providers (SPs) that tailor their products to meet the specific needs of the financial industry. Many of them are content aggregators and offer value added services such as analytics. Brokerage Houses These are the ultimate consumers of the market data and the people that place the orders. Software/Services/System Integrators Integrators are companies that are of part of the Financial Services Ecosystem (FSE) that creates products and services that tie everything together. Market Data Network Architecture (MDNA) Overview 2 OL-18257-01 Main Focus Areas Messaging/Transaction Standard Working Groups Standards working groups are organizations working on protocols for market data and financial applications.
    [Show full text]