Parity Forwarding for Multiple-Relay Networks

合集下载

A10 Thunder Convergent Firewall (CFW) Data Sheet说明

DATA S H E E T Thunder CFWConsolidated Firewall, CGN, ADC, VPN and Secure Web Gatewayperformance data center firewall includes a Layer 4 firewall with integrated DDoS protection and server load-balancing to protect data center assets from the inside out.enterprises and service providers. In mobile networks, it can be deployed as a security gateway to enable secure backhaul between the RAN nodes and the core network.The policy-based IPsec VPN also enables high-capacity client-to-site VPN deployment to support remote access clients in enterprise network.in from access networks and roaming partners to support uninterrupted operations. Thunder CFW can secure its own resources, such as NAT IP pools, to ensure that operational functions are not compromised.Gi/SGi LAN PROTECTIONEvolvedPacket Core (EPC)Radio Access NetworkMobile & IoT DevicesA10 Gi/SGi Firewall for the GiLANIn this scenario, a mobile network operator deploys the Gi/SGi firewall to secure communication between the EPC and the internet to protect the mobile coreinfrastructure. Integrated carrier-grade NAT enables carriers to manage communication with both IPv4 and IPv6 address protocols. Built-in DDoS protection safeguards the NAT IP pools to avoid service interruption. A10 Harmony ® Controller provides centralized management and analytics.business intelligence, tighter security controls, enhanced lawenforcement agency compliance and service monetization.Agile Management and Array Analytics-driven DashboardGain application and network servicesvisibility with the A10Harmony Controllerfor Thunder CFW. Centrally configureandmanage policies across services in a multi-cloud environment. Get real-time actionableinsights on firewall performance, criticalCGN services such as mapping distribution,NAT IP pool utilization and more, andapplication visibility including applicationdistribution by category, bytes consumed byapplication category.spam and phishing sources. The A10 URL Classification categorizes more than 460 million domains and 13 billion URLs into 83 categories to block undesirable sites and shield users from threats.Block Known Web ThreatsIdentify and block traffic going out to and coming in from known bad IP addresses on the internet with threat intelligence feeds.Prevent Data ExfiltrationIntegrate with third-party Data Loss Prevention (DLP) solutions via the industry-standard ICAP. Send decrypted traffic to DLP servers for inspection before forwarding intercepted traffic to a client or a server.Gain Superior Visibility and Control into Application TrafficIdentify and categorize traffic on the application level, allowing for more granular controls and policies to be defined, with application visibility and control. This DPI-based service provides application visibility with comprehensive user and group awareness, providing deep insights into network traffic. Understanding application traffic trends in enterprise networks allows for effective security planning and sanctioning of allowed business applications.A10 Thunder CFW DeviceInternetClientSecure Web Gateway Protects the Enterprise PerimeterDeploy Thunder CFW, with integrated SSL Insight technology, to decrypt traffic for a variety of security products, including inline, non-inline (passive/TAP) and ICAP-enabled devices.clouds, offering unprecedented telemetry as well as 100 percent RESTful API coverage. The product supports multi-tenancy features like application delivery partitions (ADP) for segmentation.7650 CFWThunderby the Numbers370Gbps8 MLayer 4 CPS128KRules384 MConcurrent SessionsThunder CFWThunder CFW IPsecData Center-to-Data CenterVPNVPNBy unifying IPsec VPN, firewall and application delivery controller (ADC) capabilities,organizations are able to both load-balance traffic and protect the data center, services and related applications from DDoS attacks and other threats.Thunder CFW provides industry-leading high performance as a physical, virtual or containerized solution. The physical appliance with hardware acceleration supports scalable and high-performance on-premises deployments. For NFVi and private cloud deployments, the virtual appliance works with leading hypervisors such as VMware ESXi, KVM and Microsoft Hyper-V, and integrates with leading NFV-MANO solutions including Ericsson Cloud Manager, NEC Netcracker HOM, Cisco NSO and Red Hat OpenStack andmore. For flexible and efficient cloud native deployments such as Docker and Kubernetes, the container option can be used.All Thunder CFW options run on A10’s ACOS software, providing feature parity, regardless of form factor, which helps simplify and consolidate operations in any deployment environment.Flexible Deployment OptionsHardware specifications and performance numbers are subject to change without notice, and may vary depending on configuration and environmental conditions. As for network interface, it’s highly recommended to use A10 Networks qualified optics/transceivers to ensure network reliability and stability.*1 Tested in single appliance SSLi deployment with maximum SSL option. Cipher "TLS_RSA_WITH_AES_256_CBC_SHA" with RSA 2K keys are used for RSA cases, "TLS ECDHE_RSA_WITH_AES_128_CBC_SHA256" with EC P-256 and RSA 2K keys are used for PFS case. | *2 With maximum SSL | *3 With base model | *4 Optional RPS available | *5 10Gbps speed only | *6 Fixed SFP+ optical ports with dual rate (10GBASE-SR and 1000BASE-SX) | *7 Hardware Bypass model comes equipped with the hardwareTLS acceleration | ^ Certification in process | + FIPS model must be purchasedHardware specifications and performance numbers are subject to change without notice, and may vary depending on configuration and environmental conditions. As for network interface, it’s highly recommended to use A10 Networks qualified optics/transceivers to ensure network reliability and stability.*1 Tested in single appliance SSLi deployment with maximum SSL option. Cipher "TLS_RSA_WITH_AES_128_CBC_SHA" with RSA 2K keys are used.*2 With maximum SSL*3 With base model. Number varies by SSL model+ Thunder 14045 comes with a splitter cable for console to provide access to both modules. | ^ Certification in process* Carrier-class firewall along with CGNAT and data-center firewall with ADC are the common use cases. SSL Insight (SWG) and IPsec are not adequate use cases. *******************************************************************************************.TestedwithUDPtrafficforCGNATusecase.Visibility and Analytics with Harmony Controller• CGNAT-Subscriber session insights-Session opening and closing rates-TopN flow consuming subscribers-TopN bandwidth consuming subscribers-Subscriber user quota alerts-CGN resource tracking-Mapping distribution per protocol and per technology-NAT IP pool utilization-Session distribution per NAT technology• Firewall-Firewall rule performance and rule distribution by protocol-Top firewall rules by state-GTP traffic insights, roam-in/out view and policy violation analytics-Comprehensive transduction log with source/destination IP, port, protocol, application, application category, and firewall actions for better visibility and faster troubleshooting• Application-Application distribution by category-Top destination IP by application distribution-Bytes consumed by application category Application-aware Firewall• Recognition of thousands protocol signatures with identification of service types within applications• Support custom rules that run real-timeIP Threat Intelligence• Prevents malicious traffic from entering your network, based on customizable risk score and toleranceThreat Investigator• Rich and contextual analytics for object under investigation Operation Modes• Transparent forward proxy• Explicit forward proxy• Proxy chainingCentralized Management and Analytics with Harmony Controller• Device and configuration management across multiple sites• Deployment wizard with guided configuration• Centralized security policy management and enforcement• Rich TLS/SSL traffic and decryption analytics for traffic insight, application insight, URL insight, source and destination insight and more• Threat investigator view• Session log drill-down• Troubleshooting tools• Extensive logging for auditADC• Advanced L4/L7 server load-balancing-Full HTTP proxy, Fast HTTP, HTTP/2, FIX, SIP, RADIUS, FTP, TCP, UDP and more -High-performance, template-based L7 switching with header/URL/domain manipulation-Comprehensive L7 application persistence support• DNS load balancing-Layer 4 (TCP, UDP) and Layer 7 (DNS-UDP, DNS-TCP-DNS over HTTPS (DoH), DNS over TLS (DoT)-Recursive DNS-DNS firewall/RPZ-DNS cache• Global Server Load Balancing (GSLB)• Comprehensive IPv4/IPv6 support• aFleX® TCL-based scripting: deep packet inspection and transformation for customizable, application-aware switching• HTTP acceleration: HTTP connection multiplexing (TCP connection reuse),• RAM caching, HTTP compression• SSL acceleration: Hardware SSL, TLS 1.2, TLS 1.3 support, Elliptic Curve Diffie-Hellman Exchange (ECDHE) and other PFS ciphers• ACME client support for automating TLS certificate renewal with Let’s Encrypt, Sectigo and else • Dynamic threat intelligence feed updated in near real time• 30-plus public, private and proprietary sources to block “call homes” to command and control servers, identify known attack sources and mitigate zero-day attacks.Scalable, High-performance Platform• Advanced Core Operating System (ACOS)-Multi-core CPU support-Linear application scaling with scalable symmetrical multi-processing (SSMP) architecture-ACOS on data plane• Linux on control plane• IPv6 feature parity• Flexible traffic acceleration (FTA) for scalable flow distribution, common attack mitigation-Hardware FTA utilizing FPGAs• Scale-out clusterNetworking• Integrated Layer 2/Layer 3• Transparent mode/gateway mode• Virtual wire interface support• Routing — static routes, IS-IS (v4/v6), RIPv2/ng, OSPF v2/v3, BGP4+• L2 protocols (STP, RSTP, MSTP)• VLAN (802.1Q)• Link aggregation (802.1AX), LACP• Access control lists (ACLs)• Traditional IPv4 NAT/NAPT• IPv6 NAPT• Jumbo frame support*• Hardware-accelerated VXLAN*• NVGRELearn More About A10 Networks Contact Us/contact ©️2023 A10 Networks, Inc. All rights reserved. A10 Networks, the A10 Networks logo, ACOS, Thunder, Harmony and SSL Insight are trademarks or registered trademarks of A10 Networks, Inc. in the United States and other countries. All other trademarks are property of their respective owners. A10 Networks assumes no responsibility for any inaccuracies in this document. A10 Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice. For the full list of trademarks, visit: /a10trademarks.Part Number: A10-DS-15112-EN-23 Feb 2023• Multi-tenancy with application delivery partitions (ADP) with L3-7 separation• L3 virtualizationDevOps Tools and Integration• Ansible modules and playbooks• Terraform Thunder provider• HashiCorp’s Consul and Network Infrastructure Automation (NIA) integration• Thunder Kubernetes Connector (TKC)• OpenStack Octavia driver• Cloud-init support for auto-configuration on-OpenStack-OCI-AWS-Azure• Prometheus integration for visibility and analytics monitoring* Features and certifications may vary by appliance.** Additional paid service.。

Orion A Power-Performance Simulator for Interconnection Networks

Orion:A Power-Performance Simulator for Interconnection NetworksHang-Sheng Wang Xinping Zhu Li-Shiuan Peh Sharad MalikDepartment of Electrical Engineering,Princeton University,Princeton,NJ08544hangshen,xzhu,peh,sharad@AbstractWith the prevalence of server blades and systems-on-a-chip(SoCs),interconnection networks are becoming an important part of the microprocessor landscape.How-ever,there is limited tool support available for their de-sign.While performance simulators have been built that enable performance estimation while varying network pa-rameters,these cover only one metric of interest in modern designs.System power consumption is increasingly becom-ing equally,if not more important than performance.It is now critical to get detailed power-performance tradeoff in-formation early in the microarchitectural design cycle.This is especially so as interconnection networks consume a sig-niﬁcant fraction of total system power.It is exactly this gap that the work presented in this paper aims toﬁll.We present Orion1,a power-performance interconnec-tion network simulator that is capable of providing de-tailed power characteristics,in addition to performance characteristics,to enable rapid power-performance trade-offs at the architectural-level.This capability is provided within a general framework that builds a simulator start-ing from a microarchitectural speciﬁcation of the intercon-nection network.A key component of this construction is the architectural-level parameterized power models that we have derived as part of this ing component power models and a synthesized efﬁcient power(and performance) simulator,a microarchitect can rapidly explore the design space.As case studies,we demonstrate the use of Orion in determining optimal system parameters,in examining the effect of diverse trafﬁc conditions,as well as evaluating new network microarchitectures.In each of the above,the abil-ity to simultaneously monitor power and performance is key in determining suitable microarchitectures.1Orion is one of the most powerful(brightest)network of stars(con-stellation)in the sky.It also stands for Open Research Infrastructure for Optimizing Networks.1IntroductionMicroprocessors are becoming increasingly intercon-nected.Clusters of computers and server blades connected by interconnection networks are widely deployed in server farms today.Single-chip multiprocessor systems are see-ing the use of interconnection networks as the only scalable solution to inter-processor communication[16].Emerging microprocessor systems will have to interface with an in-terconnection network fabric.In the future,routers and links will be critical components of a microprocessor sys-tem,alongside processors and memories.Researchers and designers have recognized the impor-tance of low-power computing,especially in emerging mi-croprocessor systems such as blades and SoCs.However, prior work has largely focused on the processing and mem-ory elements of microprocessors,neglecting the communi-cation components.These needs have become more criti-cal,as interconnection networks consume a signiﬁcant frac-tion of power in many microprocessor systems.In an Alpha 21364microprocessor[13],the integrated router and links consume25W of the total125W.2In a Mellanox server blade,the InﬁniBand switch is estimated to dissipate almost 37.5%of the blade’s power budget,taking15W out of the total power budget of40W,with the processor allocated the same power budget of15W[12].With ever-increasing de-mand for network bandwidth,power efﬁciency of intercon-nection networks will be even more important.Power models and simulators for processors and mem-ories have been proposed[3,4,25],enabling a rich body of research into power-efﬁcient mechanisms[2,18].There needs to be a similar drive towards better understanding of the power consumed by routers and links,the basic components of an interconnection network.In this paper, we present Orion,a network power-performance simulator where users can plug-and-play router and link components to form myriad network fabrics,run different communica-2This is an estimate obtained from Alpha designers,derived using av-erage power density from the earlier generation Alpha EV6.It includes power consumed by the router core and links.tion workloads on the fabric and investigate their impact on overall network power and performance3.To ease fu-ture integration with application simulators,our simulator is constructed within the Liberty Simulation Environment (LSE)[21]which is developed with the goal of enabling systematic architectural design space exploration.LSE al-ready has a user base in microarchitects who use it to model and simulate processors and memories.By extending it to incorporate routers and links,we attest to itsﬂexibility. Our goal is to provide a complete platform for exploring in-terconnected microprocessors,whether single-chip or span-ning multiple chips,at the architectural-level.The potential impact of Orion is twofold.On one hand, we see it providing designers with a framework for rapid exploration of interconnected microprocessor systems.On the other,by providing fast architectural-level power esti-mation,we see Orion enabling research in power-efﬁcient hardware and compiler techniques for emerging intercon-nected processors.In Section2,weﬁrst describe LSE,the simulation in-frastructure on which Orion is built upon,and the building blocks we identify for interconnection networks,aided by a hierarchical modeling methodology of on-chip communica-tion architectures[27].This is followed with a detailed dis-cussion of Orion’s power models for these building blocks in Section3.In Section4,we present three case studies ex-ploring different ways of using our simulator:to pinpoint the optimal power-performance design point for a speciﬁc microarchitecture;to see the impact application trafﬁc has on network power and performance;and to evaluate a new microarchitectural mechanism.Section5then delves into prior related work and Section6concludes the paper with a brief discussion of future directions.The Appendix presents the detailed power models,and explains how the power con-sumed by network operations are derived from these com-ponent power models.2The dynamic network simulator2.1Simulation infrastructureWe adopt LSE[21]as our basic simulation infrastruc-ture.LSE is a fast execution-driven compiled-code model-ing and simulation framework.LSE constructs concurrent structural models and retargetable simulators from a uniﬁed structural machine description and speciﬁcation database.It targets fast design space exploration for modern micropro-cessors,and has been used for processors and memories. In building Orion,we demonstrate its applicability to an-other domain.Itsﬂexibility ties in with our end-goal of 3Network performance refers to network latency–how quickly data gets shipped through the network,and network throughput–the amount of data per unit time that the network can handle before itsaturates.Figure1.Design,modeling and simulationprocess under LSE.providing a complete platform for exploring emerging mi-croprocessor microarchitectures,where processors,memo-ries,routers and links all play critical roles.In LSE,physical hardware blocks are modeled as logical functional modules that communicate through ports.Data is sent between module ports via message passing.Each mod-ule has its own pre-deﬁned parameters and control functions that generates operational and timing behavior for a wide range of application scenarios until pre-compilation stages. For example,a typical buffer module has ports correspond-ing to read/write ports,and parameters such as buffer size and width.The integration of power models is based on the event subsystem of LSE that facilitates the collection of execution ers deﬁne events associated with each module. Power models in the power simulation library are hooked to these events so when an event occurs during the execu-tion,it triggers the speciﬁc power model,which calculates and accumulates the energy consumed.Figure1shows the process of building a performance and power simulator in LSE.2.2Building blocks of an interconnection networkJust as a processor can be viewed as an assembly of indi-vidual components such as registerﬁles,ALUs,caches,etc, an interconnection network can be abstracted as composing of message generating,transporting and consuming agents, such as sources,router and link components and sinks re-spectively.A similar analogy can be drawn between instruc-tions thatﬂow through processor components and messages that stream through network components.A key aspect of our simulation environment is a careful selection of the building blocks(modules)of an intercon-nection network.This process is guided by a hierarchical modeling methodology of on-chip communication architec-ture[27].We identify the basic components such as mes-sage sources and sinks,router buffers,crossbars,arbiters and links.Conceptually,we classify these modules into two classes.The message transporting class of modules do notstore or modify messages when delivering them.Links and crossbars fall within this class.Another class of modules, the message processing class,generates,stores or modiﬁes message content.Message sources and sinks,buffers and arbiters fall within this second category.All the modules mentioned above support different types of operational and timing behavior depending on the dy-namic conﬁguration speciﬁed at the design stage.This gen-eralizes the modules so they can be utilized across different application scenarios.For instance,our modeling enables a buffer module to represent buffers ranging from a simple FIFO queue to complex dynamic prioritized multi-queue buffers.Through careful parameterization,we have been able to construct a fairly wide range of interconnection networks. Our experience shows that our relatively small library of modules is able to represent an extensive range of archi-tecture choices,from statically-scheduled on-chip networks to complex commercial InﬁniBand switches.A small pa-rameterized set of reusable modules is also critical for easy model maintenance.For instance,in Orion,wormhole[6] and virtual-channel[5]networks share exactly the same modules but with differently conﬁgured functional and tim-ing behavior.3Power modelingWe derive architectural-level parameterized power mod-els for several of the major building blocks identiﬁed in Sec-tion2,namely FIFO buffers,crossbars and arbiters.These components occupy about90%of the area of the Alpha 21364router[1],and are sufﬁcient for building a diverse range of router microarchitectures.Dynamic power,the primary source of power consumed in CMOS circuits,is formulated as,where en-ergy,with the clock frequency,the switching activity,the switch capacitance,and the supply voltage.We derive detailed parameterized equations for estimating switch capacitance of each component of an interconnection network,and track the switching activity of these components through network simulation.3.1Component power modelingTable1gives the terminology we use throughout the pa-per.We use Cacti[23]to compute the actual,and values.Transistor sizes can be user-input parameters, or automatically determined by Orion with a set of default values from Cacti[23]and applied with scaling factors from Wattch[3].Sizes of driver transistors,e.g.crossbar input drivers,are computed according to their load capacitance.denotes the energy dissipation per switch of componentTable1.Terminologygate capacitance of transistor/gatediffusion capacitance of transistor/gatecapacitance of metal wire of lengthor depending on how to count switches,provided is deﬁned,and is implicitly deﬁned when component capacitance is deﬁned.For each component,weﬁrst describe its canonical structure in terms of architectural and technological param-eters.We then proceed through detailed analysis to derive parameterized capacitance equations,taking into account both gate and wire capacitances.We then combine capaci-tance equations and switching activity estimation to derive energy consumption per component operation.To illustrate our power modeling methodology,we dis-cuss our modeling of FIFO buffers in routers.Buffers are typically implemented as SRAM arrays.We thus adapt architectural-level SRAM array power models that have been proposed for modeling caches and registerﬁles[9,28], incorporating several features speciﬁc to router microarchi-tectures.For instance,a buffer with a dedicated port to the switch does not require tri-state output drivers.Table2shows our power model for FIFO buffers–its canonical structure,architectural and technological param-eters,parameterized capacitance equations,and derived en-ergy equations for its operations.Capacitance equations are derived based on circuit structure.Take wordline capaci-tance as an example,each wordline is connected with memory cells through2pass transistors per memory cell, so is the sum of gate capacitance of these pass transis-tors,driver capacitance,and wire ca-pacitance.Power models for crossbars and arbiters are derived in a similar fashion,and are explained in detail in[22].They are also listed in the Appendix.3.2DiscussionArchitectural-level modeling.The goal of power mod-eling in Orion is to derive architectural-level parameterized power models that can provide reasonably accurate power estimates.While it would have been easier to estimate power based on simple rules of thumb such as transistor count and area,our power models are based on detailed es-timation of gate and wire capacitance and switching activi-ties.First,estimation based on transistor count and area can only be useful for estimating average power and are thus unable to reﬂect the impact of varying activity in a powerTable2.Model for FIFO buffersCanonical structureArchitectural parametersbuffer size inﬂitsﬂit size in bitsnumber of buffer read portsnumber of buffer write portsTechnological parametersmemory cell heightmemory cell widthwire spacingCapacitance equationswordline lengthbitline lengthwordline cap.read bitline cap.write bitline cap.precharge cap.memory cell cap.sense amp energy from empirical model[28]Operation energy equationsnumber of switching write bitlinesnumber of switching memory cells read energywrite energy()is the pass transistor connecting bitlines and memory cells,is the wordline driver,is the write bitline driver,is the read bitline precharge transistor,is the memory cell inverter.simulator.Second,information such as transistor count and area is typically not available at the time of architectural exploration.Model hierarchy and reusability.To maximize reuse of our power models,so users can extend them to new mi-croarchitectures easily,we construct our models in a hier-archical fashion,i.e.a model can have another as its com-ponent,so complex models can be built in a divide-and-conquer fashion.By reusing old models and hierarchically building new models,we can save signiﬁcant modeling ef-fort.For instance,in our modeling of central buffers,we heav-ily leveraged existing component power models rather than starting from scratch.Central buffers are implemented as pipelined shared memories[10],essentially regular SRAM banks connected by pipeline registers,with two crossbars facilitating the pipelined data I/O.We reused our FIFO buffer model for the SRAM banks,and theﬂip-ﬂop sub-component models from our arbiter model for the pipeline registers.The two crossbars are modeled with our crossbar power model.Through a well-deﬁned interface to propa-gate data and collect power statistics,the top-level central buffer model interacts with these lower-level models to es-timate the power consumption.Validation.We are in the process of validating our power models against measured power numbers of exist-ing routers,and against low-level power estimation tools. Preliminary validation with router designers’guesstimates found the power estimates derived by Orion for two com-mercial routers–the Alpha21364router[13]and the IBM InﬁniBand8-port12X switch[8]to be within ballpark[22]. Due to the sensitivity of the data,we have yet to obtain rig-orous power estimates or measurements of the two routers, and are thus unable to provide precise error margins.This is the focus of our current efforts,and we are actively ex-ploring more detailed validation of both chip-to-chip and on-chip networks through close collaboration with various design groups.Link power modeling.A large variety of link architec-tures has been proposed for interconnection networks,both for chip-to-chip and on-chip signaling.Across different link architectures,power characteristics differ greatly.For this paper,we choose to plug in actual power numbers of spe-ciﬁc links obtained from published datasheets.It is clearly preferable to have parameterized link power models,just as we have parameterized router power models,so architects can perform architectural-level tradeoffs for links as well. We are currently working with chip-to-chip and on-chip link designers to develop such parameterized link power models.Release of power models.We will be distributing our power models(coded in C)as part of Orion’s release.This will allow our power models to be used independently from the simulator,either as a separate power analysis tool,or as a plug-in to other network simulators.portsmodules LegendFigure 2.A simple wormhole router as mod-eled in Orion.3.3Walkthrough example of a simple wormholerouterWe now show how a simple wormhole router is modeled in Orion,and walk a head ﬂit 4through the router,showing how its power consumption is estimated.We assume the router has 5input/output ports,with 4ﬂit buffers per input port and each ﬂit 32bits wide;a 55crossbar and a 4:1arbiter per output port 5.We also assume source routing for simplicity.Figure 2sketches the module representation of a worm-hole router and its neighboring links in Orion.The source module injects a head ﬂit into the write port of the input buffer module Buf I .The buffer module writes the ﬂit into the tail of the FIFO buffer and emits a buffer write event,which triggers the buffer power model to compute bufferwrite energy.When the ﬂit emerges at the head of the FIFO buffer,it is checked via the read port of the buffer module,its routeread,and a request sent to theport of the arbiter mod-ule for the desired output port,say the north output port.The arbiter module performs the required arbitration and emits an arbitration event,which signals the arbiter powermodel to compute arbitration energy.Assuming the request is granted,the arbitration result is sent to the conﬁg port of the crossbar module.A grant signal is also sent to the grant port of the buffer module Buf I ,lead-ing to the read port of the buffer module activated.The ﬂit is then read,emitting a buffer read event,which causes thebuffer power model to compute buffer read energy.The ﬂit next traverses the crossbar,from input port,to the north output port .The crossbar module emits a crossbar traversal event and the crossbar power modelcomputes traversal energy.Finally,the ﬂit leaves the router,enters the in port of the4Aﬂit is the smallest unit of ﬂow control,and is a ﬁxed-sized unit of a packet.5We assume a ﬂit does not u-turn and leave through the same head ﬂit through the router.link module,traverses the link and leaves through the out port of the link module.The link module emits a link traver-sal event,which calls the link power model to compute linktraversal energy.The total energy this head ﬂit has consumed at this node and its outgoing link is thus:4Case studiesWe foresee three potential ways of using Orion for rapid exploration of network microarchitectures,as shown in Fig-ure 3.Subsequently,we will discuss three case studies demonstrating instances of these three usage categories and show how the architectural-level exploration of network power-performance tradeoffs enabled by Orion provided valuable insights.First,the architect may wish to trade-off two conﬁgura-tions of a microarchitecture,exploring their effect on net-work power and performance.This involves selecting the modules forming that microarchitecture,and setting differ-ent module parameters for the two conﬁgurations.Given a representative communication workload of the targeted ap-plication,the user can feed the workload and conﬁgurations into two different instances of Orion,and obtain their power and performance numbers.Second,an architect may wish to explore the impact of two application trafﬁc patterns on a speciﬁc network mi-croarchitecture,to see if the network can handle diverse communication patterns.This can be part of a study to de-sign a network suitable for various communication patterns representative of an application suite.It can also be used to provide feedback to the compiler or application program-mer on how to better place the program and data to avoid communication patterns that adversely tax network power and performance.Third,a researcher may devise a new microarchitectural technique and wish to explore its impact on interconnec-tion network power and performance,evaluating it against a base microarchitecture.This may involve deﬁning one or several new modules,along with new power u-ally,a module can be reused,with novel functional and tim-ing characteristics ponent power models can also typically be leveraged and modiﬁed for new microar-chitectures,as we will demonstrate subsequently.4.1Experimental setupWe assume a 16-node network organized as a 44torus,as shown in Figure 4.Each router has ﬁve physical bidi-rectional ports (north,south,east,west,injection/ejection)performance>performance> (a)Exploring differentconﬁgurations performance>performance> (b)Exploring different work-loads(c)Exploring new microarchitecturesFigure3.Three potential ways of using OrionFigure4.A4-by-4torus network.and propagation delay across data and credit channels is as-sumed to take a single cycle.Credit-basedﬂow control reg-ulates the use of buffers,i.e.,a credit is sent back to theprevious router whenever aﬂit leaves,so a router can main-tain a count of the number of available buffers,and noﬂitsare forwarded onto the next hop unless there are buffers tohold it.Since our case studies focus on exploring the im-pact of network microarchitectures and workloads on per-formance and power,we choose simple source dimension-ordered routing6where the route is encoded in a packet be-forehand at source.In our experiments,the simulator generates uniformlydistributed trafﬁc to random destinations,unless otherwisementioned.Each simulation is run for a warm-up phaseof1000cycles with10,000packets injected thereafter andthe simulation continued at the prescribed packet injectionrate till these packets in the sample space have all been re-ceived,and their average latency tency spansfrom when theﬁrstﬂit of the packet is created,to when itslastﬂit is ejected at the destination node,including sourcequeuing time and assuming immediate ejection.The sat-uration throughput of a network is deﬁned as the point atwhich average packet latency increases to more than twicezero-load latency,i.e.the latency experienced by packetswhen there is no contention in the network.Packets are5-ﬂit long,consisting of a headﬂit leading4dataﬂits.Routersare pipelined in accordance to the router delay model pro-posed in[15].The simulator records energy consumption of each com-ponent(input buffer,crossbar,arbiter,link)of a node overthe entire simulation excluding theﬁrst1000cycles.Aver-6Dimension-ordered routing is where a packet always goes along onedimensionﬁrst,followed by another.age power is then computed by multiplying the total energyby frequency and then dividing by total simulation cycles.In our experiments,a typical4x4torus network usingvirtual channels comprises59modules.The constructedOrion simulator is5202KB in size,with a system simula-tion speed of about1000simulation cycles per second on aPentium III750MHz machine running Linux.4.2Exploring different conﬁgurations:wormholevs.virtual-channel routersWe assume an on-chip network similar to that in[7],i.e.a44torus network on a12mm12mm chip with256-bitﬂits,clocked at2GHz,with,in0.1m pro-cess technology.Link capacitance is1.08pF/3mm using thesame parameters in our router modeling.is computedfrom link capacitance and link switching activities reportedby Orion.We simulate and compare four different router conﬁgu-rations:-wormhole router with64-ﬂit input buffer per port(WH64).virtual-channel(VC)router with2VCs per port and8-ﬂit input buffer per VC(VC16).virtual-channel router with8VCs per port and8-ﬂitinput buffer per VC(VC64).virtual-channel router with8VCs per port and16-ﬂitinput buffer per VC(VC128).As prescribed by[15],these virtual-channel routersﬁtwithin a3-stage router pipeline of virtual-channel alloca-tion,switch allocation and crossbar traversal,and the worm-hole router has a2-stage router pipeline of switch arbitrationand crossbar traversal.All routers have a55crossbar.Figure5graphs results obtained from simulating theserouters in Orion.Figure5(a)shows VC16out-performingWH64,despite having only a quarter of the buffering perinput port,saturating at a higher packet injection rate of0.15packets/cycle/node.In addition,this performance im-provement is not achieved at the expense of higher powerconsumption,as indicated by Figure5(b).In fact,VC1650010001500200025003000350000.020.040.060.080.10.120.140.160.180.2a v e r a g e p a c k e t l a t e n c y (c y c l e )packet injection rate (packet/cycle/node)VC16VC64VC128WH64(a)average packet latency 01020304050607000.020.040.060.080.10.120.140.160.180.2n e t w o r k p o w e r (W )packet injection rate (packet/cycle/node)VC16VC64VC128WH64(b)total network power0102030405060708090100p e r c e n t a g e o f c o m p o n e n t p o w e r (%)packet injection rate (packet/cycle/node)(c)VC64average power breakdown,arbiter power is invisible at current scale.Figure 5.Power-performance of on-chip 44torus networks governed by wormhole and virtual-channel ﬂow control at varying packet injection rates.dissipates less power than WH64at the same packet injec-tion rate before the network saturates.Beyond packet in-jection rate of 0.11packets/cycle/node,VC16starts to con-sume more power than WH64,since it is still able to absorb the higher packet injection rate,so network activity contin-ues to increase.For all conﬁgurations,total network power levels off after saturation,since the network cannot handle a higher packet injection rate,so the switching activity of the network remains constant.It is interesting to note that VC64dissipates approxi-mately the same amount of power as WH64before satu-ration.Intuitively,since virtual-channel ﬂow control is a more complicated protocol,requiring more complex hard-ware,we would expect a virtual-channel router to be more of a power hog than a wormhole router.Figure 5(c)ex-plains why the difference is not signiﬁcant.It shows input buffers and the crossbar switch fabric as the two dominant power consumers of a node (consuming more than 85%of total node power).7While virtual-channel ﬂow control requires more complicated arbitration circuitry,the power consumed by arbiters (less than 1%of node power)is min-imal.Hence,the impact on total node power is negligible.Clearly,our experiments show virtual-channel ﬂow control returning better power-performance than wormhole.Since buffer power is signiﬁcant,VC128dissipates higher network power as compared to VC64or VC16.When this translates to higher network throughput,the in-crease in power may be acceptable.Clearly,it will not be viable to choose VC128over VC64with our conﬁguration,since the additional power dissipation is not matched with an improvement in performance.By providing a platform7In[7],it is estimated that links take up considerably more power than routers.The huge difference between our estimates and theirs is largely because they consider all datapath power as link power,while we consider datapath within the router (crossbar)as router power.for simulating both power and performance,Orion provides the architect a tool for exploring the optimal conﬁgurations of a network microarchitecture.4.3Exploring different workloads:broadcast vs.uniform trafﬁcJust as an application’s execution patterns heavily im-pact the power-performance of a processor,an application’s communication patterns also critically affect the power-performance of a network.We select two different communication patterns :-uniform random trafﬁc,i.e.each node injects packets to randomly distributed destinations other than itself in the network.broadcast trafﬁc,i.e.one node injects packets to all the other nodes in the network.Both communication workloads inject packets at a uni-form rate.The total packet injection rate across the entire network is kept the same across the two workloads.For broadcast trafﬁc,the source node at position (1,2)injects at the maximum rate of 0.2packets per cycle.For uniform ran-dom trafﬁc,each node injects at a rate ofpackets per cycle,so total packet injection rate for the entire net-work is still 0.2packets per cycle.Network topology is ﬁxed across the workloads as a 44torus.We also ﬁx the router microarchitecture –virtual-channel routers with 2VCs per port and 8ﬂit buffers per VC.Other aspects of the network microarchitecture remain the same as conﬁgured in the previous experiment,i.e.an on-chip network.Figure 6shows the average power consumed by each node in the 44network as caused by the diverse trafﬁc pat-terns.Uniform random trafﬁc results in a rather ﬂat power。

Moxa TAP-323 铁路轨道边缘无线电说明书

TAP-323系列鐵路軌旁雙無線電802.11n IP68無線AP特色與優點•2個雙頻無線電，符合IEEE802.11a/b/g/n規範•IP68等級堅固外殼，支援-40至75°C的操作溫度•基於控制器的Turbo Roaming（小於50毫秒）1•2個光纖SFP插槽和4個PoE連接埠（M12LAN連接器）•符合所有EN50155標準強制性測試項目2•符合EN50121-4標準•無線網路冗餘加上AeroLink保護•高傳輸功率提供更長的覆蓋範圍認證簡介TAP-323鐵路軌旁無線裝置專為列車對地無線通訊而設計。

TAP-323是一款極度小巧又堅固耐用的無線設備，將兩個存取點、一個網管光纖交換機，和一個寬壓版的AC/DC電源供應器整合在一台設備上。

IP68等級的外殼可以讓設備承受嚴苛的天氣狀態，M12接頭讓設備可以抗衝擊和震動。

TAP-323支援進階的基於控制器的Turbo Roaming快速漫遊技術，使用在列車對地的無線應用，像是通訊式的列車控制系統（CBTC）和CCTV。

此設備最多可供電給4個PoE設備，同時透過Moxa Turbo Chain的技術，提供可靠的LAN通訊。

進階移動性與可靠性•控制端L3Turbo Roaming快速漫遊•支援行動IP•2組雙頻無線電：2.4GHz及5GHz•支援Turbo Chain（100毫秒恢復時間）•支援WPA/WPA2及802.11i•支援IEEE802.1X/RADIUS專為交通運輸應用設計•110至220VDC/VAC隔離式電源輸入•高傳輸功率400mW（最大值）•透過4個PoE連接埠供電•2個支援骨幹安裝的光纖SFP連接埠•支援寬溫（-40至75°C）和IP68等級外殼規格WLAN InterfaceChannel Bandwidth5MHz,10MHz,20MHz,40MHzFrequency Band5GHz2.4GHz1.此處所指的Turbo Roaming快速漫遊復原時間是在最佳狀態下，配置無干擾20MHz RF頻道、WPA2-PSK安全性和預設的Turbo Roaming快速漫遊參數，所得到的測試結果平均值。

计算机网络专业词汇中英对照

《计算机网络》中英文对照Chapter 1End system P28 端系统Modem P29 调制解调器（俗称：猫）Base station P29 基站Communication link P30 通信链路Physical media P30 物理介质Coaxial cable P30 同轴电缆Fiber optics P30 光纤Radio spectrum P30 射频频谱Transmission rate P30 传输速率Packets P30 （数据）包，或分组Routers P30 路由器Link-layer switches P30 链路层交换机Path P30 路径ISP (Internet Service Provider) P30 网络服务提供商TCP (Transmission Control Protocol) P31 传输控制协议IP ( Internet Protocol) P31 网际协议Intranets P31 内网API (Application Programming Interface) P32 应用程序编程接口Network edge P35 网络边缘Access Networks P38 接入网Ethernet P42 以太网Network core P48 网络核心Circuit Switching P50 电路转换Packet Switching 分组交换FDM (frequency-division multiplexing) P50 频分多路复用TDM (time-division multiplexing) P50 时分多路复用Statistical Multiplexing 统计复用Store-and-forward 存储转发Queuing delays P53 排队延迟Transmission delay P60 传输延迟，或发送延迟Propagation delay P60 传播延迟Throughput P59 吞吐量Internet backbone P57 骨干网Delay P59 延迟，或时延Loss P59 丢包Packet-Switched Network P59 分组交换网络Nodal processing delay P60 节点处理延迟End-to-end delay P66 端到端延迟Instantaneous throughput P68 瞬时吞吐量Network interface card P74 网络接口卡（即网卡）Message P75 消息，或报文Segment P75 （报文）段Datagram P75 数据报Frames P75 帧Packet sniffer P82 数据包监听器Protocol Stack 协议栈Peer entities 对等实体Chapter 2 应用层Server farm P110 服务器集群Infrastructure P110 基础设施，或基础架构Self-scalability P111 自扩展性Timing P114 实时性Bandwidth-sensitive applications P115带宽敏感应用Connection-oriented service P117 面向连接的服务Directory service P121 目录服务Base HTML 基本HTML文件Stateless protocol P124 无状态协议RTT (round-trip time ) P126 往返时间Web proxy caches P128 网页代理缓存Status line P130 状态行Out-of-band P141 （频）带外（的）In-band P141 带内（的）User agents P144 用户代理Mail servers P144 邮件服务器Pull protocol P148 拉式协议Push protocol p148 推式协议Host aliasing P158 主机别名Canonical hostname P158 规范主机名Mail server aliasing P158 邮件服务器别名Load distribution P158 负载分配Top-level domain (TLD) servers P161 顶级域名服务器Authoritative DNS servers P161 权威域名服务器Iterative queries P168 迭代查询Resource records (RRs) P165 资源记录Overlay network P179 覆盖网Nonpersistent HTTP 非持久HTTP，或非坚持HTTP Persistent HTTP 持久性HTTP，或坚持的HTTP Peer-to-Peer (P2P) Network 对等网络Socket programming 套接字编程Chapter 3 传输层Multiplexing and demultiplexing P226 复用与分用Unidirectional data transfer P241 单向数据传送Finite-state machine (FSM) P242 有限状态机Positive acknowledgments P243 肯定确认Negative acknowledgments P243 否定确认Countdown timer P250 （倒数）计时器Cumulative acknowledgment P258 累积确认Receive buffer P269 接收缓冲区，或接收缓存Resource-management cells 资源管理单元Source (port number) 源端口号Destination (port number) 目的端口号Checksum 校验与Pipelined protocols 流水线（型）协议Go-back-N 回退NSelective Repeat 选择重传Timeout （定时器）超时Fast Retransmit 快速重传Flow Control 流量控制Three way handshake 三次握手sequence number 序列号（简写为seq）acknowledgement number 确认号（简写为ack；注意与大小的ACK不同）Congestion Control 拥塞控制additive increase, multiplicative decrease 加性增乘性减Slow Start 慢启动congestion-avoidance 拥塞避免fast recovery 快速恢复duplicate (ACK) 冗余（ACK）Random Early Detection 随机早期检测Chapter 4 网络层Forwarding table P338 转发表Virtual-circuit networks P343 虚电路网络Datagram networks P343 数据报网络Signaling message P346 信令报文Content Addressable Memory P354 内容可寻址存储器Crossbar switch P356 纵横开关Active queue management 主动队列管理Head-of-the-line (HOL) 队头Classless interdomain routing (CIDR) P371 无类域间路由Plug-and-play P376 即插即用Anycast P386 任播Interior gateway protocols P414 内部网关协议Routing information Protocol P414 路由信息协议（RIP）Open shortest Path First OSPF P414 开放最短路径优先Area border routers P419 区域边界路由器Sequence-number-controlled flooding P430 序列号控制的洪泛，或带序列号的受控洪泛Reverse path forwarding (RPF) P431 逆向路径转发Rendezvous point P433 汇聚点Longest prefix matching 最长前缀匹配Scheduling 调度Fragmentation 分片，或分段Fragment Offset 报文段偏移量Network Address Translation (NAT) 网络地址转换NAT traversal NAT穿越Multicast 组播，或多播Unicast 单播Tunneling 隧道技术Link-State Routing Algorithm 链路状态路由算法Distance Vector Routing Algorithm 距离向量路由算法Count to Infinity Problem 无穷计数问题Hierarchical Routing 分层路由autonomous systems 自治系统BGP (Border Gateway Protocol) 边界网关协议in-network duplication 网内复制broadcast storm 广播风暴spanning tree 生成树redundant packets 冗余数据包Chapter 5 数据链路层，或链路层Broadcast channels P461 广播信道Trailer fields P464 尾部字段Link access P464 链路接入，或链路访问Network interface card P466 网络接口卡（即网卡）Parity checks P469 奇偶校验Forward error correction (FEC) P471 前向纠错Cyclic Redundancy Check 循环冗余校验Polynomial code P472 多项式码（即CRC码）Multiple access P475 多路接入Random access protocols P477 随机接入协议CSMA/CD P484 带冲突检测的载波侦听多路访问CSMA/CA 带冲突避免的载波侦听多路访问Token passing protocol P487 令牌传递协议ARP P491 地址解析协议Preamble P497 前导（字段）Exponential backoff P502 指数回退，或指数退避Repeater P504 中继器Virtual-channel identifier P520 虚拟信道标识Cell-loss priority P520 信元丢失优先权Label-switched router P524 标签交换路由器Framing （封装）成帧error detection 误差检测，或检错Channel Partitioning 信道分割式（MAC协议）Taking turns MAC protocol 轮流式MAC协议Collision 冲突，或碰撞Time Slot 时隙Slotted ALOHA 时隙ALOHAUnslotted ALOHA 无时隙ALOHA Nonpersistent CSMA 非坚持CSMA1-persistent CSMA 1坚持CSMAp-persistent CSMA p坚持CSMAToken Ring 令牌环(Wireless) LAN （无线）局域网Hub 集线器Collision domain 冲突域Bridge 网桥。

迈克罗斯 AWK-3131-M12-RCC 系列产品介绍说明书

IntroductionSpecificationsAWK-3131-M12-RCC SeriesThe AWK-3131-M12-RCC series industrial 802.11n wireless AP/bridge/client is an ideal wireless solution for applications such as onboard passenger infotainment systems and inter-carriage wireless backbone networks. The AWK-3131-M12-RCC series provides a faster data rate than the 802.11g model and is ideal for a great variety of wireless configurations and applications. The auto carriage connection (ACC) feature provides simple deployment and increases the reliability of wireless carriage backbone networks. The AWK-3131-M12-RCC series is also optimized for passenger Wi-Fi services and complies with a portion of EN 50155 specifications, covering operating temperature, power input voltage, surge, ESD, and vibration, making the products suitable for a variety of industrial applications. The AWK-3131-M12-RCC series can also be powered via PoE for easier deployment.Improved Higher Data Rate and Bandwidth• High-speed wireless connectivity with up to 300 Mbps data rate • MIMO technology to improve the capability of transmitting and receiving multiple data streams• Increased channel width with channel bonding technologySpecifications for Industrial-Grade Applications• Industrial-grade QoS and VLAN for efficient data traffic management• Integrated DI/DO for on-site monitoring and warnings• Signal strength LEDs for easy deployment and antenna alignmentWLAN InterfaceStandards:IEEE 802.11a/b/g/n for Wireless LAN IEEE 802.11i for Wireless Security IEEE 802.3 for 10BaseTIEEE 802.3u for 100BaseT(X) IEEE 802.3ab for 1000BaseTIEEE 802.3af for Power-over-Ethernet IEEE 802.1D for Spanning Tree Protocol IEEE 802.1w for Rapid STP IEEE 802.1Q for VLANSpread Spectrum and Modulation (typical): • DSSS with DBPSK, DQPSK, CCK• OFDM with BPSK, QPSK, 16QAM, 64QAM• 802.11b: CCK @ 11/5.5 Mbps, DQPSK @ 2 Mbps, DBPSK @ 1 Mbps• 802.11a/g: 64QAM @ 54/48 Mbps, 16QAM @ 36/24 Mbps, QPSK @ 18/12 Mbps, BPSK @ 9/6 Mbpssupported)Operating Channels (central frequency): US:2.412 to 2.462 GHz (11 channels) 5.18 to 5.24 GHz (4 channels)EU:2.412 to 2.472 GHz (13 channels) 5.18 to 5.24 GHz (4 channels) JP:2.412 to 2.472 GHz (13 channels, OFDM) 2.412 to 2.484 GHz (14 channels, DSSS) 5.18 to 5.24 GHz (4 channels for W52)Security:• SSID broadcast enable/disable• Firewall for MAC/IP/Protocol/Port-based filtering• 64-bit and 128-bit WEP encryption, WPA/WPA2-Personal and Enterprise (IEEE 802.1X/RADIUS, TKIP, and AES)Transmission Rates:802.11b: 1, 2, 5.5, 11 Mbps802.11a/g: 6, 9, 12, 18, 24, 36, 48, 54 Mbps802.11n: 6.5 to 300 Mbps (multiple rates supported)TX Transmit Power: 802.11b:1 to 11 Mbps: Typ. 18 dBm (± 1.5 dBm) 802.11g:6 to 24 Mbps: Typ. 18 dBm (± 1.5 dBm) 36 to 48 Mbps: Typ. 17 dBm (± 1.5 dBm) 54 Mbps: Typ. 15 dBm (± 1.5 dBm)802.11a:6 to 24 Mbps: Typ. 17 dBm (± 1.5 dBm) 36 to 48 Mbps: Typ. 16 dBm (± 1.5 dBm) 54 Mbps: Typ. 14 dBm (± 1.5 dBm)TX Transmit Power MIMO (per connector): 802.11a/n (20/40 MHz):MCS15 20 MHz: Typ. 13 dBm (±1.5 dBm) MCS15 40 MHz: Typ. 12 dBm (±1.5 dBm) 802.11g/n (20 MHz):MCS15 20 MHz: Typ. 14 dBm (±1.5 dBm)RX Sensitivity: 802.11b:-92dBm@1Mbps,-90dBm@2Mbps,**************,-84dBm @ 11 Mbps 802.11g:-87 dBm @ 6 Mbps, -86 dBm @ 9 Mbps, -85 dBm @ 12 Mbps, -82 dBm @ 18 Mbps, -80 dBm @ 24 Mbps, -76 dBm @ 36 Mbps, -72 dBm @ 48 Mbps, -70 dBm @ 54 Mbps 802.11a:-87 dBm @ 6 Mbps, -86 dBm @ 9 Mbps, -85 dBm @ 12 Mbps, -82 dBm @ 18 Mbps,-80 dBm @ 24 Mbps, -76 dBm @ 36 Mbps, -72 dBm @ 48 Mbps, -70 dBm @ 54 MbpsRX Sensitivity MIMO: 802.11a/n:-68 dBm @ MCS15 40 MHz, -69 dBm @ MCS15 20 MHz, -70 dBm @ MCS7 40 MHz, -71 dBm @ MCS7 20 MHz 802.11g/n:-69 dBm @ MCS15 20 MHz, -71 dBm @ MCS7 20 MHzProtocol SupportGeneral Protocols: Proxy ARP, DNS, HTTP, HTTPS, IP, ICMP, SNTP, TCP, UDP, RADIUS, SNMP, PPPoE, DHCPAP-only Protocols: ARP, BOOTP, DHCP, STP/RSTP (IEEE 802.1D/w)InterfaceConnector for External Antennas: QMA (female)M12 Ports: 1, M12 A-coded 8-pin female connector,10/100/1000BaseT(X) auto negotiation speed, F/H duplex mode, auto MDI/MDI-X connectionConsole Port: RS-232 (RJ45-type)Reset: PresentLED Indicators: PWR1, PWR2, PoE, FAULT, STATE, signal strength, WLAN, LANAlarm Contact (digital output): 1 relay output with current carrying capacity of 1 A @ 24 VDCDigital Inputs: 2 electrically isolated inputs • +13 to +30 V for state “1” • +3 to -30 V for state “0” • Max. input current: 8 mAPhysical CharacteristicsHousing: Metal, IP30 protection Weight: 970 g (2.14 lb)Dimensions: 53 x 135 x 105 mm (2.08 x 5.31 x 4.13 in)Installation: DIN-rail mounting (standard), wall mounting (optional)Environmental LimitsOperating Temperature:Standard Models: -25 to 60°C (-13 to 140°F) Wide Temp. Models: -40 to 75°C (-40 to 167°F)Storage Temperature: -40 to 85°C (-40 to 185°F)Ambient Relative Humidity: 5% to 95% (non-condensing)Power RequirementsInput Voltage: 12 to 48 VDC, redundant dual DC power inputs or 48 VDC Power-over-Ethernet (IEEE 802.3af compliant)Input Current: 0.7 A @ 12 VDCConnector: 10-pin removable terminal block Reverse Polarity Protection: PresentStandards and CertificationsSafety: EN 60950-1(LVD), UL 60950-1, IEC 60950-1(CB)EMC: EN 55032/24EMI: CISPR 32, FCC Part 15B Class B EMS:IEC 61000-4-2 ESD: Contact: 8 kV; Air: 15 kV IEC 61000-4-3 RS: 80 MHz to 1 GHz: 20 V/m IEC 61000-4-4 EFT: Power: 2 kV; Signal: 2 kV IEC 61000-4-5 Surge: Power: 2 kV; Signal: 2 kV IEC 61000-4-6 CS: 10 V IEC 61000-4-8Radio:EU: EN 300 328, EN 301 893 US: FCC ID SLE-WAPN001 JP: TELECRail Traffic: EN 50155*, EN 50121-4, EN 45545-2*Complies with a portion of EN 50155 specifications.Note: Please check Moxa’s website for the most up-to-date certification status.MTBF (mean time between failures)Time: 407,416 hrsStandard: Telcordia SR332WarrantyWarranty Period: 5 yearsDetails: See /warrantyOrdering InformationOptional Accessories (can be purchased separately)WK-51-01: DIN-rail/wall-mounting kit, 2 plates with 6 screws。

