Data-Driven Regular Reconfigurable Arrays Design Space Exploration and Mapping

PRIDE:A Data Abstraction Layer for Large-Scale2-tier Sensor NetworksWoochul Kang University of Virginia Email:wk5f@Sang H.SonUniversity of VirginiaEmail:son@John A.StankovicUniversity of VirginiaEmail:stankovic@Abstract—It is a challenging task to provide timely access to global data from sensors in large-scale sensor network applica-tions.Current data storage architectures for sensor networks have to make trade-offs between timeliness and scalability. PRIDE is a data abstraction layer for2-tier sensor networks, which enables timely access to global data from the sensor tier to all participating nodes in the upper storage tier.The design of PRIDE is heavily influenced by collaborative real-time ap-plications such as search-and-rescue tasks for high-rise building fires,in which multiple devices have to collect and manage data streams from massive sensors in cooperation.PRIDE achieves scalability,timeliness,andflexibility simultaneously for such applications by combining a model-driven full replication scheme and adaptive data quality control mechanism in the storage-tier. We show the viability of the proposed solution by implementing and evaluating it on a large-scale2-tier sensor network testbed. The experiment results show that the model-driven replication provides the benefit of full replication in a scalable and controlled manner.I.I NTRODUCTIONRecent advances in sensor technology and wireless connec-tivity have paved the way for next generation real-time appli-cations that are highly data-driven,where data represent real-world status.For many of these applications,data streams from sensors are managed and processed by application-specific devices such as PDAs,base stations,and micro servers.Fur-ther,as sensors are deployed in increasing numbers,a single device cannot handle all sensor streams due to their scale and geographic distribution.Often,a group of such devices need to collaborate to achieve a common goal.For instance,during a search-and-rescue task for a buildingfire,while PDAs carried byfirefighters collect data from nearby sensors to check the dynamic status of the building,a team of suchfirefighters have to collaborate by sharing their locally collected real-time data with peerfirefighters since each individualfirefighter has only limited information from nearby sensors[1].The building-wide situation assessment requires fusioning data from all(or most of)firefighters.As this scenario shows,lots of future real-time applications will interact with physical world via large numbers of un-derlying sensors.The data from the sensors will be managed by distributed devices in cooperation.These devices can be either stationary(e.g.,base stations)or mobile(e.g.,PDAs and smartphones).Sharing data,and allowing timely access to global data for each participating entity is mandatory for suc-cessful collaboration in such distributed real-time applications.Data replication[2]has been a key technique that enables each participating entity to share data and obtain an understanding of the global status without the need for a central server. In particular,for distributed real-time applications,the data replication is essential to avoid unpredictable communication delays[3][4].PRIDE(Predictive Replication In Distributed Embedded systems)is a data abstraction layer for devices performing collaborative real-time tasks.It is linked to an application(s) at each device,and provides transparent and timely access to global data from underlying sensors via a scalable and robust replication mechanism.Each participating device can transparently access the global data from all underlying sen-sors without noticing whether it is from local sensors,or from remote sensors,which are covered by peer devices. Since global data from all underlying sensors are available at each device,queries on global spatio-temporal data can be efficiently answered using local data access methods,e.g.,B+ tree indexing,without further communication.Further,since all participating devices share the same set of data,any of them can be a primary device that manages a sensor.For example,when entities(either sensor nodes or devices)are mobile,any device that is close to a sensor node can be a primary storage node of the sensor node.Thisflexibility via decoupling the data source tier(sensors)from the storage tier is very important if we consider the highly dynamic nature of wireless sensor network applications.Even with these advantages,the high overhead of repli-cation limits its applicability[2].Since potentially a vast number of sensor streams are involved,it is not generally possible to propagate every sensor measurement to all devices in the system.Moreover,the data arrival rate can be high and unpredictable.During critical situations,the data rates can significantly increase and exceed system capacity.If no corrective action is taken,queues will form and the laten-cies of queries will increase without bound.In the context of centralized systems,several intelligent resource allocation schemes have been proposed to dynamically control the high and unpredictable rate of sensor streams[5][6][7].However, no work has been done in the context of distributed and replicated systems.In this paper,we focus on providing a scalable and robust replication mechanism.The contributions of this paper are: 1)a model-driven scalable replication mechanism,which2significantly reduces the overall communication and computation overheads,2)a global snapshot management scheme for efficientsupport of spatial queries on global data,3)a control-theoretic quality-of-data management algo-rithm for robustness against unpredictable workload changes,and4)the implementation and evaluation of the proposed ap-proach on a real device with realistic workloads.To make the replication scalable,PRIDE provides a model-driven replication scheme,in which the models of sensor streams are replicated to peer storage nodes,instead of data themselves.Once a model for a sensor stream is replicated from a primary storage node of the sensor to peer nodes,the updates from the sensor are propagated to peer nodes only if the prediction from the current model is not accurate enough. Our evaluation in Section5shows that this model-driven approach makes PRIDE highly scalable by significantly re-ducing the communication/computation overheads.Moreover, the Kalmanfilter-based modeling technique in PRIDE is light-weight and highly adaptable because it dynamically adjusts its model parameters at run-time without training.Spatial queries on global data are efficiently supported by taking snapshots from the models periodically.The snapshot is an up-to-date reflection of the monitored situation.Given this fresh snapshot,PRIDE supports a rich set of local data orga-nization mechanisms such as B+tree indexing to efficiently process spatial queries.In PRIDE,the robustness against unpredictable workloads is achieved by dynamically adjusting the precision bounds at each node to maintain a proper level of system load,CPU utilization in particular.The coordination is made among the nodes such that relatively under-loaded nodes synchronize their precision bound with an relatively overloaded node. Using this coordination,we ensure that the congestion at the overloaded node is effectively resolved.To show the viability of the proposed approach,we imple-mented a prototype of PRIDE on a large-scale testbed com-posed of Nokia N810Internet tablets[8],a cluster computer, and a realistic sensor stream generator.We chose Nokia N810 since it represents emerging ubiquitous computing platforms such as PDAs,smartphones,and mobile computers,which will be expected to interact with ubiquitous sensors in the near future.Based on the prototype implementation,we in-vestigated system performance attributes such as communica-tion/computation loads,energy efficiency,and robustness.Our evaluation results demonstrate that PRIDE takes advantage of full replication in an efficient,highly robust and scalable manner.The rest of this paper is organized as follows.Section2 presents the overview of PRIDE.Section3presents the details of the model-driven replication.Section4discusses our pro-totype implemention,and Section5presents our experimental results.We present related work in Section6and conclusions in Section7.II.O VERVIEW OF PRIDEA.System ModelFig.1.A collaborative application on a2-tier sensor network. PRIDE envisions2-tier sensor network systems with a sensor tier and a storage tier as shown in Figure1.The sensor tier consists of a large number of cheap and simple sensors;S={s1,s2,...,s n},where s i is a sensor.Sensors are assumed to be highly constrained in resources,and per-form only primitive functions such as sensing and multi-hop communication without local storage.Sensors stream data or events to a nearest storage node.These sensors can be either stationary or mobile;e.g.,sensors attached to afirefighter are mobile.The storage tier consists of more powerful devices such as PDAs,smartphones,and base stations;D={d1,d2,...,d m}, where d i is a storage node.These devices are relatively resource-rich compared with sensor nodes.However,these devices also have limited resources in terms of processor cycles,memory,power,and bandwidth.Each storage node provides in-network storage for underlying sensors,and stores data from sensors in its vicinity.Each node supports multiple radios;an802.11radio to connect to a wireless mesh network and a802.15.4to communicate with underlying sensors.Each node in this tier can be either stationary(e.g.,base stations), or mobile(e.g.,smartphones and PDAs).The sensor tier and the storage tier have loose coupling; the storage node,which a sensor belongs to,can be changed dynamically without coordination between the two tiers.This loose coupling is required in many sensor network applications if we consider the highly dynamic nature of such systems.For example,the mobility of sensors and storage nodes makes the system design very complex and inflexible if two tiers are tightly coupled;a complex group management and hand-off procedure is required to handle the mobility of entities[9]. Applications at each storage node are linked to the PRIDE layer.Applications issue queries to underlying PRIDE layer either autonomously,or by simply forwarding queries from external users.In the search-and-rescue task example,each storage node serves as both an in-network data storage for nearby sensors and a device to run autonomous real-time applications for the mission;the applications collect data by issuing queries and analyzing the situation to report results to thefirefighter.Afterwards,a node refers to a storage node if it is not explicitly stated.3Fig.2.The architecture of PRIDE(Gray boxes).age ModelIn PRIDE,all nodes in the storage tier are homogeneous in terms of their roles;no asymmetrical function is placed on a sub-group of the nodes.All or part of the nodes in the storage tier form a replication group R to share the data from underlying sensors,where R⊂D.Once a node joins the replication group,updates from its local sensors are propagated to peer nodes;conversely,the node can receive updates from remote sensors via peer nodes.Any storage node,which is receiving updates directly from a sensor,becomes a primary node for the sensor,and it broadcasts the updates from the sensor to peer nodes.However,it should be noted that,as will be shown in Section3,the PRIDE layer at each node performs model-driven replication,instead of replicating sensor data,to make the replication efficient and scalable.PRIDE is characterized by the queries that it supports. PRIDE supports both temporal queries on each individual sensor stream and spatial queries on current global data.Tem-poral queries on sensor s i’s historical data can be answered using the model for s i.An example of temporal query is “What is the value of sensor s i5minutes ago?”For spatial queries,each storage node provides a snapshot on the entire set of underlying sensors(both local and remote sensors.)The snapshot is similar to a view in database ing the snapshot,PRIDE provides traditional data organization and access methods for efficient spatial query processing.The access methods can be applied to any attributes,e.g.,sensor value,sensor ID,and location;therefore,value-based queries can be efficiently supported.Basic operations on the access methods such as insertion,deletion,retrieval,and the iterating cursors are supported.Special operations such as join cursors for join operations are also supported by making indexes to multiple attributes,e.g.,temperature and location attributes. This join operation is required to efficiently support complex spatial queries such as“Return the current temperatures of sensors located at room#4.”III.PRIDE D ATA A BSTRACTION L AYERThe architecture of PRIDE is shown in Figure2.PRIDE consists of three key components:(i)filter&prediction engine,which is responsible for sensor streamfiltering,model update,and broadcasting of updates to peer nodes,(ii)query processor,which handles queries on spatial and temporal data by using a snapshot and temporal models,respectively,and (iii)feedback controller,which determines proper precision bounds of data for scalability and overload protection.A.Filter&Prediction EngineThe goals offilter&prediction engine are tofilter out updates from local sensors using models,and to synchronize models at each storage node.The premise of using models is that the physical phenomena observed by sensors can be captured by models and a large amount of sensor data can be filtered out using the models.In PRIDE,when a sensor Input:update v from sensor s iˆv=prediction from model for s i;1if|ˆv−v|≥δthen2broadcast to peer storage nodes;3update data for s i in the snapshot;4update model m i for s i;5store to cache for later temporal query processing;6else7discard v(or store for logging);8end9Algorithm2:OnUpdateFromPeer.stream s i is covered by PRIDE replication group R,each storage node in R maintains a model m i for s i.Therefore, all storage nodes in R maintain a same set of synchronized models,M={m1,m2,...,m n},for all sensor streams in underlying sensor tier.Each model m i for sensor s i are synchronized at run-time by s i’s current primary storage node (note that s i’s primary node can change during run-time because of the network topology changes either at sensor tier or storage tier).Algorithms1and2show the basic framework for model synchronization at a primary node and peer nodes,respec-tively.In Algorithm1,when an update v is received from sensor s i to its primary storage node d j,the model m i is looked up,and a prediction is made using m i.If the gap between the predicted value from the model,ˆv,and the sensor update v is less than the precision boundδ(line2),then the new data is discarded(or saved locally for logging.)This implies that the current models(both at the primary node and the peer nodes)are precise enough to predict the sensor output with the given precision bound.However,if the gap is bigger than the precision bound,this implies that the model cannot capture the current behavior of the sensor output.In this case, m i at the primary node is updated and v is broadcasted to all peer nodes(line3).In Algorithm2,as a reaction to the broadcast from d j,each peer node receives a new update v and updates its own model m i with v.The value v is stored in local caches at all nodes for later temporal query processing.4As shown in the Algorithms,the communication among nodes happens only when the model is not precise enough. Models,Filtering,and Prediction So far,we have not discussed a specific modeling technique in PRIDE.Several distinctive requirements guide the choice of modeling tech-nique in PRIDE.First,the computation and communication costs for model maintenance should be low since PRIDE han-dles a large number of sensors(and corresponding models for each sensor)with collaboration of multiple nodes.The cost of model maintenance linearly increases to the number of sensors. Second,the parameters of models should be obtained without an extensive learning process,because many collaborative real-time applications,e.g.,a search-and-rescue task in a building fire,are short-term and deployed without previous monitoring history.A statistical model that needs extensive historical data for model training is less applicable even with their highly efficientfiltering and prediction performance.Finally, the modeling should be general enough to be applied to a broad range of applications.Ad-hoc modeling techniques for a particular application cannot be generally used for other applications.Since PRIDE is a data abstraction layer for wide range of collaborative applications,the generality of modeling is important.To this end,we choose to use Kalmanfilter [10][6],which provides a systematic mechanism to estimate past,current,and future state of a system from noisy measure-ments.A short summary on Kalmanfilter follows.Kalman Filter:The Kalmanfilter model assumes the true state at time k is evolved from the state at(k−1)according tox k=F k x k−1+w k;(1) whereF k is the state transition matrix relating x k−1to x k;w k is the process noise,which follows N(0,Q k);At time k an observation z k of the true state x k is made according toz k=H k x k+v k(2) whereH k is the observation model;v k is the measurement noise,which follows N(0,R k); The Kalmanfilter is a recursive minimum mean-square error estimator.This means that only the estimated state from the previous time step and the current measurement are needed to compute the estimate for the current and future state. In contrast to batch estimation techniques,no history of observations is required.In what follows,the notationˆx n|m represents the estimate of x at time n given observations up to,and including time m.The state of afilter is defined by two variables:ˆx k|k:the estimate of the state at time k givenobservations up to time k.P k|k:the error covariance matrix(a measure of theestimated accuracy of the state estimate). Kalmanfilter has two distinct phases:Predict and Update. The predict phase uses the state estimate from the previous timestep k−1to produce an estimate of the state at the next timestep k.In the update phase,measurement information at the current timestep k is used to refine this prediction to arrive at a new more accurate state estimate,again for the current timestep k.When a new measurement z k is available from a sensor,the true state of the sensor is estimates using the previous predictionˆx k|k−1,and the weighted prediction error. The weight is called Kalman gain K k,and it is updated on each prediction/update cycle.The true state of the sensor is estimated as follows,ˆx k|k=ˆx k|k−1+K k(z k−H kˆx k|k−1).(3)P k|k=(I−K k H k)P k|k−1.(4) The Kalman gain K k is updated as follows,K k|k=P k|k−1H T k(H k P k|k−1H T k+R k).(5) At each prediction step,the next state of the sensor is predicted by,ˆx k|k−1=F kˆx k−1|k−1.(6) Example:For instance,a temperature sensor can be described by the linear state space,x k= x dxdtis the derivative of the temperature with respect to time.As a new(noisy)measurement z k arrives from the sensor1,the true state and model parameters are estimated by Equations3-5.The future state of the sensor at(k+1)th time step after∆t can be predicted using the Equation6, where the state transition matrix isF= 1∆t01 .(7) It should be noted that the parameters for Kalmanfilter,e.g., K and P,do not have to be accurate in the beginning;they can be estimated at run-time and their accuracy improves gradually by having more sensor measurements.We do not need massive past data for modeling at deployment time.In addition,the update cycle of Kalmanfilter(Equations3-5) is performed at all storage nodes when a new measurement is broadcasted as shown in Algorithm1(line5)and Algorithm2 (line2).No further communication is required to synchronize the parameters of the models.Finally,as will be shown in Section5,the prediction/update cycle of Kalmanfilter incurs insignificant overhead to the system.1Note that the temperature component of zk is directly acquired from the sensor,and dx5B.Query ProcessorThe query processor of PRIDE supports both temporal queries and spatial queries with planned extension to support spatio-temporal queries.Temporal Queries:Historical data for each sensor stream can be processed in any storage node by exploiting data at the local cache and linear smoother[10].Unlike the estimation of current and future states using one Kalmanfilter,the optimized estimation of historical data(sometimes called smoothing) requires two Kalmanfilters,a forwardfilterˆx and a backward filterˆx b.Smoothing is a non-real-time data processing scheme that uses all measurements between0and T to estimate the state of a system at a certain time t,where0≤t≤T(see Figure3.)The smoothed estimateˆx(t|T)can be obtained as a linear combination of the twofilters as follows.ˆx(t|T)=Aˆx(t)+A′ˆx(t)b,(8) where A and A′are weighting matrices.For detailed discus-sion on smoothing techniques using Kalmanfilters,the reader is referred to[10].Fig.3.Smoothing for temporal query processing.Spatial Queries:Each storage node maintains a snapshot for all underlying local and remote sensors to handle queries on global spatial data.Each element(or data object)of the snapshot is an up-to-date value from the corresponding sensor.The snapshot is dynamically updated either by new measurements from sensors or by models2.The Algorithm1 (line4)and Algorithm2(line1)show the snapshot updates when a new observation is pushed from a local sensor and a peer node,respectively.As explained in the previous section, there is no communication among storage nodes when models well represent the current observations from sensors.When there is no update from peer nodes,the freshness of values in the snapshot deteriorate over time.To maintain the freshness of the snapshot even when there is no updates from peer nodes,each value in the snapshot is periodically updated by its local model.Each storage node can estimate the current state of sensor s i using Equation6without communication to the primary storage node of s i.For example,a temperature after30seconds can be predicted by setting∆t of transition matrix in Equation7to30seconds.The period of update of data object i for sensor s i is determined,such that the precision boundδis observed. Intuitively,when a sensor value changes rapidly,the data object should be updated more frequently to make the data object in the snapshot valid.In the example of Section3.1.1, 2Note that the data structures for the snapshot such as indexes are also updated when each value of the snapshot is updated.the period can be dynamically estimated as follows:p[i]=δ/dxdtis the absolute validity interval(avi)before the data object in the snapshot violates the precision bound,which is±δ.The update period should be as short as the half of the avi to make the data object fresh[11].Since each storage node has an up-to-date snapshot,spatial queries on global data from sensors can be efficiently han-dled using local data access methods(e.g.,B+tree)without incurring further communication delays.(a)δ=5C(b)δ=10CFig.4.Varying data precision.Figure4shows how the value of one data object in the snapshot changes over time when we apply different precision bounds.As the precision bound is getting bigger,the gap be-tween the real state of the sensor(dashed lines)and the current value at the snapshot(solid lines)increases.In the solid lines, the discontinued points are where the model prediction and the real measurement from the sensor are bigger than the precision bound,and subsequent communication is made among storage nodes for model synchronization.For applications and users, maintaining the smaller precision bound implies having a more accurate view on the monitored situation.However, the overhead also increases as we have the smaller precision bound.Given the unpredictable data arrival rates and resource constraints,compromising the data quality for system sur-vivability is unavoidable in many situations.In PRIDE,we consider processor cycles as the primary limited resource,and the resource allocation is performed to maintain the desired CPU utilization.The utilization control is used to enforce appropriate schedulable utilization bounds of applications can be guaranteed despite significant uncertainties in system work-loads[12][5].In utilization control,it is assumed that any cycles that are recovered as a result of control in PRIDE layer are used sensibly by the scheduler in the application layer to relieve the congestion,or to save power[12][5].It can also enhance system survivability by providing overload protection against workloadfluctuation.Specification:At each node,the system specification U,δmax consists of a utilization specification U and the precision specificationδmax.The desired utilization U∈[0..1]gives the required CPU utilization not to overload the system while satisfying the target system performance6 such as latency,and energy consumption.The precisionspecificationδmax denotes the maximum tolerable precision bound.Note there is no lower bound on the precision as in general users require a precision bound as short as possible (if the system is not overloaded.)Local Feedback Control to Guarantee the System Spec-ification:Using feedback control has shown to be very effec-tive for a large class of computing systems that exhibit unpre-dictable workloads and model inaccuracies[13].Therefore,to guarantee the system specification without a priori knowledge of the workload or accurate system model we apply feedbackcontrol.Fig.5.The feedback control loop.The overall feedback control loop at each storage node is shown in Figure5.Let T is the sampling period.The utilization u(k)is measured at each sampling instant0T,1T,2T,...and the difference between the target utilization and u(k)is fed into the ing the difference,the controller computes a local precision boundδ(k)such that u(k)converges to U. Thefirst step for local controller design is modeling the target system(storage node)by relatingδ(k)to u(k).We model the the relationship betwenδ(k)and u(k)by using profiling and statistical methods[13].Sinceδ(k)has higher impact on u(k)as the size of the replication group increases, we need different models for different sizes of the group. We change the number of members of the replication group exponentially from2to64and have tuned a set offirst order models G n(z),where n∈{2,4,8,16,32,64}.G n(z)is the z-transform transfer function of thefirst-order models,in which n is the size of the replication group.After the modeling, we design a controller for the model.We have found that a proportional integral(PI)controller[13]is sufficient in terms of providing a zero steady-state error,i.e.,a zero difference between u(k)and the target utilization bound.Further,a gain scheduling technique[13]have been used to apply different controller gains for different size of replication groups.For instance,the gain for G32(z)is applied if the size of a replication group is bigger than24and less than or equal to48. Due to space limitation we do not provide a full description of the design and tuning methods.Coordination among Replication Group Members:If each node independently sets its own precision bound,the net precision bound of data becomes unpredictable.For example, at node d j,the precision bounds for local sensor streams are determined by d j itself while the precision bounds for remote sensor streams are determined by their own primary storage nodes.PRIDE takes a conservative approach in coordinating stor-age nodes in the group.As Algorithm3shows,the global precision bound for the k th period is determined by taking the maximum from the precision bounds of all nodes in theInput:myid:my storage id number/*Get localδ.*/1measure u(k)from monitor;2calculateδmyid(k)from local controller;3foreach peer node d in R−˘d myid¯do4/*Exchange localδs.*/5/*Use piggyback to save communication cost.*/ 6sendδmyid(k)to d;7receiveδi(k)from d;8end9/*Get thefinal globalδ.*/10δglobal(k)=max(δi(k)),where i∈R;11。

