Parity Forwarding for Multiple-Relay Networks

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 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-nificant fraction of total system power.It is exactly this gap that the work presented in this paper aims tofill.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 specification 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 efficient 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 traffic 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 significant 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 InfiniBand 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 efficiency 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-efficient 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 itsflexibility. 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-efficient hardware and compiler techniques for emerging intercon-nected processors.In Section2,wefirst 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 specific microarchitecture;to see the impact application traffic 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 unified structural machine description and specification 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.Itsflexibility 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-defined 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 define 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 specific 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 registerfiles,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 thatflow 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 modifies 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 configuration specified 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 InfiniBand 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 configured functional and tim-ing behavior.3Power modelingWe derive architectural-level parameterized power mod-els for several of the major building blocks identified in Sec-tion2,namely FIFO buffers,crossbars and arbiters.These components occupy about90%of the area of the Alpha 21364router[1],and are sufficient 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 defined,and is implicitly defined when component capacitance is defined.For each component,wefirst 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 registerfiles[9,28], incorporating several features specific 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 reflect the impact of varying activity in a powerTable2.Model for FIFO buffersCanonical structureArchitectural parametersbuffer size inflitsflit 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 significant 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 theflip-flop sub-component models from our arbiter model for the pipeline registers.The two crossbars are modeled with our crossbar power model.Through a well-defined 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 InfiniBand8-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-cific 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 flit 4through the router,showing how its power consumption is estimated.We assume the router has 5input/output ports,with 4flit buffers per input port and each flit 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 flit into the write port of the input buffer module Buf I .The buffer module writes the flit 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 flit 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 config 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 flit is then read,emitting a buffer read event,which causes thebuffer power model to compute buffer read energy.The flit 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 flit leaves the router,enters the in port of the4Aflit is the smallest unit of flow control,and is a fixed-sized unit of a packet.5We assume a flit does not u-turn and leave through the same head flit 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 flit 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 configura-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 configurations.Given a representative communication workload of the targeted ap-plication,the user can feed the workload and configurations 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 traffic patterns on a specific 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 defining 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 modified 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 five physical bidi-rectional ports (north,south,east,west,injection/ejection)performance>performance> (a)Exploring differentconfigurations 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-basedflow control reg-ulates the use of buffers,i.e.,a credit is sent back to theprevious router whenever aflit leaves,so a router can main-tain a count of the number of available buffers,and noflitsare 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 traffic 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 thefirstflit of the packet is created,to when itslastflit is ejected at the destination node,including sourcequeuing time and assuming immediate ejection.The sat-uration throughput of a network is defined 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-flit long,consisting of a headflit leading4dataflits.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 thefirst1000cycles.Aver-6Dimension-ordered routing is where a packet always goes along onedimensionfirst,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 configurations:wormholevs.virtual-channel routersWe assume an on-chip network similar to that in[7],i.e.a44torus network on a12mm12mm chip with256-bitflits,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 configu-rations:-wormhole router with64-flit input buffer per port(WH64).virtual-channel(VC)router with2VCs per port and8-flit input buffer per VC(VC16).virtual-channel router with8VCs per port and8-flitinput buffer per VC(VC64).virtual-channel router with8VCs per port and16-flitinput buffer per VC(VC128).As prescribed by[15],these virtual-channel routersfitwithin 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 flow 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 configurations,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 flow 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 significant.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 flow 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 flow control returning better power-performance than wormhole.Since buffer power is significant,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 configuration,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 configurations of a network microarchitecture.4.3Exploring different workloads:broadcast vs.uniform trafficJust 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 traffic,i.e.each node injects packets to randomly distributed destinations other than itself in the network.broadcast traffic,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 traffic,the source node at position (1,2)injects at the maximum rate of 0.2packets per cycle.For uniform ran-dom traffic,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 fixed across the workloads as a 44torus.We also fix the router microarchitecture –virtual-channel routers with 2VCs per port and 8flit buffers per VC.Other aspects of the network microarchitecture remain the same as configured 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 traffic pat-terns.Uniform random traffic results in a rather flat power。

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 网桥。

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。

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系列工業級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安全性和預設快速漫遊參數。

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.。