JetNet 7612G 5612G交换机说明书

Interface IntroductionJetNet 7612G/5612G supports 8 ports Gigabit Ethernet RJ-45, and 4 ports swappable 100/1000 Ethernet SFP socket for fiber connection.Mounting the DIN RailThe DIN Rail clip on the rear of JetNet7612G/5612G,and supports35mm DIN rail.Power Details You can configure JetNet7612G/5612G Series via the RS-232console with the attached console cable.Or you can remotely manage the switch via network.You can choose Telnet/SSH,Web/HTTPS management. Preparation for console managementAttach the RS-232DB9connector to your PC’s COM port.Connect the RJ-45 connector to the console port of the JetNet Switch.1.Go to Start►Program►Accessories►Communication►Hyper Terminal2.Give a name to the new console connection.3.Choose the COM name and select the correct serial settings.The serial port settings are as below:Baud Rate:115200/Parity:None/Data Bit:8/Stop Bit:14.After connected,you will see the Switch login request.Type the username and password and then you can login.The default username is“admin”, password is“admin”.5.Follow the manual to configure the software features.Preparation for Web managementunch the web browser on the PC.2.Type http://JetNet Managed Switch_IP_Address(The default IP address is 192.168.10.1.),then press Enter.3.The login screen will appear next.Type in the user name and password and click“OK”button.The default user name and password is admin/admin.4.At the left column of the web management interface are the software features,where ring column will list the available settings.JetNet 7612G/7612GP/5612G/5612GPQuick Installation Guide V1.0 OverviewInstallationDevice Management Wiring the Power Inputs&Earth Grounding1.Insert the positive and negative wires into the V+and V-contact on theterminal block connector.2.Connect the ChassisGrounding to Earth Groundsystem to obtain electromagneticimmunity to resist lighting,electro static discharge andelectric fast transient.3.Tighten the wire-clamp screws to prevent the power wires from beingloosened.Notes:The recommended working voltage is listed in“Power Details”Wiring the Relay OutputThe relay output contacts arein the bottom side.The relayoutput(DO)is controlled bythe pre-defined operatingrules.To activate relay outputfunction,please refer to theUser’s Manual for more relayoutput management information.Notes:The relay contact only supports0.5A current,DC24V.It is notrecommended to apply voltage and current higher than the specifications.The JetNet 7612G/5612G Series is an pure Gigabit Managed Switchwith 8 ports Gigabit Ethernet plus , and 4 100/1000 SFP for opticalfiber connection It adopts high efficiency Ethernet MAC controllerwith 24Gbps Switch fabric bandwidth, 9K jumbo frame forwarding andpowerful capability. The robust system design makes the JetNet7612G/5612G Series survive under harsh outdoor environment withextreme electric magnetic interference and the variation of environmenttemperature. The hardware switching with high performance, lowlatency and security. It provides your network infrastructure with greatperformance and safety with network access control, and handle burstpacket with smart buffer management for IP surveillance in realinfrastructure.Package Check List❝JetNet7612G/7612GP/5612G/5612GP❝DIN Mounting kit❝DB-9to RJ-45(RS-232)Console Cable❝Quick Installation GuideWiring the Digital InputThe Digital Input(DI)contacts arein the bottom.It accepts one externalDC type signal input and can beconfigured to send alert messagethrough Ethernet when the signalis changed.The signal may triggerand generated by external powerswitch,like as door open trigger switch for control cabinet.Note:the DI accepts DC type signal and supports isolated input circuit with Digital High Level input DC11V~30V and Digital Low Level input DC 0V~10V.Do not apply voltage higher than the specification;it may cause internal circuit damage or a wrong action of DI.Connect to Network1.Connect the Ethernet Port:Connect the Ethernet port of JetNet7612G/5612G Series with the other Ethernet device by Cat-5/Cat-6 UTP or STP cable,and then the LNK/ACT LED will turn on and start flashing to indicate the communication is occurred between2device. 2.Connect the SFP Port:Plug in SFP fiber transceiver.We recommendusing Korenix certificated SFP mini GBIC transceiver.Cross-connect the transmit channel at each end to the receive channel at the opposite end.5Years WarrantyEach of Korenix’s product is designed,produced,and tested with high industrial standard.Korenix warrants that the product(s)shall be free from defects in materials and workmanship for a period of five(5)years from the date of delivery provided that the product was properly installed and used. This warranty is voided if defects,malfunctions or failures of the warranted product are caused by damage resulting from force measure(such as floods, fire,etc.),other external forces such as power disturbances,over spec power input,or incorrect cabling;or the warranted product is misused,abused,or operated,altered and repaired in an unauthorized or improper way. Attention!To avoid system damage caused by sparks,please DO NOT plug in power connector when power is on.The product is in compliance with Directive2002/95/EC and2011/65/EU of the European Parliament and of the Council of27January2003on the restriction of the use of certain hazardous substances in electrical and electronics equipment(RoHS Directives&RoHS2.0)Korenix Customer ServiceKorenixCARE is Korenix Technology’s global service center,where our professional staffs are ready to answer your questions at any time.Email address of Korenix Global Service Center:******************** Support界面介绍JetNet 7612G/5612G 系列支持8端口千兆以太网RJ-45及4个100/1000SFP 插口支持SFP 光收发器光纤传输。