Huawei OceanStor Dorado 5000/6000are mid-range storage systems in the OceanStor Dorado all-flash series,and are designed to provide excellent data service experience for enterprises.Both products are equipped with innovative hardware platform,intelligent FlashLink®algorithms,and an end-to-end (E2E)NVMe architecture,ensuring the storage systems deliver a 30%higher performance than the previous generation,and achieve the latency down to just 0.05ms.The intelligent algorithms are built into the storage system to make storage more intelligent during the application operations.Furthermore,the five-level reliability design ensures the continuity of core business.Excelling in scenarios such as OLTP/OLAP databases,server virtualization,VDI,and resource consolidation,OceanStor Dorado 5000/6000all-flash systems are smart choices for medium and large enterprises,and have already been widely adopted in the finance,government,healthcare,education,energy,and manufacturing fields.The storage systems are ready to maximize your return on investment (ROI)and benefit diverse industries.OceanStor Dorado 5000/6000All-Flash Storage Systems 30%higher performance than theprevious generation E2E NVMe for 0.05ms of ultra-low latencyFlashLink®intelligent algorithmsSCM intelligent cache acceleration for 60%lower latencyDistributed file system with 30%higher performanceLeading Performance withInnovative Hardware✓The intelligent multi-protocol interface module hosts the protocol parsing previously performed by the general-purpose CPU, expediting the front-end access performance by 20%.✓The computing platform offers industry-leading performance with 25% higher computing power than the industry average.✓The intelligent accelerator module analyzes and understands I/O rules of multiple application models based 3-layer intelligent management:•365-day capacity trends prediction •60-day performance bottleneck prediction •14-day disk fault prediction •Immediate solutions for 93%ofproblemsSAN&NAS convergence,storage and computing convergence,and cross-gen device convergence for efficient resource utilizationFlashEver:No data migration over 10years for 3-gen systems Efficient O&M with IntelligentEdge-Cloud SynergyComponent reliability :Wear leveling and anti-wear levelingArchitecture and product reliability :0data loss in the event of failures of controllers,disk enclosures,or three disksSolution and cloud reliability :The industry's only A-A solution for SAN and NAS,geo-redundant 3DC solution,and gateway-free cloud backup Always-On Applications with5-Layer ReliabilityProduct Features Ever Fast Performance with Innovative Hardware Innovative hardware platform: The hardware platform of Huawei storage enables E2E data acceleration, improving the system performance by 30% compared to the previousgeneration.on machine learning frameworks to implement intelligentprefetching of memory space. This improves the read cache hit ratio by 50%.✓SmartCache+ SCM intelligent multi-tier caching identify whether or not the data is hot and uses different media tostore it, reducing the latency by 60% in OLTP (100% reads) scenarios.✓The intelligent SSD hosts the core Flash Translation Layer (FTL) algorithm, accelerating data access in SSDs andreducing the write latency by half.✓The intelligent hardware has a built-in Huawei storage fault library that accelerates component fault location anddiagnosis, and shortens the fault recovery time from 2hours to just 10 minutes.Intelligent algorithms: Most flash vendors lack E2E innate capabilities to ensure full performance from their SSDs. OceanStor Dorado 5000/6000 runs industry-leading FlashLink® intelligent algorithms based on self-developed controllers, disk enclosures, and operating systems.✓Many-core balancing algorithm: Taps into the many-core computing power of a controller to maximize the dataprocessing capability.✓Service splitting algorithm: Offloads reconstruction services from the controller enclosure to the smart SSD enclosure to ease the load pressure of the controller enclosure for moreefficient I/O processing.✓Cache acceleration algorithm: Accelerates batch processing with the intelligent module to bring intelligence to storagesystems during application operations.The data layout between SSDs and controllers is coordinated synchronously.✓Large-block sequential write algorithm: Aggregates multiple discrete data blocks into a unified big data blockfor disk flushing, reducing write amplification and ensuringstable performance.✓Independent metadata partitioning algorithm: Effectively controls the performance compromise caused by garbagecollection for stable performance.✓I/O priority adjustment algorithm: Ensures that read and write I/Os are always prioritized, shortening the accesslatency.FlashLink® intelligent algorithms give full play to all flash memory and help Huawei OceanStor Dorado achieve unparalleled performance for a smoother service experience.E2E NVMe architecture for full series: All-flash storage has been widely adopted by enterprises to upgrade existing ITsystems, but always-on service models continue to push IT system performance boundaries to a new level. Conventional SAS-based all-flash storage cannot break the bottleneck of 0.5 ms latency. NVMe all-flash storage, on the other hand, is a future-proof architecture that implements direct communication between the CPU and SSDs, shortening the transmission path. In addition, the quantity of concurrencies is increased by 65,536 times, and the protocol interaction is reduced from four times to two, which doubles the write request processing. Huawei is a pioneer in adopting end-to-end NVMe architecture across the entire series. OceanStor Dorado 5000/6000 all-flash systems use the industry-leading 32 Gb FC-NVMe/100 Gb RoCE protocols at the front end and adopt Huawei-developed link-layer protocols to implement failover within seconds and plug-and-play, thus improving the reliability and O&M. It also uses a 100 Gb RDMA protocol at the back end for E2E data acceleration. This enables latency as low as 0.05 ms and 10x faster transmission than SAS all-flash storage. Globally shared distributed file system: The OceanStor Dorado 5000/6000 all-flash storage systems support the NAS function and use the globally shared distributed file systems to ensure ever-fast NAS performance. To make full use of computing power, the many-core processors in a controller process services concurrently. In addition, intelligent data prefetching and layout further shorten the access latency, achieving over 30% higher NAS performance than the industry benchmark.Linear increase of performance and capacity: Unpredictable business growth requires storage to provide simple linear increases in performance as more capacity is added to keep up with ever-changing business needs. OceanStor Dorado5000/6000 support the scale-out up to 16 controllers, and IOPS increases linearly as the quantity of controller enclosures increases, matching the performance needs of the future business development.Efficient O&M with Intelligent Edge-Cloud Synergy Extreme convergence: Huawei OceanStor Dorado 5000/6000 all-flash storage systems provide multiple functions to meet diversified service requirements, improve storage resource utilization, and effectively reduce the TCO. The storage systems provide both SAN and NAS services and support parallel access, ensuring the optimal path for dual-service access. Built-in containers support storage and compute convergence, reducing IT construction costs, eliminating the latency between servers and storage, and improving performance. The convergence of cross-generation devices allows data to flow freely, simplifying O&M and reducing IT purchasing costs.On and off-cloud synergy: Huawei OceanStor Dorado5000/6000 all-flash systems combine general-purpose cloud intelligence with customized edge intelligence over a built-inintelligent hardware platform, providing incremental training and deep learning for a personalized customer experience. The eService intelligent O&M and management platform collects and analyzes over 190,000 device patterns on the live network in real time, extracts general rules, and enhances basic O&M. Intelligence throughout service lifecycle: Intelligent management covers resource planning, provisioning, system tuning, risk prediction, and fault location, and enables 60-day and 14-day predictions of performance bottleneck and disk faults respectively, and immediate solutions for 93% of problems detected.FlashEver: The intelligent flexible architecture implements component-based upgrades without the need for data migration within 10 years. Users can enjoy latest-generation software and hardware capabilities without investing again in the related storage software features.Always-On Applications with 5-Layer Reliability Industries such as finance, manufacturing, and carriers are upgrading to intelligent service systems to meet the strategy of sustainable development. This will likely lead to diverse services and data types that require better IT architecture. Huawei OceanStor Dorado all-flash storage is an ideal choice for customers who need robust IT systems that consolidate multiple types of services for stable, always on services. It ensures end-to-end reliability at all levels, from component, architecture, product, solution, all the way to cloud, supporting data consolidation scenarios with 99.9999% availability. Benchmark-Setting 5-Layer ReliabilityComponent –SSDs: Reliability has always been a top concern in the development of SSDs, and Huawei SSDs are a prime example of this. Leveraging global wear-leveling technology, Huawei SSDs can balance their loads for a longer lifespan of each SSD. In addition, Huawei's patented anti-wear leveling technology prevents simultaneous multi-SSD failures and improves the reliability of the entire system.Architecture –fully interconnected design: Huawei OceanStor Dorado 5000/6000 adopt the intelligent matrix architecture (multi-controller) within a fully symmetric active-active (A-A) design to eliminate single points of failure and achieve high system availability. Application servers can access LUNs through any controller, instead of just a single controller. Multiple controllers share workload pressure using the load balancing algorithm. If a controller fails, other controllers take over services smoothly without any service interruption. Product –enhanced hardware and software: Product design is a systematic process. Before a stable storage system is commercially released, it must ensure that it meets the demands from both software and hardware, and can faultlesslyhost key enterprise applications. The OceanStor Dorado5000/6000 are equipped with hardware that adopts a fully redundant architecture and supports dual-port NVMe and hot swap, preventing single points of failure. The innovative 9.5 mm palm-sized SSDs and biplanar orthogonal backplane design provide 44% higher capacity density and 25% improved heat dissipation capability, and ensure stable operations of 2U 36-slot SSD enclosures. The smart SSD enclosure is the first ever to feature built-in intelligent hardware that offloads reconstruction from the controller to the smart SSD enclosure. Backed up by RAID-TP technology, the smart SSD enclosure can tolerate simultaneous failures of three SSDs and reconstruct 1 TB of data within 25 minutes. In addition, the storage systems offer comprehensive enterprise-grade features, such as 3-second periodic snapshots, that set a new standard for storage product reliability.Solution –gateway-free active-active solution: Flash storage is designed for enterprise applications that require zero data loss or zero application interruption. OceanStor Dorado5000/6000 use a gateway-free A-A solution for SAN and NAS to prevent node failures, simplify deployment, and improve system reliability. In addition, the A-A solution implements A-A mirroring for load balancing and cross-site takeover without service interruption, ensuring that core applications are not affected by system breakdown. The all-flash systems provide the industry's only A-A solution for NAS, ensuring efficient, reliable NAS performance. They also offer the industry's firstall-IP active-active solution for SAN, which uses long-distance RoCE transmission to improve performance by 50% compared with traditional IP solutions. In addition, the solution can be smoothly upgraded to the geo-redundant 3DC solution for high-level data protection.Cloud –gateway-free cloud DR*: Traditional backup solutions are slow, expensive, and the backup data cannot be directly used. Huawei OceanStor Dorado 5000/6000 systems provide a converged data management solution. It improves the backup frequency 30-fold using industry-leading I/O-level backup technology, and allows backup copies to be directly used for development and testing. The disaster recovery (DR) and backup are integrated in the storage array, slashing TCO of DR construction by 50%. Working with HUAWEI CLOUD and Huawei jointly-operated clouds, the solution achieves gateway-free DR and DR in minutes on the cloud.Technical SpecificationsModel OceanStor Dorado 5000 OceanStor Dorado 6000 Hardware SpecificationsMaximum Number ofControllers3232Maximum Cache (DualControllers, Expanding withthe Number of Controllers)256 GB-8 TB 1 TB-16 TBSupported Storage Protocols FC, iSCSI, NFS*, CIFS*Front-End Port Types8/16/32 Gbit/s FC/FC-NVMe*, 10/25/40/100 GbE, 25/100 Gb NVMe over RoCE*Back-End Port Types SAS 3.0/ 100 Gb RDMAMaximum Number of Hot-Swappable I/O Modules perController Enclosure12Maximum Number of Front-End Ports per ControllerEnclosure48Maximum Number of SSDs3,2004,800SSDs 1.92 TB/3.84 TB/7.68 TB palm-sized NVMe SSD,960 GB/1.92 TB/3.84 TB/7.68 TB/15.36 TB SASSSDSCM Supported800 GB SCM*Software SpecificationsSupported RAID Levels RAID 5, RAID 6, RAID 10*, and RAID-TP (tolerates simultaneous failures of 3 SSDs)Number of LUNs16,38432,768Value-Added Features SmartDedupe, SmartVirtualization, SmartCompression, SmartMigration, SmartThin,SmartQoS(SAN&NAS), HyperSnap(SAN&NAS), HyperReplication(SAN&NAS),HyperClone(SAN&NAS), HyperMetro(SAN&NAS), HyperCDP(SAN&NAS), CloudBackup*,SmartTier*, SmartCache*, SmartQuota(NAS)*, SmartMulti-Tenant(NAS)*, SmartContainer* Storage ManagementSoftwareDeviceManager UltraPath eServicePhysical SpecificationsPower Supply SAS SSD enclosure: 100V–240V AC±10%,192V–288V DC,-48V to -60V DCController enclosure/Smart SAS diskenclosure/Smart NVMe SSD enclosure: 200V–240V AC±10%, 100–240V AC±10%,192V–288V DC, 260V–400V DC,-48V to -60V DC SAS SSD enclosure: 100V–240V AC±10%, 192V–288V DC, -48V to -60V DC Controller enclosure/Smart SAS SSD enclosure/Smart NVMe SSD enclosure: 200V–240V AC±10%, 192V–288V DC, 260V–400V DC,-48V to -60V DCTechnical SpecificationsModel OceanStor Dorado 5000 OceanStor Dorado 6000 Physical SpecificationsDimensions (H x W x D)SAS controller enclosure: 86.1 mm ×447mm ×820 mmNVMe controller enclosure: 86.1 mm ×447mm ×920 mmSAS SSD enclosure: 86.1 mm ×447 mm ×410 mmSmart SAS SSD enclosure: 86.1 mm x 447mm x 520 mmNVMe SSD enclosure: 86.1 mm x 447 mm x620 mmSAS controller enclosure: 86.1 mm ×447mm ×820 mmNVMe controller enclosure: 86.1 mm ×447mm ×920 mmSAS SSD enclosure: 86.1 mm ×447 mm ×410 mmSmart SAS SSD enclosure: 86.1 mm ×447mm ×520 mmNVMe SSD enclosure: 86.1 mm x 447 mm x620 mmWeight SAS controller enclosure: ≤ 45 kgNVMe controller enclosure: ≤ 50 kgSAS SSD enclosure: ≤ 20 kgSmart SAS SSD enclosure: ≤ 30 kgSmart NVMe SSD enclosure: ≤ 35 kg SAS controller enclosure: ≤ 45 kg NVMe controller enclosure: ≤ 50 kg SAS SSD enclosure: ≤ 20 kgSmart SAS SSD enclosure: ≤ 30 kg Smart NVMe SSD enclosure: ≤ 35 kgOperating Temperature–60 m to +1800 m altitude: 5°C to 35°C (bay) or 40°C (enclosure)1800 m to 3000 m altitude: The max. temperature threshold decreases by 1°C for everyaltitude increase of 220 mOperating Humidity10% RH to 90% RHCopyright © Huawei Technologies Co., Ltd. 2021. All rights reserved.No part of this document may be reproduced or transmitted in any form or by any means without the prior written consent of Huawei Technologies Co., Ltd.Trademarks and Permissions, HUAWEI, and are trademarks or registered trademarks of Huawei Technologies Co., Ltd. Other trademarks, product, service and company names mentioned are the property of their respective holders.Disclaimer THE CONTENTS OF THIS MANUAL ARE PROVIDED "AS IS". EXCEPT AS REQUIRED BY APPLICABLE LAWS, NO WARRANTIES OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, THE IMPLIEDWARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, ARE MADE IN RELATION TOTHE ACCURACY, RELIABILITY OR CONTENTS OF THIS MANUAL.TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, IN NO CASE SHALL HUAWEI TECHNOLOGIESCO., LTD BE LIABLE FOR ANY SPECIAL, INCIDENTAL, INDIRECT, OR CONSEQUENTIAL DAMAGES, OR LOSTPROFITS, BUSINESS, REVENUE, DATA, GOODWILL OR ANTICIPATED SAVINGS ARISING OUT OF, OR INCONNECTION WITH, THE USE OF THIS MANUAL.Tel: + S h e n z h en 518129,P.R.C h i n aBantian Longgang DistrictHUAWEI TECHNOLOGIES CO.,LTD.To learn more about Huawei storage, please contact your local Huawei officeor visit the Huawei Enterprise website: .Huawei Enterprise APPHuawei IT。