RELAY CONTROLLER’S MANUALRELAY CONTROLLERRELAY CONTROLLER by Milestone is a device that helps person/s to control various electric appliances sitting at one place through remote keypad or local keypad or RS 232 interface.Models Available:ML 4 RL 4 Relay ControlML 8 RL 8 Relay ControlFeatures:Installation Easy to Install 100% Plug and Play UnitCompatibility Can switch 230 V 8 Amp. DevicesSelection Individual Relay controlled throughIndividual Local keypadIndividual remote keypad (optional).Remote contact closure.RS232C interface.RS422/RS485 interface (optional).IR / RF Remote Keypad (optional).Indication LED Indication for working channel Unit IdentityCode2 Bit DIP Switch (For RS-232 only)Exclusive Relay Operation 4 Pairs of Relays through DIP Switch Setting (When one of the pair is ON other will be OFF and vice versa).Multiple Unit Operation Using Unit Identifier, up to 32 Relays can be operated (ML-8RL X 4) through single RS232C Controller.Battery Backup Last selected status stored in battery-backed memory. Isolation RS-232C & relays are optically isolated.1Specifications:Model ML 4 RL ML8 RL Nos. Of Relay 4 8 Input Power1 1 Terminal Block 230 V 60 AmpOut Put – 3 Pin Captive Screw2 4230V, 8A (L, N, E)Output – 4 Pin Captive Screw2 4230V, 8A, (F, L, N, E)LED Indication 1-4 & Power 1-8 & Power Key Pad Selection 1-4 1-8Remote Keypad / Contact ClosureD9M x 1 D9M x 1 ConnectorManual / RS232 Select switch Yes YesRS-232 Interface D9F x 1 D9F x 1 DIP Switch Settings 8 Bits 8 Bits Unit Identifier Code 2 Bits 2 Bits Exclusive Relay Mode 4 Bits 4 Bits Mains Input (AC.) 230 V 230 V Dimension (Table Top) 288x130x52 288x130x68 Dimension (Rack 19”) 1U 1U Weight 1770g 2000g2DIP Switch Selection:A. Normal / Exclusive Mode Selection:DIP SWITCH POSITION OPERATION1. OFFONRelay 1 & 2 NormalMode OperationRelay 1 & 2 ExclusiveMode Operation2. OFFONRelay 3 & 4 NormalMode OperationRelay 3 & 4 ExclusiveMode Operation3. OFFONRelay 5 & 6 NormalMode OperationRelay 5 & 6 ExclusiveMode Operation4. OFFONRelay 7 & 8 NormalMode OperationRelay 7 & 8 ExclusiveMode OperationNormal Mode Operation: - Relay 1 and Relay 2 works as Independent Relays Exclusive Mode Operation: - If Relay 1 is ON; Relay 2 will remain OFF and vice versa.Always works in pair.Operation in Exclusive Mode for Relay 1& 2.1) Keep the dip Switch 1 to ON position.2) Use Relay 1 connector ‘4 Pin Captive Screw’ for motor.(Do not use Relay 2 Connector if motor used.)3) Connect common of motor to N.Connect Forward wire to FConnect Reverse wire to LConnect Earth to E3) Press Key’1’ for reverse motor drive and press Key’2’ for forward motor drive• Similarly for Relay 3 & 4, 5 & 6, 7 & 8.• For operation in normal mode. Do not use F of Relay 1, Relay 3, Relay 5, Relay7.3B. Unit Identity Code Selection (Only for RS-232C Command)DIP SWITCH 5 DIP SWITCH 6 UNIT IDENTIFIERCODEOFF OFF !OFF ON #ON OFF @ON ON $OPERATION:At Power ON, all the relay status remains as per last selected when powered OFF (using battery backed memory feature)A. Manual Mode:Keep the select switch on rear panel to NORMAL Mode.• Local Keypad:Controls the required output from the front panel keypad. Pressing the individual keypad will toggle the respective relay output (ON or OFF)Note: Pressing any key for more than 2 seconds will OFF all the relays.• Remote Contact Closure / Remote Keypad:Rear Panel has a D9 Male Connector to connect Milestone’s remote keypad oray other remote contact closure that can be operated from a distance from 50meters.The connector diagram for D9 male connector is as follows:D-9 Male Relay Driver1 12 2: :: :8 89 Common groundNote: Particular relay can be operated by shorting respective pin-to-pin 9 through contact switch or by using Milestone’s remote keypad.4B. Remote RS232 interfaceKeep the select rear panel to RS 232 Mode. D9 female connector from rear panel is used for selecting the relay drive through RS232C Interface.The pin configurations are:D-9 Female Signals3 RX5 GRDThe simple commands used for selecting the relays are:RELAYDecimal(Set by DIP switch 5 & 6)ASCI I1 ON 1! or 1@ or 1# or 1$ 31, 212 ON 2! or 2@ or 2# or 2$ 32, 21: : :08 ON 8! or 8@ or 8# or 8$ 38, 211 OFF a! or a@ or a# or a$ 61, 21: : :8 OFF h! or h@ or h# or h$ 68, 21All OFF 0! or 0@ or 0# or 0$ 30, 21 Communication parameters are 9600 baud, 8-bit, 1 stop bit and no parity.∴∴∴∴∴∴5。