工业级无线用户端 AWK-1137C 系列说明书

AWK-1137C系列工業級802.11a/b/g/n無線用戶端特色與優點•符合IEEE802.11a/b/g/n標準的用戶端•全方位介面，提供一個序列埠和兩個乙太網路LAN連接埠•毫秒等級的用戶端Turbo Roaming漫遊1•透過AeroMag輕鬆設定與布署•2x2MIMO未來技術•透過網路位址轉譯(NAT)輕鬆設定網路•整合耐用的天線和電源隔離能力•抗震動設計•小巧尺寸，適合您的工業應用認證簡介AWK-1137C是工業無線行動應用程式的理想用戶端解決方案。

此產品可為乙太網路和序列裝置提供無線區域網路連線，並符合工業標準和認證，涵蓋操作溫度、電源輸入電壓、突波、ESD及震動。

AWK-1137C可以在2.4或5GHz頻段上操作，並相容現有的802.11a/b/g布署。

MxView網路管理工具程式的無線附加元件能夠以視覺化的方式呈現AWK的無線連線，確保整體的Wi-Fi連線能力。

工業級耐用性•整合式天線和電源隔離設計可提供500V絕緣保護，防止外部電氣干擾•-40至75°C的寬廣操作溫度型號(-T)可在惡劣環境中提供順暢的無線通訊行動導向設計•基於用戶端的Turbo Roaming快速漫遊，2在AP間的漫遊復原時間<150毫秒•MIMO技術可確保在外出時的傳輸及接收能力•防震效能（參考IEC60068-2-6）輕鬆整合•半自動設定降低布署成本•AeroMag支援自動配對更新設定，可用於工業應用的基本無線區域網路初始設定•各種通訊介面，可連接不同類型的裝置•一對多NAT可簡化您的機器設定透過MXview Wireless進行無線網路管理•動態拓撲視圖一目了然顯示無線連結狀態及連線變化•視覺化的互動式漫遊播放功能，可檢閱用戶端的漫遊記錄•個別AP和用戶端裝置的詳細裝置資訊及效能指標圖表1.此處所指出的快速漫遊復原時間是在最佳化條件下記錄的平均測試結果，其中包含無干擾的20MHz RF頻道、WPA2-PSK安全性和預設快速漫遊參數。