【收藏】R数据分析常用包与函数2016-09-26R语言作为入门槛较低的解释性编程语言，受到从事数据分析，数据挖掘工作人员的喜爱，在行业排名中一直保持较高的名次（经常排名第一），下面列出了可用于数据分析、挖掘的R包和函数的集合。

1、聚类常用的包：fpc，cluster，pvclust，mclust基于划分的方法: kmeans, pam, pamk, clara基于层次的方法: hclust, pvclust, agnes, diana基于模型的方法: mclust基于密度的方法: dbscan基于画图的方法: plotcluster, plot.hclust基于验证的方法: cluster.stats2、分类常用的包：rpart，party，randomForest，rpartOrdinal，tree，marginTree，maptree，survival决策树: rpart, ctree随机森林: cforest, randomForest回归, Logistic回归, Poisson回归: glm, predict, residuals生存分析: survfit, survdiff, coxph3、关联规则与频繁项集常用的包：arules：支持挖掘频繁项集，最大频繁项集，频繁闭项目集和关联规则DRM：回归和分类数据的重复关联模型APRIORI算法，广度RST算法：apriori, drmECLAT算法：采用等价类，RST深度搜索和集合的交集：eclat4、序列模式常用的包：arulesSequencesSPADE算法：cSPADE5、时间序列常用的包：timsac时间序列构建函数：ts成分分解: decomp, decompose, stl, tsr6、统计常用的包：Base R, nlme方差分析: aov, anova假设检验: t.test, prop.test, anova, aov线性混合模型：lme主成分分析和因子分析：princomp7、图表条形图: barplot饼图: pie散点图: dotchart直方图: hist箱线图boxplotQQ图: qqnorm, qqplot, qqlineBi-variate plot: coplot树图: rpartParallel coordinates: parallel, paracoor, parcoord热图, contour: contour, filled.contour其他图: stripplot, sunflowerplot, interaction.plot, matplot, fourfoldplot, assocplot, mosaicplot8、数据操作缺失值：na.omit变量标准化：scale变量转置：t抽样：sample其他：aggregate, merge, reshape。