3GPP TS 36.331 V13.2.0 (2016-06)Technical Specification3rd Generation Partnership Project;Technical Specification Group Radio Access Network;Evolved Universal Terrestrial Radio Access (E-UTRA);Radio Resource Control (RRC);Protocol specification(Release 13)The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP. The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented.This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this Specification. Specifications and reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices.KeywordsUMTS, radio3GPPPostal address3GPP support office address650 Route des Lucioles - Sophia AntipolisValbonne - FRANCETel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16InternetCopyright NotificationNo part may be reproduced except as authorized by written permission.The copyright and the foregoing restriction extend to reproduction in all media.© 2016, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC).All rights reserved.UMTS™ is a Trade Mark of ETSI registered for the benefit of its members3GPP™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational PartnersLTE™ is a Trade Mark of ETSI currently being registered for the benefit of its Members and of the 3GPP Organizational Partners GSM® and the GSM logo are registered and owned by the GSM AssociationBluetooth® is a Trade Mark of the Bluetooth SIG registered for the benefit of its membersContentsForeword (18)1Scope (19)2References (19)3Definitions, symbols and abbreviations (22)3.1Definitions (22)3.2Abbreviations (24)4General (27)4.1Introduction (27)4.2Architecture (28)4.2.1UE states and state transitions including inter RAT (28)4.2.2Signalling radio bearers (29)4.3Services (30)4.3.1Services provided to upper layers (30)4.3.2Services expected from lower layers (30)4.4Functions (30)5Procedures (32)5.1General (32)5.1.1Introduction (32)5.1.2General requirements (32)5.2System information (33)5.2.1Introduction (33)5.2.1.1General (33)5.2.1.2Scheduling (34)5.2.1.2a Scheduling for NB-IoT (34)5.2.1.3System information validity and notification of changes (35)5.2.1.4Indication of ETWS notification (36)5.2.1.5Indication of CMAS notification (37)5.2.1.6Notification of EAB parameters change (37)5.2.1.7Access Barring parameters change in NB-IoT (37)5.2.2System information acquisition (38)5.2.2.1General (38)5.2.2.2Initiation (38)5.2.2.3System information required by the UE (38)5.2.2.4System information acquisition by the UE (39)5.2.2.5Essential system information missing (42)5.2.2.6Actions upon reception of the MasterInformationBlock message (42)5.2.2.7Actions upon reception of the SystemInformationBlockType1 message (42)5.2.2.8Actions upon reception of SystemInformation messages (44)5.2.2.9Actions upon reception of SystemInformationBlockType2 (44)5.2.2.10Actions upon reception of SystemInformationBlockType3 (45)5.2.2.11Actions upon reception of SystemInformationBlockType4 (45)5.2.2.12Actions upon reception of SystemInformationBlockType5 (45)5.2.2.13Actions upon reception of SystemInformationBlockType6 (45)5.2.2.14Actions upon reception of SystemInformationBlockType7 (45)5.2.2.15Actions upon reception of SystemInformationBlockType8 (45)5.2.2.16Actions upon reception of SystemInformationBlockType9 (46)5.2.2.17Actions upon reception of SystemInformationBlockType10 (46)5.2.2.18Actions upon reception of SystemInformationBlockType11 (46)5.2.2.19Actions upon reception of SystemInformationBlockType12 (47)5.2.2.20Actions upon reception of SystemInformationBlockType13 (48)5.2.2.21Actions upon reception of SystemInformationBlockType14 (48)5.2.2.22Actions upon reception of SystemInformationBlockType15 (48)5.2.2.23Actions upon reception of SystemInformationBlockType16 (48)5.2.2.24Actions upon reception of SystemInformationBlockType17 (48)5.2.2.25Actions upon reception of SystemInformationBlockType18 (48)5.2.2.26Actions upon reception of SystemInformationBlockType19 (49)5.2.3Acquisition of an SI message (49)5.2.3a Acquisition of an SI message by BL UE or UE in CE or a NB-IoT UE (50)5.3Connection control (50)5.3.1Introduction (50)5.3.1.1RRC connection control (50)5.3.1.2Security (52)5.3.1.2a RN security (53)5.3.1.3Connected mode mobility (53)5.3.1.4Connection control in NB-IoT (54)5.3.2Paging (55)5.3.2.1General (55)5.3.2.2Initiation (55)5.3.2.3Reception of the Paging message by the UE (55)5.3.3RRC connection establishment (56)5.3.3.1General (56)5.3.3.1a Conditions for establishing RRC Connection for sidelink communication/ discovery (58)5.3.3.2Initiation (59)5.3.3.3Actions related to transmission of RRCConnectionRequest message (63)5.3.3.3a Actions related to transmission of RRCConnectionResumeRequest message (64)5.3.3.4Reception of the RRCConnectionSetup by the UE (64)5.3.3.4a Reception of the RRCConnectionResume by the UE (66)5.3.3.5Cell re-selection while T300, T302, T303, T305, T306, or T308 is running (68)5.3.3.6T300 expiry (68)5.3.3.7T302, T303, T305, T306, or T308 expiry or stop (69)5.3.3.8Reception of the RRCConnectionReject by the UE (70)5.3.3.9Abortion of RRC connection establishment (71)5.3.3.10Handling of SSAC related parameters (71)5.3.3.11Access barring check (72)5.3.3.12EAB check (73)5.3.3.13Access barring check for ACDC (73)5.3.3.14Access Barring check for NB-IoT (74)5.3.4Initial security activation (75)5.3.4.1General (75)5.3.4.2Initiation (76)5.3.4.3Reception of the SecurityModeCommand by the UE (76)5.3.5RRC connection reconfiguration (77)5.3.5.1General (77)5.3.5.2Initiation (77)5.3.5.3Reception of an RRCConnectionReconfiguration not including the mobilityControlInfo by theUE (77)5.3.5.4Reception of an RRCConnectionReconfiguration including the mobilityControlInfo by the UE(handover) (79)5.3.5.5Reconfiguration failure (83)5.3.5.6T304 expiry (handover failure) (83)5.3.5.7Void (84)5.3.5.7a T307 expiry (SCG change failure) (84)5.3.5.8Radio Configuration involving full configuration option (84)5.3.6Counter check (86)5.3.6.1General (86)5.3.6.2Initiation (86)5.3.6.3Reception of the CounterCheck message by the UE (86)5.3.7RRC connection re-establishment (87)5.3.7.1General (87)5.3.7.2Initiation (87)5.3.7.3Actions following cell selection while T311 is running (88)5.3.7.4Actions related to transmission of RRCConnectionReestablishmentRequest message (89)5.3.7.5Reception of the RRCConnectionReestablishment by the UE (89)5.3.7.6T311 expiry (91)5.3.7.7T301 expiry or selected cell no longer suitable (91)5.3.7.8Reception of RRCConnectionReestablishmentReject by the UE (91)5.3.8RRC connection release (92)5.3.8.1General (92)5.3.8.2Initiation (92)5.3.8.3Reception of the RRCConnectionRelease by the UE (92)5.3.8.4T320 expiry (93)5.3.9RRC connection release requested by upper layers (93)5.3.9.1General (93)5.3.9.2Initiation (93)5.3.10Radio resource configuration (93)5.3.10.0General (93)5.3.10.1SRB addition/ modification (94)5.3.10.2DRB release (95)5.3.10.3DRB addition/ modification (95)5.3.10.3a1DC specific DRB addition or reconfiguration (96)5.3.10.3a2LWA specific DRB addition or reconfiguration (98)5.3.10.3a3LWIP specific DRB addition or reconfiguration (98)5.3.10.3a SCell release (99)5.3.10.3b SCell addition/ modification (99)5.3.10.3c PSCell addition or modification (99)5.3.10.4MAC main reconfiguration (99)5.3.10.5Semi-persistent scheduling reconfiguration (100)5.3.10.6Physical channel reconfiguration (100)5.3.10.7Radio Link Failure Timers and Constants reconfiguration (101)5.3.10.8Time domain measurement resource restriction for serving cell (101)5.3.10.9Other configuration (102)5.3.10.10SCG reconfiguration (103)5.3.10.11SCG dedicated resource configuration (104)5.3.10.12Reconfiguration SCG or split DRB by drb-ToAddModList (105)5.3.10.13Neighbour cell information reconfiguration (105)5.3.10.14Void (105)5.3.10.15Sidelink dedicated configuration (105)5.3.10.16T370 expiry (106)5.3.11Radio link failure related actions (107)5.3.11.1Detection of physical layer problems in RRC_CONNECTED (107)5.3.11.2Recovery of physical layer problems (107)5.3.11.3Detection of radio link failure (107)5.3.12UE actions upon leaving RRC_CONNECTED (109)5.3.13UE actions upon PUCCH/ SRS release request (110)5.3.14Proximity indication (110)5.3.14.1General (110)5.3.14.2Initiation (111)5.3.14.3Actions related to transmission of ProximityIndication message (111)5.3.15Void (111)5.4Inter-RAT mobility (111)5.4.1Introduction (111)5.4.2Handover to E-UTRA (112)5.4.2.1General (112)5.4.2.2Initiation (112)5.4.2.3Reception of the RRCConnectionReconfiguration by the UE (112)5.4.2.4Reconfiguration failure (114)5.4.2.5T304 expiry (handover to E-UTRA failure) (114)5.4.3Mobility from E-UTRA (114)5.4.3.1General (114)5.4.3.2Initiation (115)5.4.3.3Reception of the MobilityFromEUTRACommand by the UE (115)5.4.3.4Successful completion of the mobility from E-UTRA (116)5.4.3.5Mobility from E-UTRA failure (117)5.4.4Handover from E-UTRA preparation request (CDMA2000) (117)5.4.4.1General (117)5.4.4.2Initiation (118)5.4.4.3Reception of the HandoverFromEUTRAPreparationRequest by the UE (118)5.4.5UL handover preparation transfer (CDMA2000) (118)5.4.5.1General (118)5.4.5.2Initiation (118)5.4.5.3Actions related to transmission of the ULHandoverPreparationTransfer message (119)5.4.5.4Failure to deliver the ULHandoverPreparationTransfer message (119)5.4.6Inter-RAT cell change order to E-UTRAN (119)5.4.6.1General (119)5.4.6.2Initiation (119)5.4.6.3UE fails to complete an inter-RAT cell change order (119)5.5Measurements (120)5.5.1Introduction (120)5.5.2Measurement configuration (121)5.5.2.1General (121)5.5.2.2Measurement identity removal (122)5.5.2.2a Measurement identity autonomous removal (122)5.5.2.3Measurement identity addition/ modification (123)5.5.2.4Measurement object removal (124)5.5.2.5Measurement object addition/ modification (124)5.5.2.6Reporting configuration removal (126)5.5.2.7Reporting configuration addition/ modification (127)5.5.2.8Quantity configuration (127)5.5.2.9Measurement gap configuration (127)5.5.2.10Discovery signals measurement timing configuration (128)5.5.2.11RSSI measurement timing configuration (128)5.5.3Performing measurements (128)5.5.3.1General (128)5.5.3.2Layer 3 filtering (131)5.5.4Measurement report triggering (131)5.5.4.1General (131)5.5.4.2Event A1 (Serving becomes better than threshold) (135)5.5.4.3Event A2 (Serving becomes worse than threshold) (136)5.5.4.4Event A3 (Neighbour becomes offset better than PCell/ PSCell) (136)5.5.4.5Event A4 (Neighbour becomes better than threshold) (137)5.5.4.6Event A5 (PCell/ PSCell becomes worse than threshold1 and neighbour becomes better thanthreshold2) (138)5.5.4.6a Event A6 (Neighbour becomes offset better than SCell) (139)5.5.4.7Event B1 (Inter RAT neighbour becomes better than threshold) (139)5.5.4.8Event B2 (PCell becomes worse than threshold1 and inter RAT neighbour becomes better thanthreshold2) (140)5.5.4.9Event C1 (CSI-RS resource becomes better than threshold) (141)5.5.4.10Event C2 (CSI-RS resource becomes offset better than reference CSI-RS resource) (141)5.5.4.11Event W1 (WLAN becomes better than a threshold) (142)5.5.4.12Event W2 (All WLAN inside WLAN mobility set becomes worse than threshold1 and a WLANoutside WLAN mobility set becomes better than threshold2) (142)5.5.4.13Event W3 (All WLAN inside WLAN mobility set becomes worse than a threshold) (143)5.5.5Measurement reporting (144)5.5.6Measurement related actions (148)5.5.6.1Actions upon handover and re-establishment (148)5.5.6.2Speed dependant scaling of measurement related parameters (149)5.5.7Inter-frequency RSTD measurement indication (149)5.5.7.1General (149)5.5.7.2Initiation (150)5.5.7.3Actions related to transmission of InterFreqRSTDMeasurementIndication message (150)5.6Other (150)5.6.0General (150)5.6.1DL information transfer (151)5.6.1.1General (151)5.6.1.2Initiation (151)5.6.1.3Reception of the DLInformationTransfer by the UE (151)5.6.2UL information transfer (151)5.6.2.1General (151)5.6.2.2Initiation (151)5.6.2.3Actions related to transmission of ULInformationTransfer message (152)5.6.2.4Failure to deliver ULInformationTransfer message (152)5.6.3UE capability transfer (152)5.6.3.1General (152)5.6.3.2Initiation (153)5.6.3.3Reception of the UECapabilityEnquiry by the UE (153)5.6.4CSFB to 1x Parameter transfer (157)5.6.4.1General (157)5.6.4.2Initiation (157)5.6.4.3Actions related to transmission of CSFBParametersRequestCDMA2000 message (157)5.6.4.4Reception of the CSFBParametersResponseCDMA2000 message (157)5.6.5UE Information (158)5.6.5.1General (158)5.6.5.2Initiation (158)5.6.5.3Reception of the UEInformationRequest message (158)5.6.6 Logged Measurement Configuration (159)5.6.6.1General (159)5.6.6.2Initiation (160)5.6.6.3Reception of the LoggedMeasurementConfiguration by the UE (160)5.6.6.4T330 expiry (160)5.6.7 Release of Logged Measurement Configuration (160)5.6.7.1General (160)5.6.7.2Initiation (160)5.6.8 Measurements logging (161)5.6.8.1General (161)5.6.8.2Initiation (161)5.6.9In-device coexistence indication (163)5.6.9.1General (163)5.6.9.2Initiation (164)5.6.9.3Actions related to transmission of InDeviceCoexIndication message (164)5.6.10UE Assistance Information (165)5.6.10.1General (165)5.6.10.2Initiation (166)5.6.10.3Actions related to transmission of UEAssistanceInformation message (166)5.6.11 Mobility history information (166)5.6.11.1General (166)5.6.11.2Initiation (166)5.6.12RAN-assisted WLAN interworking (167)5.6.12.1General (167)5.6.12.2Dedicated WLAN offload configuration (167)5.6.12.3WLAN offload RAN evaluation (167)5.6.12.4T350 expiry or stop (167)5.6.12.5Cell selection/ re-selection while T350 is running (168)5.6.13SCG failure information (168)5.6.13.1General (168)5.6.13.2Initiation (168)5.6.13.3Actions related to transmission of SCGFailureInformation message (168)5.6.14LTE-WLAN Aggregation (169)5.6.14.1Introduction (169)5.6.14.2Reception of LWA configuration (169)5.6.14.3Release of LWA configuration (170)5.6.15WLAN connection management (170)5.6.15.1Introduction (170)5.6.15.2WLAN connection status reporting (170)5.6.15.2.1General (170)5.6.15.2.2Initiation (171)5.6.15.2.3Actions related to transmission of WLANConnectionStatusReport message (171)5.6.15.3T351 Expiry (WLAN connection attempt timeout) (171)5.6.15.4WLAN status monitoring (171)5.6.16RAN controlled LTE-WLAN interworking (172)5.6.16.1General (172)5.6.16.2WLAN traffic steering command (172)5.6.17LTE-WLAN aggregation with IPsec tunnel (173)5.6.17.1General (173)5.7Generic error handling (174)5.7.1General (174)5.7.2ASN.1 violation or encoding error (174)5.7.3Field set to a not comprehended value (174)5.7.4Mandatory field missing (174)5.7.5Not comprehended field (176)5.8MBMS (176)5.8.1Introduction (176)5.8.1.1General (176)5.8.1.2Scheduling (176)5.8.1.3MCCH information validity and notification of changes (176)5.8.2MCCH information acquisition (178)5.8.2.1General (178)5.8.2.2Initiation (178)5.8.2.3MCCH information acquisition by the UE (178)5.8.2.4Actions upon reception of the MBSFNAreaConfiguration message (178)5.8.2.5Actions upon reception of the MBMSCountingRequest message (179)5.8.3MBMS PTM radio bearer configuration (179)5.8.3.1General (179)5.8.3.2Initiation (179)5.8.3.3MRB establishment (179)5.8.3.4MRB release (179)5.8.4MBMS Counting Procedure (179)5.8.4.1General (179)5.8.4.2Initiation (180)5.8.4.3Reception of the MBMSCountingRequest message by the UE (180)5.8.5MBMS interest indication (181)5.8.5.1General (181)5.8.5.2Initiation (181)5.8.5.3Determine MBMS frequencies of interest (182)5.8.5.4Actions related to transmission of MBMSInterestIndication message (183)5.8a SC-PTM (183)5.8a.1Introduction (183)5.8a.1.1General (183)5.8a.1.2SC-MCCH scheduling (183)5.8a.1.3SC-MCCH information validity and notification of changes (183)5.8a.1.4Procedures (184)5.8a.2SC-MCCH information acquisition (184)5.8a.2.1General (184)5.8a.2.2Initiation (184)5.8a.2.3SC-MCCH information acquisition by the UE (184)5.8a.2.4Actions upon reception of the SCPTMConfiguration message (185)5.8a.3SC-PTM radio bearer configuration (185)5.8a.3.1General (185)5.8a.3.2Initiation (185)5.8a.3.3SC-MRB establishment (185)5.8a.3.4SC-MRB release (185)5.9RN procedures (186)5.9.1RN reconfiguration (186)5.9.1.1General (186)5.9.1.2Initiation (186)5.9.1.3Reception of the RNReconfiguration by the RN (186)5.10Sidelink (186)5.10.1Introduction (186)5.10.1a Conditions for sidelink communication operation (187)5.10.2Sidelink UE information (188)5.10.2.1General (188)5.10.2.2Initiation (189)5.10.2.3Actions related to transmission of SidelinkUEInformation message (193)5.10.3Sidelink communication monitoring (195)5.10.6Sidelink discovery announcement (198)5.10.6a Sidelink discovery announcement pool selection (201)5.10.6b Sidelink discovery announcement reference carrier selection (201)5.10.7Sidelink synchronisation information transmission (202)5.10.7.1General (202)5.10.7.2Initiation (203)5.10.7.3Transmission of SLSS (204)5.10.7.4Transmission of MasterInformationBlock-SL message (205)5.10.7.5Void (206)5.10.8Sidelink synchronisation reference (206)5.10.8.1General (206)5.10.8.2Selection and reselection of synchronisation reference UE (SyncRef UE) (206)5.10.9Sidelink common control information (207)5.10.9.1General (207)5.10.9.2Actions related to reception of MasterInformationBlock-SL message (207)5.10.10Sidelink relay UE operation (207)5.10.10.1General (207)5.10.10.2AS-conditions for relay related sidelink communication transmission by sidelink relay UE (207)5.10.10.3AS-conditions for relay PS related sidelink discovery transmission by sidelink relay UE (208)5.10.10.4Sidelink relay UE threshold conditions (208)5.10.11Sidelink remote UE operation (208)5.10.11.1General (208)5.10.11.2AS-conditions for relay related sidelink communication transmission by sidelink remote UE (208)5.10.11.3AS-conditions for relay PS related sidelink discovery transmission by sidelink remote UE (209)5.10.11.4Selection and reselection of sidelink relay UE (209)5.10.11.5Sidelink remote UE threshold conditions (210)6Protocol data units, formats and parameters (tabular & ASN.1) (210)6.1General (210)6.2RRC messages (212)6.2.1General message structure (212)–EUTRA-RRC-Definitions (212)–BCCH-BCH-Message (212)–BCCH-DL-SCH-Message (212)–BCCH-DL-SCH-Message-BR (213)–MCCH-Message (213)–PCCH-Message (213)–DL-CCCH-Message (214)–DL-DCCH-Message (214)–UL-CCCH-Message (214)–UL-DCCH-Message (215)–SC-MCCH-Message (215)6.2.2Message definitions (216)–CounterCheck (216)–CounterCheckResponse (217)–CSFBParametersRequestCDMA2000 (217)–CSFBParametersResponseCDMA2000 (218)–DLInformationTransfer (218)–HandoverFromEUTRAPreparationRequest (CDMA2000) (219)–InDeviceCoexIndication (220)–InterFreqRSTDMeasurementIndication (222)–LoggedMeasurementConfiguration (223)–MasterInformationBlock (225)–MBMSCountingRequest (226)–MBMSCountingResponse (226)–MBMSInterestIndication (227)–MBSFNAreaConfiguration (228)–MeasurementReport (228)–MobilityFromEUTRACommand (229)–Paging (232)–ProximityIndication (233)–RNReconfiguration (234)–RNReconfigurationComplete (234)–RRCConnectionReconfiguration (235)–RRCConnectionReconfigurationComplete (240)–RRCConnectionReestablishment (241)–RRCConnectionReestablishmentComplete (241)–RRCConnectionReestablishmentReject (242)–RRCConnectionReestablishmentRequest (243)–RRCConnectionReject (243)–RRCConnectionRelease (244)–RRCConnectionResume (248)–RRCConnectionResumeComplete (249)–RRCConnectionResumeRequest (250)–RRCConnectionRequest (250)–RRCConnectionSetup (251)–RRCConnectionSetupComplete (252)–SCGFailureInformation (253)–SCPTMConfiguration (254)–SecurityModeCommand (255)–SecurityModeComplete (255)–SecurityModeFailure (256)–SidelinkUEInformation (256)–SystemInformation (258)–SystemInformationBlockType1 (259)–UEAssistanceInformation (264)–UECapabilityEnquiry (265)–UECapabilityInformation (266)–UEInformationRequest (267)–UEInformationResponse (267)–ULHandoverPreparationTransfer (CDMA2000) (273)–ULInformationTransfer (274)–WLANConnectionStatusReport (274)6.3RRC information elements (275)6.3.1System information blocks (275)–SystemInformationBlockType2 (275)–SystemInformationBlockType3 (279)–SystemInformationBlockType4 (282)–SystemInformationBlockType5 (283)–SystemInformationBlockType6 (287)–SystemInformationBlockType7 (289)–SystemInformationBlockType8 (290)–SystemInformationBlockType9 (295)–SystemInformationBlockType10 (295)–SystemInformationBlockType11 (296)–SystemInformationBlockType12 (297)–SystemInformationBlockType13 (297)–SystemInformationBlockType14 (298)–SystemInformationBlockType15 (298)–SystemInformationBlockType16 (299)–SystemInformationBlockType17 (300)–SystemInformationBlockType18 (301)–SystemInformationBlockType19 (301)–SystemInformationBlockType20 (304)6.3.2Radio resource control information elements (304)–AntennaInfo (304)–AntennaInfoUL (306)–CQI-ReportConfig (307)–CQI-ReportPeriodicProcExtId (314)–CrossCarrierSchedulingConfig (314)–CSI-IM-Config (315)–CSI-IM-ConfigId (315)–CSI-RS-Config (317)–CSI-RS-ConfigEMIMO (318)–CSI-RS-ConfigNZP (319)–CSI-RS-ConfigNZPId (320)–CSI-RS-ConfigZP (321)–CSI-RS-ConfigZPId (321)–DMRS-Config (321)–DRB-Identity (322)–EPDCCH-Config (322)–EIMTA-MainConfig (324)–LogicalChannelConfig (325)–LWA-Configuration (326)–LWIP-Configuration (326)–RCLWI-Configuration (327)–MAC-MainConfig (327)–P-C-AndCBSR (332)–PDCCH-ConfigSCell (333)–PDCP-Config (334)–PDSCH-Config (337)–PDSCH-RE-MappingQCL-ConfigId (339)–PHICH-Config (339)–PhysicalConfigDedicated (339)–P-Max (344)–PRACH-Config (344)–PresenceAntennaPort1 (346)–PUCCH-Config (347)–PUSCH-Config (351)–RACH-ConfigCommon (355)–RACH-ConfigDedicated (357)–RadioResourceConfigCommon (358)–RadioResourceConfigDedicated (362)–RLC-Config (367)–RLF-TimersAndConstants (369)–RN-SubframeConfig (370)–SchedulingRequestConfig (371)–SoundingRS-UL-Config (372)–SPS-Config (375)–TDD-Config (376)–TimeAlignmentTimer (377)–TPC-PDCCH-Config (377)–TunnelConfigLWIP (378)–UplinkPowerControl (379)–WLAN-Id-List (382)–WLAN-MobilityConfig (382)6.3.3Security control information elements (382)–NextHopChainingCount (382)–SecurityAlgorithmConfig (383)–ShortMAC-I (383)6.3.4Mobility control information elements (383)–AdditionalSpectrumEmission (383)–ARFCN-ValueCDMA2000 (383)–ARFCN-ValueEUTRA (384)–ARFCN-ValueGERAN (384)–ARFCN-ValueUTRA (384)–BandclassCDMA2000 (384)–BandIndicatorGERAN (385)–CarrierFreqCDMA2000 (385)–CarrierFreqGERAN (385)–CellIndexList (387)–CellReselectionPriority (387)–CellSelectionInfoCE (387)–CellReselectionSubPriority (388)–CSFB-RegistrationParam1XRTT (388)–CellGlobalIdEUTRA (389)–CellGlobalIdUTRA (389)–CellGlobalIdGERAN (390)–CellGlobalIdCDMA2000 (390)–CellSelectionInfoNFreq (391)–CSG-Identity (391)–FreqBandIndicator (391)–MobilityControlInfo (391)–MobilityParametersCDMA2000 (1xRTT) (393)–MobilityStateParameters (394)–MultiBandInfoList (394)–NS-PmaxList (394)–PhysCellId (395)–PhysCellIdRange (395)–PhysCellIdRangeUTRA-FDDList (395)–PhysCellIdCDMA2000 (396)–PhysCellIdGERAN (396)–PhysCellIdUTRA-FDD (396)–PhysCellIdUTRA-TDD (396)–PLMN-Identity (397)–PLMN-IdentityList3 (397)–PreRegistrationInfoHRPD (397)–Q-QualMin (398)–Q-RxLevMin (398)–Q-OffsetRange (398)–Q-OffsetRangeInterRAT (399)–ReselectionThreshold (399)–ReselectionThresholdQ (399)–SCellIndex (399)–ServCellIndex (400)–SpeedStateScaleFactors (400)–SystemInfoListGERAN (400)–SystemTimeInfoCDMA2000 (401)–TrackingAreaCode (401)–T-Reselection (402)–T-ReselectionEUTRA-CE (402)6.3.5Measurement information elements (402)–AllowedMeasBandwidth (402)–CSI-RSRP-Range (402)–Hysteresis (402)–LocationInfo (403)–MBSFN-RSRQ-Range (403)–MeasConfig (404)–MeasDS-Config (405)–MeasGapConfig (406)–MeasId (407)–MeasIdToAddModList (407)–MeasObjectCDMA2000 (408)–MeasObjectEUTRA (408)–MeasObjectGERAN (412)–MeasObjectId (412)–MeasObjectToAddModList (412)–MeasObjectUTRA (413)–ReportConfigEUTRA (422)–ReportConfigId (425)–ReportConfigInterRAT (425)–ReportConfigToAddModList (428)–ReportInterval (429)–RSRP-Range (429)–RSRQ-Range (430)–RSRQ-Type (430)–RS-SINR-Range (430)–RSSI-Range-r13 (431)–TimeToTrigger (431)–UL-DelayConfig (431)–WLAN-CarrierInfo (431)–WLAN-RSSI-Range (432)–WLAN-Status (432)6.3.6Other information elements (433)–AbsoluteTimeInfo (433)–AreaConfiguration (433)–C-RNTI (433)–DedicatedInfoCDMA2000 (434)–DedicatedInfoNAS (434)–FilterCoefficient (434)–LoggingDuration (434)–LoggingInterval (435)–MeasSubframePattern (435)–MMEC (435)–NeighCellConfig (435)–OtherConfig (436)–RAND-CDMA2000 (1xRTT) (437)–RAT-Type (437)–ResumeIdentity (437)–RRC-TransactionIdentifier (438)–S-TMSI (438)–TraceReference (438)–UE-CapabilityRAT-ContainerList (438)–UE-EUTRA-Capability (439)–UE-RadioPagingInfo (469)–UE-TimersAndConstants (469)–VisitedCellInfoList (470)–WLAN-OffloadConfig (470)6.3.7MBMS information elements (472)–MBMS-NotificationConfig (472)–MBMS-ServiceList (473)–MBSFN-AreaId (473)–MBSFN-AreaInfoList (473)–MBSFN-SubframeConfig (474)–PMCH-InfoList (475)6.3.7a SC-PTM information elements (476)–SC-MTCH-InfoList (476)–SCPTM-NeighbourCellList (478)6.3.8Sidelink information elements (478)–SL-CommConfig (478)–SL-CommResourcePool (479)–SL-CP-Len (480)–SL-DiscConfig (481)–SL-DiscResourcePool (483)–SL-DiscTxPowerInfo (485)–SL-GapConfig (485)。