莫萨MGate 5109系列1口Modbus RTU ASCII TCP-to-DNP3串行 TCP

MGate5109Series1-port Modbus RTU/ASCII/TCP-to-DNP3serial/TCP/UDP gatewaysFeatures and Benefits•Supports Modbus RTU/ASCII/TCP master/client and slave/server•Supports DNP3serial/TCP/UDP master and outstation(Level2)•DNP3master mode supports up to26600points•Supports time-synchronization through DNP3•Effortless configuration via web-based wizard•Built-in Ethernet cascading for easy wiring•Embedded traffic monitoring/diagnostic information for easy troubleshooting•microSD card for configuration backup/duplication and event logs•Status monitoring and fault protection for easy maintenance•Redundant dual DC power inputs and relay output•-40to75°C wide operating temperature models available•Serial port with2kV isolation protection•Security features based on IEC62443CertificationsIntroductionThe MGate5109is an industrial Ethernet gateway for Modbus RTU/ASCII/TCP and DNP3serial/TCP/UDP protocol conversion.All models are protected with a rugged metallic casing,are DIN-rail mountable,and offer built-in serial isolation.The MGate5109supports transparent mode to easily integrate Modbus TCP to Modbus RTU/ASCII networks or DNP3TCP/UDP to DNP3serial networks.The MGate5109also supports agent mode to exchange data between Modbus and DNP3networks or to act as a data concentrator for multiple Modbus slaves or multiple DNP3 outstations.The rugged design is suitable for industrial applications such as power,oil and gas,and water and wastewater.Easy Configuration via Web ConsoleThe MGate5109Series comes with an illustrated Quick Setup guide designed to make configuration easy.With Quick Setup,you can easily access protocol conversion modes and finish the configuration in a few steps.The MGate5109Series also supports Auto Detection for DNP3serial outstations,allowing the MGate5109to automatically acquire all outstation objects when configured as a DNP3master.Modbus and DNP3Protocol Traffic MonitorThe MGate5109gateways support Modbus and DNP3Protocol Traffic Monitor for easy troubleshooting,especially during the installation stage. Communication issues could be caused by incorrect software parameters,such as slave ID and register address,or incorrect command configuration.With Modbus/DNP3Protocol Traffic Monitor,you can check the captured data and easily identify the root cause.A Variety of Maintenance FunctionsThe MGate5109gateways provide a web console and Telnet console for remote maintenance.Encryption communication functions,including HTTPS and SSH,are supported to provide better network security.In addition,firmware log functions are provided to record connection events and Modbus maintenance ers can review log data remotely through the web console.SpecificationsEthernet Interface10/100BaseT(X)Ports(RJ45connector)2Auto MDI/MDI-X connectionMagnetic Isolation Protection 1.5kV(built-in)Ethernet Software FeaturesIndustrial Protocols Modbus TCP Client(Master),Modbus TCP Server(Slave),DNP3TCP Master,DNP3TCP OutstationConfiguration Options Web Console(HTTP/HTTPS),Device Search Utility(DSU),Telnet Console Management ARP,DHCP Client,DNS,HTTP,HTTPS,SMTP,SNMP Trap,SNMPv1/v2c/v3,TCP/IP,Telnet,SSH,UDP,NTP ClientMIB RFC1213,RFC1317Time Management NTP ClientSecurity FunctionsAuthentication Local databaseEncryption HTTPS,AES-128,AES-256,SHA-256Security Protocols SNMPv3SNMPv2c TrapHTTPS(TLS1.3)Serial InterfaceConsole Port RS-232(TxD,RxD,GND),8-pin RJ45(115200,n,8,1)No.of Ports1Connector DB9maleSerial Standards RS-232/422/485Baudrate50bps to921.6kbpsData Bits7,8Parity None,Even,Odd,Space,MarkStop Bits1,2Flow Control RTS Toggle(RS-232only),RTS/CTSRS-485Data Direction Control ADDC®(automatic data direction control)Pull High/Low Resistor for RS-4851kilo-ohm,150kilo-ohmsTerminator for RS-485120ohmsIsolation2kV(built-in)Serial SignalsRS-232TxD,RxD,RTS,CTS,DTR,DSR,DCD,GNDRS-422Tx+,Tx-,Rx+,Rx-,GNDRS-485-2w Data+,Data-,GNDRS-485-4w Tx+,Tx-,Rx+,Rx-,GNDSerial Software FeaturesConfiguration Options Serial ConsoleIndustrial Protocols Modbus RTU/ASCII Master,Modbus RTU/ASCII Slave,DNP3Serial Master,DNP3SerialOutstationModbus RTU/ASCIIMode Master,SlaveFunctions Supported1,2,3,4,5,6,15,16,23 Max.No.of Commands100Modbus TCPFunctions Supported1,2,3,4,5,6,15,16,23 Mode Client(Master),Server(Slave) Max.No.of Client Connections16Max.No.of Server Connections32Max.No.of Commands100DNP3(Transparent)Max.No.of Master Connections16Max.No.of Outstation Connections32DNP3SerialMode Master,OutstationMax.No.of Master Connections1Max.No.of Outstation Connections31Internal Master Database(each Master)Binary Inputs:8192pointsAnalog Inputs:2048pointsCounters:2048pointsBinary Outputs:8192pointsAnalog Outputs:2048points Internal Outstation Database Binary Inputs:8192pointsAnalog Inputs:2048pointsCounters:2048pointsBinary Outputs:8192pointsAnalog Outputs:2048pointsBinary Input Events:1024Analog Input Events:1024Counter Events:1024DNP3TCP/UDPMode Master,OutstationMax.No.of Master Connections1Max.No.of Outstation Connections32Internal Master Database(each Master)Binary Inputs:8192pointsAnalog Inputs:2048pointsCounters:2048pointsBinary Outputs:8192pointsAnalog Outputs:2048points Internal Outstation Database Binary Inputs:8192pointsAnalog Inputs:2048pointsCounters:2048pointsBinary Outputs:8192pointsAnalog Outputs:2048pointsBinary Input Events:1024Analog Input Events:1024Counter Events:1024MemorymicroSD Slot Up to32GB(SD2.0compatible)Power ParametersInput Voltage12to48VDCInput Current455mA@12VDCPower Connector Screw-fastened Euroblock terminalRelaysContact Current Rating Resistive load:2A@30VDCPhysical CharacteristicsHousing MetalIP Rating IP30Dimensions36x105x140mm(1.42x4.14x5.51in)Weight507g(1.12lb)Environmental LimitsOperating Temperature MGate5109:0to60°C(32to140°F)MGate5109-T:-40to75°C(-40to167°F)Storage Temperature(package included)-40to85°C(-40to185°F)Ambient Relative Humidity5to95%(non-condensing)Standards and CertificationsSafety EN60950-1,UL508EMC EN55032/24EMI CISPR32,FCC Part15B Class BEMS IEC61000-4-2ESD:Contact:8kV;Air:15kVIEC61000-4-3RS:80MHz to1GHz:10V/mIEC61000-4-4EFT:Power:4kV;Signal:2kVIEC61000-4-5Surge:Power:2kV;Signal:2kVIEC61000-4-6CS:150kHz to80MHz:10V/m;Signal:10V/mIEC61000-4-8PFMFHazardous Locations ATEX,Class I Division2,IECExFreefall IEC60068-2-32Shock IEC60068-2-27Vibration IEC60068-2-6,IEC60068-2-64MTBFTime888,926hrsStandards Telcordia SR332WarrantyWarranty Period5yearsDetails See /warrantyPackage ContentsDevice1x MGate5109Series gatewayCable1x RJ45-to-DB9console cableInstallation Kit1x DIN-rail kitDocumentation1x quick installation guide1x warranty cardDimensionsOrdering InformationModel Name Operating Temp. MGate51090to60°C MGate5109-T-40to75°C Accessories(sold separately)CablesCBL-F9M9-150DB9female to DB9male serial cable,1.5mCBL-F9M9-20DB9female to DB9male serial cable,20cmCBL-RJ45F9-1508-pin RJ45to DB9female serial cable,1.5mCBL-RJ45SF9-1508-pin RJ45to DB9female serial cable with shielding,1.5mConnectorsMini DB9F-to-TB DB9female to terminal block connectorPower CordsCBL-PJTB-10Non-locking barrel plug to bare-wire cableMounting KitsDK-25-01DIN-rail mounting kit,2screwsWK-36-02DIN-rail/wall-mounting kit,2plates,6screws©Moxa Inc.All rights reserved.Updated Feb08,2022.This document and any portion thereof may not be reproduced or used in any manner whatsoever without the express written permission of Moxa Inc.Product specifications subject to change without notice.Visit our website for the most up-to-date product information.。