rrt自主探索原理
RRT（Rapidly-exploring Random Tree）是一种常用的自主探索算法，其原理如下：
1. 初始化：将起始点作为根节点，创建一棵树。

2. 生成随机点：在搜索空间中随机生成一个点。

3. 寻找最近节点：在树中找到最接近随机点的节点。

4. 扩展节点：从最接近的节点出发，沿着随机点方向移动一小步，生成一个新的节点。

5. 碰撞检测：检测新节点与障碍物是否有碰撞。

如果有碰撞，则舍弃该点。

6. 链接节点：将新节点与最接近的节点连接。

7. 判断目标是否可达：判断新节点是否接近目标点。

如果新节点接近目标点，则将新节点作为目标节点插入到树中，并返回成功；否则，回到步骤2。

8. 终止条件：当达到设定的最大迭代次数或无法继续生成新节点时，终止搜索。

RRT算法通过不断生成新节点并与现有的节点连接，逐步扩展搜索树，直到达到目标点或无法继续扩展为止。

通过随机生
成点来探索搜索空间，增加搜索范围，能够较好地应对复杂的环境。

同时，利用碰撞检测可以避免生成与障碍物相交的节点，提升路径规划的安全性。

coderinfo.storageclass的枚举量coderinfo.storageclass枚举量用于表示存储类别。

