DOCSLIB.ORG

Ts 102 127 V8.0.0 (2018-08)

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read 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. The content of the PDF version shall not be modified without the written authorization of ETSI. The copyright and the foregoing restriction extend to reproduction in all media. © ETSI 2018. All rights reserved. DECTTM, PLUGTESTSTM, UMTSTM and the ETSI logo are trademarks of ETSI registered for the benefit of its Members. 3GPPTM and LTETM are trademarks of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. oneM2M logo is protected for the benefit of its Members. GSM® and the GSM logo are trademarks registered and owned by the GSM Association. ETSI Release 8 3 ETSI TS 102 127 V8.0.0 (2018-08) Contents Intellectual Property Rights ................................................................................................................................ 8 Foreword ............................................................................................................................................................. 8 Modal verbs terminology .................................................................................................................................... 8 1 Scope ........................................................................................................................................................ 9 2 References ................................................................................................................................................ 9 2.1 Normative references ......................................................................................................................................... 9 2.2 Informative references ...................................................................................................................................... 10 3 Definitions, symbols, abbreviations and coding conventions ................................................................ 10 3.1 Definitions ........................................................................................................................................................ 10 3.2 Symbols ............................................................................................................................................................ 11 3.3 Abbreviations ................................................................................................................................................... 11 3.4 Coding conventions .......................................................................................................................................... 11 4 Description ............................................................................................................................................. 12 5 CAT_TP layer ........................................................................................................................................ 13 5.0 Layers presentation........................................................................................................................................... 13 5.1 Data communication......................................................................................................................................... 13 5.2 Segmentation management ............................................................................................................................... 13 5.2.1 Segmentation and re-assembly ................................................................................................................... 13 5.2.1.0 Segmentation behaviour ........................................................................................................................ 13 5.2.1.1 N-SDU and N-PDU when segmentation is needed ............................................................................... 14 5.2.1.2 N-SDU and N-PDU when no segmentation .......................................................................................... 14 5.2.2 Limitations .................................................................................................................................................. 14 5.2.3 CAT_TP segmentation management .......................................................................................................... 14 5.3 Transport management ..................................................................................................................................... 15 5.3.1 CAT_TP connection management .............................................................................................................. 15 5.3.1.0 Connection description .......................................................................................................................... 15 5.3.1.1 Opening a connection ............................................................................................................................ 16 5.3.1.2 Ports ...................................................................................................................................................... 16 5.3.1.3 Connection states .................................................................................................................................. 16 5.3.1.3.0 Connection states presentation ........................................................................................................ 16 5.3.1.3.1 CLOSED state ................................................................................................................................. 17 5.3.1.3.2 LISTEN state ................................................................................................................................... 17 5.3.1.3.3 SYN-SENT state ............................................................................................................................. 17 5.3.1.3.4 SYN-RCVD state ............................................................................................................................ 17 5.3.1.3.5 OPEN state ...................................................................................................................................... 17 5.3.1.3.6 CLOSE-WAIT state ........................................................................................................................ 17 5.3.1.4 Connection record ................................................................................................................................. 17 5.3.1.4.0 Overview ......................................................................................................................................... 17 5.3.1.4.1 STATE............................................................................................................................................. 17 5.3.1.4.2 Variables for CAT_TP sending activity .......................................................................................... 18 5.3.1.4.3 Variables for CAT_TP receiving activity ........................................................................................ 18 5.3.1.4.4 Variables from current PDU ............................................................................................................ 18 5.3.1.4.5 Variables from SYN PDU ............................................................................................................... 18 5.3.1.5 Closing a connection ............................................................................................................................. 18 5.3.1.6 Detecting a Half-Open and/or inactive connection ............................................................................... 19 5.3.1.7 Version Number Management .............................................................................................................. 19 5.3.2 Reliable Communication ...........................................................................................................................
Load more

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]
  • 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.
    [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]
  • 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]