1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。

protocol, devised in [2]. In the multihop scheme, the source and a group of relays that have already decoded the source message replicate and cooperatively transmit the source message to the next relay. This process is repeated until all relays decode the source message and cooperatively transmit the source message to the destination. The decoding procedures at the receivers take into account that the message is transmitted over several blocks. It has been proved that multihopping along with optimal decoding is capacity achieving for the generalized multirelay version of the single-relay degraded channel [2]. This paper shows that the multihop protocol can be further improved. The main bottleneck of the multihop relaying strategy is that all relay terminals must decode the source message in order to participate in the relaying protocol. This can be restrictive, because the source rate is constrained by the decodability conditions at those relays with poor links from the source. However, it is not necessary to require all relays to decode the source message. The multihop DF rate is improved if relays are allowed to choose an appropriate set of messages to decode. This set of messages may include not only the source message, but also messages from other relays. This ﬂexibility can signiﬁcantly improve the DF rate. In this paper, a class of DF protocols, named parity forwarding, is proposed to improve the DF rate for the multirelay network. In parity forwarding, the source and the relays may transmit multiple messages. Relays decode a selection of messages transmitted by other nodes, called the decoding set. The messages sent by relays are bin indices containing partial information for the messages in the decoding set. A key feature of the parity forwarding protocol as compared to the multihop protocol is that the relay messages partially describe the decoded data at the relays, rather than fully replicate the decoded data. To decode a message, the decoders (i.e., the ﬁnal destination or intermediate relays) identify all messages that contain partial information about the message to be decoded, and perform joint decoding by combining all partial information. For a given multirelay network, several parity forwarding protocols are possible, depending on the messages decoded or transmitted by the relays. This paper characterizes a class of parity forwarding protocols in an structured way via a message tree. The message tree characterizes the dependencies between messages in the network. Using this tree structure,
X0
Fig. 1. A general network with multiple relays A relay network consists of a pair of source and destination terminals and a number of relays. The relays have no message of their own and only help the source communicate to the destination. Fig. 1 shows a schematic of a network with K relays in which the relays are numbered from 1 to K , the source is represented by index 0, and the destination is represented by index K +1. The random variables X0 , X1 , . . . , XK represent the transmitted signals, and Y1 , Y2 , . . . , YK +1 represent the received signals, at respective nodes. The channel is assumed to be memoryless and is deﬁned by the joint probability distribution function (pdf) p(y1 , y2 , . . . , yK +1 |x0 , x1 , . . . , xK ). Although the capacity of the simple yet fundamental singlerelay network introduced by Van der Meulen in [1] is still open, the recent surge of interests in relay networks has resulted in new communication protocols and achievable rates for multirelay networks [2]–[7]. Among the various relaying strategies, the classical decode-and-forward (DF) strategy, proposed by Cover and El Gamal [8], has been of particular interest. In the DF scheme for the single-relay channel, the relay decodes the source message and forwards a bin index for it to the destination. This fundamental relaying strategy is proved to be capacity achieving for a degraded single-relay network [8, Theorem 1]. Generalizations of the single-relay DF scheme to the multirelay case have been studied in [2]–[6], [9]. The best known DF strategy for multirelay networks is called the multihop
Abstract— This paper proposes a relaying strategy for the multiple-relay network in which each relay decodes a selection of transmitted messages by other transmitting terminals, and forwards parities of the decoded codewords. This protocol improves the previously known achievable rate of the decode-andforward (DF) strategy for multirelay networks by allowing relays to decode only a selection of messages from relays with strong links to it. Hence, each relay may have several choices as to which messages to decode, and for a given network many different parity forwarding protocols may exist. A tree structure is devised to characterize a class of parity forwarding protocols for an arbitrary multirelay network. Based on this tree structure, closedform expressions for the achievable rates of these DF schemes are derived. It is shown that parity forwarding is capacity achieving for new forms of degraded relay networks.