该枚举量有以下值：1.STANDARD：标准存储类别，具有较低的成本和较高的延迟。

2.STANDARD_IA：低频访问存储类别，具有较低的成本和较高的延迟。

3.NEARLINE：冷存储类别，具有最低的成本和最高的延迟。

4.ARCHIVE：归档存储类别，具有最低的成本和最高的延迟。

以下是每个存储类别的详细说明：●STANDARD：STANDARD存储类别是Amazon S3中最常用的存储类别。

它具有较低的成本和较高的延迟，适用于需要随时访问的常规数据。

●STANDARD_IA：STANDARD_IA存储类别是Amazon S3的低频访问存储类别。

它具有较低的成本和较高的延迟，适用于需要定期访问，但不经常访问的数据。

●NEARLINE：NEARLINE存储类别是Amazon S3的冷存储类别。

它具有最低的成本和最高的延迟，适用于需要不经常访问的数据。

●ARCHIVE：ARCHIVE存储类别是Amazon S3的归档存储类别。

它具有最低的成本和最高的延迟，适用于需要长期存储的数据。

在使用coderinfo.storageclass枚举量时，可以通过以下方式指定存储类别：1.使用枚举量的名称：例如，coderinfo.storageclass=STANDARD。

2.使用枚举量的值：例如，coderinfo.storageclass=0。

以下是使用coderinfo.storageclass枚举量的示例：✧import coderinfo✧指定存储类别为STANDARD✧coderinfo.storageclass=coderinfo.STORAGECLASS.STANDARD✧指定存储类别为STANDARD_IA✧coderinfo.storageclass=coderinfo.STORAGECLASS.STANDARD_IA✧指定存储类别为NEARLINE✧coderinfo.storageclass=coderinfo.STORAGECLASS.NEARLINE✧指定存储类别为ARCHIVE✧coderinfo.storageclass=coderinfo.STORAGECLASS.ARCHIVE。

csr读取稀疏矩阵1.引言1.1 概述概述部分的内容可以包括CSR格式和稀疏矩阵的基本概念和定义。

概述:CSR (Compressed Sparse Row) 格式是一种常用的稀疏矩阵存储格式，它通过压缩稀疏矩阵的行索引、列索引和非零元素值的方式，实现了对大规模稀疏矩阵的高效存储和读取。

稀疏矩阵是指矩阵中大部分元素为零的矩阵，与之相对的是稠密矩阵，即大部分元素都不为零。

在很多应用领域，如图像处理、机器学习和科学计算等，稀疏矩阵的表示和处理是非常重要的。

CSR格式最早由Yale大学的George K. Francis教授在1972年提出，在数值计算和稀疏矩阵计算领域得到了广泛应用。

相比于其他常见的稀疏矩阵存储格式，如COO (Coordinate) 格式和CSC (Compressed Sparse Column) 格式，CSR格式具有更高的存储效率和读取速度。

它通过将矩阵的非零元素按行顺序存储，并将每行的非零元素的列索引和值分别保存在两个数组中，大大节省了存储空间。

此外，CSR格式还支持快速的稀疏矩阵向量乘法等操作，是许多线性代数计算中的重要基础。

本文将介绍CSR格式在读取稀疏矩阵中的应用。

首先，我们将详细介绍CSR格式的原理和数据结构，并对其进行比较分析，了解其优势和不足之处。

然后，我们将探讨稀疏矩阵的定义和特点，从理论上认识稀疏矩阵的结构和特性，为后续的稀疏矩阵读取提供基础。

最后，我们将在结论部分总结CSR格式在读取稀疏矩阵中的优势和应用场景。

通过本文的阅读，读者将能够全面了解CSR格式在读取稀疏矩阵中的原理和应用，为进一步的研究和应用提供参考。

希望本文能够对读者在稀疏矩阵的处理和应用中起到一定的帮助和指导作用。

1.2文章结构文章结构是指文章的组织方式和章节的排列顺序。

一个良好的文档结构可以使读者更好地理解文章的主要内容和观点。

本文按照以下结构来组织：1. 引言1.1 概述1.2 文章结构1.3 目的2. 正文2.1 CSR格式介绍2.2 稀疏矩阵的定义和特点3. 结论3.1 CSR格式在读取稀疏矩阵中的应用3.2 总结在引言部分，我们将对文章要介绍的内容进行概述，简要说明CSR格式和稀疏矩阵，以及本文的目的。

2024年华为人工智能方向HCIA考试复习题库（含答案）一、单选题1.以下哪—项不属于MindSpore全场景部署和协同的关键特性?A、统一模型R带来一致性的部署体验。

B、端云协同FederalMetaLearning打破端云界限,多设备协同模型。

C、数据+计算整图到Ascend芯片。

D、软硬协同的图优化技术屏蔽场景差异。

参考答案：C2.在对抗生成网络当中,带有标签的数据应该被放在哪里?A、作为生成模型的输出值B、作为判别模型的输入值C、作为判别模型的输出值D、作为生成模型的输入值参考答案：B3.下列属性中TensorFlow2.0不支持创建tensor的方法是?A、zerosB、fillC、createD、constant参考答案：C4.以下哪一项是HiAI3.0相对于2.0提升的特点？A、单设备B、分布式C、多设备D、端云协同参考答案：B5.以下哪个不是MindSpore中Tensor常见的操作？A、asnumpy()B、dim()C、for()D、size()参考答案：C6.优化器是训练神经网络的重要组成部分,使用优化器的目的不包含以下哪项:A、加快算法收敛速度B、减少手工参数的设置难度C、避过过拟合问题D、避过局部极值参考答案：C7.K折交叉验证是指将测试数据集划分成K个子数据集。

A、TRUEB、FALSE参考答案：B8.机器学习是深度学习的一部分。

人工智能也是深度学习的一部分。

A、TrueB、False参考答案：B9.在神经网络中,我们是通过以下哪个方法在训练网络的时候更新参数,从而最小化损失函数的?A、正向传播算法B、池化计算C、卷积计算D、反向传播算法参考答案：D10.以下不属于TensorFlow2.0的特点是?A、多核CPU加速B、分布式C、多语言D、多平台参考答案：A11.以下关于机器学习中分类模型与回归模型的说法,哪一项说法是正确的?A、对回归问题和分类问题的评价,最常用的指标都是准确率和召回率B、输出变量为有限个离散变量的预测问题是回归问题,输出变量为连续变量的预测问题是分类问题C、回归问题知分类问题都有可能发生过拟合D、逻辑回归是一种典型的回归模型参考答案：C12.ModelArts平台中的数据管理中不支持视频数据格式。

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

一、单选题（60分，每题0.5分）1．电磁波的极化方向就是（）方向A.电场方向B.磁场方向C.传播方向D.以上都不是答案：A2．避雷针要有足够的高度，能保护铁塔或杆上的所有天线，所有室外设施都应在避雷针的（）度保护角之内。

A.30B.45C.60D.90答案：B3．对于90度的方向性天线，它的含义是（）A.天线覆盖X围是90度B.天线半功率角是90度C.天线安装方向为90度D.以上都不正确答案：B4．下列关于天线的描述不正确的是（）A.天线是由一系列半波振子组成的B.天线是能量转换装置C.天线是双向器件D.天线增益越高，主瓣越小，旁瓣越大答案：D5．你对天线的增益（dBd）是如何认识的（）A.这是一个绝对增益值B.天线是无源器件，不可能有增益，所以此值没有实际意义C.这是一个与集中幅射有关的相对值D.全向天线没有增益，而定向天线才有增益答案：C6．在使用SiteMaster之前，必须对之（）校准。

A.负载B.开路C.短路D.以上三种都要答案：D7．下列关于天线的描述不正确的是（）A.天线把电信号转换成电磁波B.天线把电磁波转换为电信号C.天线是双向器件D.天线发射端的信号功率比天线输入端的信号功率大答案：D8.请问下列关于天线的描述哪些是正确的: （）A.天线的机械下倾角度过大会导致天线方向图严重变形(即主瓣前方产生凹坑)B.电子下倾通过改变天线振子的相位使得波束的发射方向发生改变,各个波瓣的功率下降幅度是相同的C.当天线下倾角增大到一定数值时,天线前后辐射比变小,此时主波束对应覆盖区域逐渐凹陷下去,同时旁瓣增益增加,造成其它方向上同频小区干扰D.当天线以垂直方向安装时,它的发射方向是水平的,由于要考虑到控制覆盖X围和同频干扰,小区制的蜂窝网络的天线一般有一个下倾角度。

答案：A9．100米1/2软跳线的损耗是（）dB。

A.4.3B.7.7C.33D.3答案：B10.以下所测天馈线系统的回波损耗（）是合格的。

稀疏矩阵是指矩阵中大部分元素都是0的矩阵。

由于稀疏矩阵中大部分元素都是0，因此存储和处理这种矩阵时可以使用一些特殊的方法来节省存储空间和提高计算效率。

以下是一些常见的稀疏矩阵存储格式：
1. COO（Coordinate List）格式：COO格式是一种基于矩阵元素的坐标信息来存储稀疏矩阵的格式。

在COO格式中，每个非零元素由它的行和列编号表示，这两个编号被称为元素的坐标。

COO格式的优点是它可以直接访问元素，不需要进行任何转换，但是它的缺点是它需要存储每个元素的行和列信息，占用的存储空间较大。

2. CSR（Compressed Sparse Row）格式：CSR格式是一种基于矩阵元素的行和列编号来存储稀疏矩阵的格式。

在CSR格式中，每个非零元素由它的行和列编号以及值表示。

CSR格式的优点是它可以使用较小的存储空间来存储矩阵，因为它只需要存储非零元素和它们的行和列编号，而不需要存储元素的坐标信息。

但是，CSR格式需要进行一些额外的操作才能访问元素，比如需要通过行和列编号找到元素的位置。

3. CSC（Compressed Sparse Column）格式：CSC格式是一种基于矩阵元素的列编号来存储稀疏矩阵的格式。

在CSC格式中，每个非零元素由它的行和列编号以及值表示。

CSC格式的优点是它可以使用较小的存储空间来存储矩阵，因为它只需要存储非零元素和它们的列编号，而不需要存储元素的行编号。

但是，CSC格式需要进行一些额外的操作才能访问元素，比如需要通过列编号找到元素的位置。

以上是一些常见的稀疏矩阵存储格式，每种格式都有其优缺点，需要根据具体的应用场景和需求来选择合适的格式。

不同场景下参数配置在不同场景下进行参数配置是一项重要而复杂的任务，涉及到众多因素和变量。

本文将探讨在几个不同的场景中进行参数配置的一些关键方面。

1.机器学习模型参数配置：在机器学习模型中，参数配置对算法的性能和效果有着重要的影响。

以下是一些常见的机器学习模型参数配置的方面：- 学习率（learning rate）：控制模型在训练过程中的更新速度。

过高的学习率可能导致发散，而过低的学习率则可能导致模型收敛速度过慢。

- 正则化参数（regularization）：用来控制模型的复杂度，可以帮助避免过拟合问题。

正则化参数越大，模型的复杂度越低，但可能会引入欠拟合问题。

- 批量大小（batch size）：决定每次迭代更新模型时使用的训练样本数量。

较小的批量大小能提供更多的梯度更新，而较大的批量大小则能提高模型训练的效率。

- 激活函数（activation function）：选择适当的激活函数可以帮助模型更好地拟合数据。

不同的激活函数适用于不同的场景和问题。

2.网络配置参数：在计算机网络中，参数配置对网络的性能和可靠性有着重要的影响。

以下是一些常见的网络配置参数的方面：- 带宽（bandwidth）：决定网络传输速度的最大容量，直接影响网络的吞吐量和响应时间。

- 传输协议（transmission protocol）：选择适当的传输协议可以根据网络的特点和需求来优化传输性能，例如TCP和UDP的选择。

- 拥塞控制（congestion control）：对网络中拥塞情况进行监测和调节，以避免网络性能下降和数据丢失。

- 延迟（latency）：网络传输中的延时时间，影响实时应用的响应时间和用户体验。

3.数据库配置参数：在数据库系统中，参数配置对数据库的性能和可扩展性有着重要的影响。

以下是一些常见的数据库配置参数的方面：- 缓冲区大小（buffer size）：决定数据库能够缓存的数据量大小，直接影响数据库的访问速度。

MATLAB总结一MATLAB常用函数1、特殊变量与常数2、操作符与特殊字符3、基本数学函数4、基本矩阵和矩阵操作5、数值分析和傅立叶变换6、多项式与插值7、绘图函数二Matlab工作间常用命令：1、常用的窗口命令2、有关文件及其操作的语句3、启动与退出的命令4、管理变量工作空间的命令5、对命令窗口控制的常用命令6、此外还有一些常用的命令：↑Ctrl+p 调用上一次的命令↓Ctrl+n 调用下一行的命令←Ctrl+b 退后一格→Ctrl+f 前移一格Ctrl + ←Ctrl+r 向右移一个单词Ctrl + →Ctrl+l 向左移一个单词Home Ctrl+a 光标移到行首End Ctrl+e 光标移到行尾Esc Ctrl+u 清除一行Del Ctrl+d 清除光标后字符Backspace Ctrl+h 清除光标前字符Ctrl+k 清除光标至行尾字 Ctrl+c 中断程序运行三Matlab 运行加速1)性能加速a、采用如下数据类型：logical、char、int、uint、double;b、数据维数不超过3；c、f or循环范围内只采用标量值;只调用内建函数..if 、else if 、while、swicth的条件测试语句只采用标量；d、同一行的命令条数为一条；e、命令操作为改变数据类型或者形状大小;维数；f、复数写为：ａ＋ｂｊ型；2遵守3条准则a、避免使用循环语句将循环语句向量化：向量化技术函数有All、diff、ipermute、permute、reshape、squeeze、any、find、logical、prod、shiftdim、sub2ind、cumsum、ind2sub、ndgrid、repmat、sort、sum 等；不得不使用循环语句时;超过2重;循环次数少的在外环；b、预分配矩阵空间函数有：zeros、ones、cell、struct、repmat和采用repmat函数对非double 型预分配空间或对一个变量扩容；c、优先使用内建函数和function;3绝招：采用Mex技术;或者利用matlab提供的工具将程序转化为C语言、Fortran 语言注意：比较向量化和加速器；加速之前采用profiler测试各部分耗时情况..SIMILINK模块库按功能进行分为以下8类子库：Continuous连续模块Discrete离散模块Function&Tables函数和平台模块Math数学模块Nonlinear非线性模块Signals&Systems信号和系统模块Sinks接收器模块Sources输入源模块连续模块Continuouscontinuous.mdlIntegrator：输入信号积分Derivative：输入信号微分State-Space：线性状态空间系统模型Transfer-Fcn：线性传递函数模型Zero-Pole：以零极点表示的传递函数模型Memory：存储上一时刻的状态值Transport Delay：输入信号延时一个固定时间再输出Variable Transport Delay：输入信号延时一个可变时间再输出离散模块Discrete discrete.mdlDiscrete-time Integrator：离散时间积分器Discrete Filter：IIR与FIR滤波器Discrete State-Space：离散状态空间系统模型Discrete Transfer-Fcn：离散传递函数模型Discrete Zero-Pole：以零极点表示的离散传递函数模型First-Order Hold：一阶采样和保持器Zero-Order Hold：零阶采样和保持器Unit Delay：一个采样周期的延时函数和平台模块Function&Tables function.mdlFcn：用自定义的函数表达式进行运算：利用matlab的现有函数进行运算S-Function：调用自编的S函数的程序进行运算Look-Up Table：建立输入信号的查询表线性峰值匹配Look-Up Table2-D：建立两个输入信号的查询表线性峰值匹配数学模块Math math.mdlSum：加减运算Product：乘运算Dot Product：点乘运算Gain：比例运算Math Function：包括指数函数、对数函数、求平方、开根号等常用数学函数Trigonometric Function：三角函数;包括正弦、余弦、正切等MinMax：最值运算Abs：取绝对值Sign：符号函数Logical Operator：逻辑运算Relational Operator：关系运算Complex to Magnitude-Angle：由复数输入转为幅值和相角输出Magnitude-Angle to Complex：由幅值和相角输入合成复数输出Complex to Real-Imag：由复数输入转为实部和虚部输出Real-Imag to Complex：由实部和虚部输入合成复数输出非线性模块Nonlinear nonlinear.mdlSaturation：饱和输出;让输出超过某一值时能够饱和..Relay：滞环比较器;限制输出值在某一范围内变化..Switch：开关选择;当第二个输入端大于临界值时;输出由第一个输入端而来;否则输出由第三个输入端而来..Manual Switch：手动选择开关信号和系统模块Signal&Systems sigsys.mdlIn1：输入端..Out1：输出端..Mux：将多个单一输入转化为一个复合输出..Demux：将一个复合输入转化为多个单一输出..Ground：连接到没有连接到的输入端..Terminator：连接到没有连接到的输出端..SubSystem：建立新的封装Mask功能模块接收器模块Sinks sinks.mdlScope：示波器..XY Graph：显示二维图形..To Workspace：将输出写入MA TLAB的工作空间..To File.mat：将输出写入数据文件..输入源模块Sources sources.mdlConstant：常数信号..Clock：时钟信号..From Workspace：来自MA TLAB的工作空间..From File.mat：来自数据文件..Pulse Generator：脉冲发生器..Repeating Sequence：重复信号..Signal Generator：信号发生器;可以产生正弦、方波、锯齿波及随意波..Sine Wave：正弦波信号..Step：阶跃波信号..在MA TLAB命令窗口下直接运行一个已经存在的simulink模型t;x;y=sim'model';timespan;option;ut其中;t为返回的仿真时间向量；x为返回的状态矩阵；y为返回的输出矩阵；model为系统Simulink模型文件名;timespan为仿真时间; option为仿真参数选择项;由simset设置; ut 为选择外部产生输入;ut=T;u1;u2;...;un..Sources库信号源库无输入;至少一个输出Sine Wave: 产生幅值、频率可设置的正弦波信号..Step: 产生幅值、阶跃时间可设置的阶跃信号..Sinks库显示和写模块输出Display: 数字表;显示指定模块的输出数值XY Graph: 用同一图形窗口;显示X-Y坐标的图形需现在参数对话框中设置每个坐标的变化范围..Scope: 示波器..显示在仿真过程中产生的信号波形..Continuous库包含描述线性函数的模块Derivative: 微分环节..其输出为其输入信号的微分..Integrator: 积分环节..其输出为其输入信号的积分..Transfer Fcn: 分子分母为多项式形式的传递函数Zero-Poles: 零极点增益形式的传递函数..Math库包含描述一般数学函数的模块..AddSign: 符号函数..输出为输入信号的符号Math function: 实现一个数学函数..Signals & Systems 库Demux: 信号分路器..将混路器输出的信号依照原来的构成方法分解成多路信号..Mux: 信号汇总器..将多路信号依照向量的形式混合成一路信号..Simulink环境下的仿真运行仿真参数对话框Solver页设置仿真开始和终止时间Solver options仿真算法选择：分为定步长算法和变步长算法离散系统一般默认选择定步长算法;在实时控制中则必须选用定步长算法变步长算法;对连续系统仿真一般选择ode45;步长范围用auto Error Tolerance误差限度：算法的误差是指当前状态值与当前状态估计值的误差;分为Relative tolerance相对限度和Absolute tolerance绝对限度;通常可选auto..。

非平滑非负矩阵分解及其应用研究的开题报告1. 研究背景矩阵分解在机器学习和数据挖掘等领域中具有广泛应用，因为它可以将高维数据映射到低维空间，并且可以从中提取出有用的信息。

在实际应用中，许多矩阵是非负的，例如信号处理、图像处理和文本处理等领域中的矩阵。

因此，非负矩阵分解（NMF）在这些领域中也被广泛应用。

然而，传统的NMF方法假设原始矩阵是平滑的，这在许多实际应用中并不成立。

例如，图像处理中的局部变化和噪声可能导致原始矩阵成为非平滑矩阵。

为了解决这个问题，非平滑NMF（NSNMF）被提出。

2. 研究内容本研究的主要内容是非平滑NMF及其应用。

具体而言，将研究以下内容：（1）非平滑NMF模型及其优化算法：目前较为流行的NSNMF模型有基于稀疏表示的模型、基于低秩表示的模型和基于张量分解的模型等。

针对不同的应用需求，需要选择合适的NSNMF模型。

此外，为了提高模型的准确性和效率，需要研究相应的优化算法。

（2）基于NSNMF的图像处理：图像处理是NSNMF的重要应用领域之一。

通过NSNMF可以实现图像分割、去噪、压缩等功能。

本研究将探讨NSNMF在图像处理中的应用，以及如何选择合适的NSNMF模型和算法。

（3）基于NSNMF的文本处理：文本处理是另一个重要的NSNMF应用领域。

通过NSNMF可以实现文本分类、主题提取、情感分析等功能。

本研究将探讨NSNMF在文本处理中的应用，以及如何选择合适的NSNMF模型和算法。

3. 研究意义本研究的意义如下：（1）探讨NSNMF在非平滑矩阵分解中的应用，为相关领域的研究提供重要思路和参考。

（2）研究NSNMF模型及其优化算法，提高NSNMF的准确性和效率。

（3）开发基于NSNMF的图像处理和文本处理算法，并验证其有效性。

4. 研究方法本研究将采用以下方法：（1）对NSNMF模型进行分析和比较，选择合适的模型。

（2）设计相应的NSNMF优化算法，提高模型的准确性和效率。

稀疏矩阵csr存储规则
稀疏矩阵CSR存储规则是一种用于高效存储和处理稀疏矩阵的方法。

稀疏矩阵是指大部分元素为零的矩阵，而CSR（Compressed Sparse Row）存储规则则是一种基于行压缩的存储方式。

在CSR存储规则中，矩阵被分解为三个数组，值数组（values array）、列索引数组（column index array）和行偏移数组（row offset array）。

这种方式的存储规则可以大大减少存储空间，并且能够提高矩阵运算的效率。

在值数组中，存储了矩阵中所有非零元素的值，按照它们在矩阵中出现的顺序排列。

列索引数组则存储了每个非零元素所在的列号，而行偏移数组则记录了每一行的第一个非零元素在值数组中的位置。

通过这种存储方式，我们可以快速定位矩阵中的非零元素，并且能够高效地进行矩阵运算，比如矩阵乘法、矩阵向量乘法等。

这对于处理大规模稀疏矩阵的应用非常重要，比如在图像处理、网络分析、物理模拟等领域。

总的来说，稀疏矩阵CSR存储规则是一种非常有效的矩阵存储和处理方法，能够帮助我们更高效地处理大规模稀疏矩阵，提高计算效率，减少内存占用。

这种存储规则在实际应用中得到了广泛的应用，对于处理大规模数据和复杂计算任务有着重要的意义。

GTSAM原理介绍GTSAM（Generalized Trajectory and Sparse Factor Graphs Optimization）是一个用于非线性优化的开源库，专注于传感器数据处理和SLAM（Simultaneous Localization and Mapping）问题。

它是一个基于因子图的优化框架，可以在不同传感器数据的基础上进行状态估计和地图构建。

为什么选择GTSAMGTSAM的设计目标是提供一个高效、灵活和易于使用的非线性优化框架。

相比于其他优化库，GTSAM具有以下优势： 1. 因子图表示：GTSAM使用因子图来表示问题，将状态变量和约束关系以图的形式表示出来，使得问题更加直观和可理解。

2.稀疏性：GTSAM利用问题的稀疏性，只存储和处理非零元素，大大减少了计算和存储的复杂度。

3. 高效性：GTSAM使用了一些高效的优化算法和数据结构，如QR分解、Cholesky分解等，以提高计算效率。

4. 可扩展性：GTSAM支持自定义因子和变量类型，可以根据具体问题进行扩展和定制。

GTSAM的基本原理GTSAM的基本原理是基于因子图的优化。

因子图是一种用于表示概率模型的图结构，其中节点表示变量，边表示变量之间的关系。

在GTSAM中，因子图由变量节点和因子节点组成，变量节点表示状态变量，因子节点表示约束关系。

变量节点在GTSAM中，变量节点表示状态变量，可以是连续变量、离散变量或者混合变量。

每个变量节点都有一个唯一的ID和一个值。

变量节点的值可以是一个向量、一个矩阵或者其他自定义的数据类型。

因子节点在GTSAM中，因子节点表示约束关系，用于描述传感器测量或其他先验知识。

每个因子节点都有一个唯一的ID和一个因子函数。

因子函数是一个函数，接受一组变量作为输入，并返回一个代价值。

因子函数可以是线性函数、非线性函数或其他自定义的函数。

优化问题在GTSAM中，优化问题可以表示为最小化一个代价函数的问题，代价函数是所有因子函数的加权和。