sgem fp2 d6.1.8 v0.6 - sgemfinalreport.fisgemfinalreport.fi/files/sgem_fp2_d6.1.8.pdf · an outage...

- 1 - D6.1.8: Traffic requirements and dimensioning for smart grids communications

CLEEN OY Eteläranta 10, P.O. BOX 10, FI-00131 HELSINKI, FINLAND www.cleen.fi

D6.1.8: Traffic requirements and dimensioning for smart grids

communications Revision History

Edition Date Status Editor

v0.01 Created

J. Haapola, J. Markkula, A. Avvaru, K. Singh

V0.1 Updated J. Markkula

V0.2 Input J. Markkula, A. Avvaru, K. Singh

V0.3 11.3.2012 Input and consolidation J. Haapola

V0.4 13.3.2012 Comments, Interim Ready J. Markkula

V0.5 22.3.2012 Updated results J. Markkula

V0.6 30.3.2012 Finalisation of Deliverable J. Haapola

Abstract This report describes the scenario and the assumptions under which the traffic requirements and dimensioning studies have been conducted for SGEM FP2 along with the results obtained. The document also describes the performance metrics of interest in these evaluations and the methodology for obtaining the results.



Table of Contents D6.1.8: Traffic requirements and dimensioning for smart grids communications ............. 1 Revision History .............................................................................................................................. 1 Abstract ............................................................................................................................................ 1 Table of Contents ............................................................................................................................ 2 1 Preface ........................................................................................................................................ 3 2 Scope .......................................................................................................................................... 3 3 Introduction ................................................................................................................................ 4 4 Evaluated Topology – Suburban Environment ....................................................................... 4 5 Overview of power outage management in smart grids ........................................................ 7

5.1 Outage Notification Scenario ................................................................................................ 7 6 Assumptions on LTE ................................................................................................................. 9

6.1 Key parameters ..................................................................................................................... 9 6.2 Simulation scenarios ........................................................................................................... 14

6.2.1 Normal AMR traffic ....................................................................................................... 15 6.2.2 Emergency traffic ......................................................................................................... 15 6.2.3 Emergency traffic generation with uniform distribution ................................................. 15 6.2.4 Background traffic ........................................................................................................ 16 6.2.5 Normal AMR traffic with background traffic .................................................................. 17 6.2.6 Emergency traffic with background traffic .................................................................... 17 6.2.7 Two-way normal AMR traffic with background traffic ................................................... 18 6.2.8 Long Term Evolution Uplink and Downlink Traffic ........................................................ 18

7 Metrics and Evaluation Methodology .................................................................................... 19 8 Simulation results ................................................................................................................... 20

8.1 Normal AMR traffic .............................................................................................................. 20 8.2 Emergency traffic ................................................................................................................ 24 8.3 Emergency traffic generation with uniform distribution ....................................................... 26 8.4 Background traffic ............................................................................................................... 29 8.5 Normal AMR traffic with background traffic ......................................................................... 31 8.6 Emergency traffic with background traffic ........................................................................... 33 8.7 Two-way normal AMR traffic with background traffic .......................................................... 35 8.8 Packet delivery ratios in scenarios with background traffic ................................................. 37

9 Conclusions ............................................................................................................................. 38 References ..................................................................................................................................... 40



1 Preface This report was done as a part of the Finnish national research project "Smart Grid and Energy Market" SGEM. It was funded by Tekes – the Finnish Funding Agency for Technology and Innovation and the project partners. We would also like to thank our partners from NSN and University of Eastern Finland for their valuable input to make our simulations more realistic in terms of functional and non-functional requirements.

2 Scope The scope of this deliverable is to describe the scenario, the assumptions, and results for our simulation work in SGEM Funding Period 2. The key research tool used is Opnet Modeler with Wireless Suite and LTE simulation toolboxes. The results achieved by our simulations elaborate dimensioning studies in a generalised sub-urban smart grid environment. As requirements are in a key role for determining the outputs of simulations, they have been described in detail and we have attempted to take as realistic assumptions as possible for the simulation parameters. The deliverable addresses an extensive set of simulations for smart metering considering average and peak loads of LTE-equipped AMR meters with and without background traffic of the network. The background traffic consists of multiple types of traffic, some with different priorities.



3 Introduction This deliverable describes the simulation setups and assumptions under which the impact of smart grid traffic is evaluated in suburban environments. The document starts with defining an instantiation of a suburban environment and a generalisation of that into a usable model. As we are especially interested in the impact of peak events (power outage, etc.) that may have a significant effect on the performance of the network, a concise description of such events is given. Furthermore, the simulations have a significantly large set of simulation parameter, each of which has an effect on the results of the simulations. The key parameters are discussed in more detail to give an understanding of the entire simulation setup. The simulation scenarios are then described and contain setups for normal and emergency traffic, with and without background traffic and one or two-way communication. In addition, the background traffic breakdown is presented. The metrics of evaluation are briefly described and simulation results are presented in Section 8. The conclusions are drawn in Section 9.

4 Evaluated Topology – Suburban Environment As a start, we chose a suburban environment, as depicted in Figure 4-1, to start building up the scenario. The suburb of Jääli, in Kiminki largely consists of houses instead of apartment buildings or row houses and hence, the building and AMR remote terminal unit (RTU) density is lower than in ones with many apartment block buildings. However, the estimated number of RTU units corresponds reasonably well with a model, depicted in Figure 4-2, based on real data on AMR meters.



Figure 4-1: Jääli suburb in Kiiminki. An approximate scenario on the number of AMR meters in a suburban area. The example case is a suburb with majority of houses, some row houses and a few low-rise apartment block buildings. The terrain is quite flat in the region and buildings are clustered based on when a particular expansion of the suburb has been constructed. Overall, it can be deduced from Figure 4-1 that the clusters’ dimensions are roughly 150m by 150m and contain approximately 25 buildings. There are about 30 of such clusters in the area that is contained in a region of 2.5 km by 1.5 km (although it has a rather triangular shape). The total number of AMR RTUs is therefore expected to be around 750 units in the area. It is envisioned that a single LTE cell, using 1805-1880 MHz frequency band, could cover this area. The assumption is that while people living in the suburban environment have the freedom of using any available LTE carrier for their mobile terminals and data units, all of the RTUs are serviced by a single LTE carrier. The RF environment will be mostly free space, light trees, and houses being the main obstructions for communications. A typical 30 m elevated base station antenna element can be considered.

50 100 150 200 250 300 350

50

100

150

200

250

300

350

Observed

Pre

dict

ed

Sites #reg (IA: 0.98815 R2: 0.9543 RMSE: 4.5067)

Figure 4-2: Prediction vs. Observation of the number of AMR meters in a suburban

environment grid of size 250 by 250 m. Courtesy of Department of Environmental Science, University of Eastern Finland.

However, we are not only interested in a particular instantiation of a suburban environment setting and therefore we generalise the environment. From Figure 4-1, we identify that the buildings are typically clustered into groups and the size of the groups tends to be more or less uniform. Roads,



parks, streams and ponds typically separate the clusters. Inside the cluster, buildings (and AMR meters) have less order due to freedom of positioning buildings in the area. As a consequence, the suburban environment is generalised to the following. Simulation topology consists of a suburban area that is presented in Figure 4-3. The suburban area is divided into 30 clusters, each containing 25 and, in total 750, houses/apartments with AMR units. Each house/apartment has one RTU that is wirelessly connected with an LTE-network eNodeB (base station). The RTUs are randomly (uniform distribution) positioned inside every cluster at the start of the each simulation run. The purpose of the random placement is to let the AMR units to be placed in various locations, not dictated by municipal planning as is usual in real environments. The clusters represent locations of municipal planning, separated by roads, parks, etc., where groups of houses/apartments are usually constructed (especially in temporally phased construction zones).

Cluster 125 RTUs 2 3 4 5

66 7 8 9 10

11 12 13 14 15

16 17 18 19 20

21 22 23 24 25

26 27 28 29 30

eNodeB, EPC,

Server

790 m

950 m

10 m

150 m

150 m Figure 4-3. Evaluated topology with 750 RTUs.



5 Overview of power outage management in smart grids Smart grids use Outage Management Systems (OMS) with graphical user interfaces to detect outages. An outage is defined as loss of configurable amount of voltage for a configurable amount of time [7]. Trouble call handling, outage analysis and prediction, crew management and reliability reporting are some of the major functions of OMS. Outage management in smart grid can be analyzed based on the three methods [8]: • Integration of Advanced Metering Infrastructure (AMI) data in OMS • Advanced applications to support outage • Integration of Supervisory Control and Data Acquisition (SCADA) and Distribution Management

(DMS) and OMS. AMI data integration in OMS has mainly three functionalities: • AMI meters and communications are so equipped that OMS receive the last gasp or outage

notification from the meter even if the customer does not report the outage. • Proper interface between the OMS and AMI system with the right communication infrastructure

so that the message can be sent from OMS to the meter about its service (It is used to detect the outage whether customer side or distributed network side)

• Restoration notifications are used in handling the outage notification status whether the issue resolved or not.

Advanced applications are used for fault detection using different technologies. Some of the specific examples are: • DMS application, which is used for fault location using circuit connectivity, location of open

switches and impedances of conductor segments • Restoration and Switching Analysis is another application which evaluates all possible

switching options to eradicate permanent faults in the electrical network. Integrated SCADA/DMS/OMS means: • Transfer of status/analog points from SCADA to the DMS/OMS • Sending supervisory control and manual override commands from DMS/OMS to the SCADA • Integrated user interface running on operator console and sign-on for users. In this deliverable we are interested in the solution (Integration of Advanced Metering Infrastructure data in OMS) with the right communication interface and the requirements for establishing the communication to send outage and restore notification. To implement the communication between the network manager (SCADA, DMS) and AMI is the area of research. We are interested in the payload and the frame requirements for outage notification.

5.1 Outage Notification Scenario The last gasp message is the outage notification in AMI network. A last gasp message outage notification works differently with different AMI technologies [7]. Generally, the smart meter Network Interface Card (NIC) produces the outage notification or the last gasp message when it



detects zero voltage event lasting for more than 45 seconds [9]. The last gasp message is routed through the AMI network to the AMI head end. The AMI head end publishes the message to the Meter Outage Processor (MOP) and the Operational Data Store (ODS). In most commercially deployed smart meters the occurrences of outage notification is time stamped. The restoration notification is used to intimate the head end when the configurable threshold value for a configurable amount of time is achieved [7].

Figure 5-1; Last gasp notification [9].

The interface 3 in the last gasp notification of Figure 5-1 is of main interest and the requirements for realising outage notification can be discovered from the from NIST SG Requirements [10]. The use case ME-10 (Meter Event 10) signifies the fault error alarm event according to NIST. The requirements for the event to occur are:

Table 1: Outage reporting requirements

Use Case Name ME-10 Interface 1D Reliability >98 % Latency Response (one direction) <30 s Direction Smart Meter to DAP Payload 25 -278 bytes Implication Fault/error/alarm Event could indicate a major problem Frequency of Occurrence 4 per month per 1K meters



6 Assumptions on LTE This section defines the parameters essential for configuring our simulations. Firstly, we introduce key parameters that concern the RTUs and the eNodeB. Secondly, we address the traffic parameters of the simulations.

6.1 Key parameters Key parameters for the simulation scenarios are selected based on SGEM deliverable D6.1.1 [4] and they are presented in Table 2. Quality of Service (QoS) class identifier number 9 signifies that there is no guaranteed bit-rate (non-GBR) value for the transmitted data [5]. Link adaptation and channel dependent scheduling mode signifies that also RTUs will take measurements on various sub-bands and calculate separate modulation and coding scheme (MCS) indexes for each sub-band. The eNodeB will try to match the RTUs to their preferred sub-bands, perform link adaptation and create wideband MCS index. If the eNodeB can put the RTU in one of its preferred sub-bands, and if the MCS index of that sub-band is higher than the wideband MCS index, the eNodeB will use the sub-band MCS index and optimise frame resources. The used path-loss model type, suburban macrocell, is based on COST 231 Hata path-loss model [2]. Terrain type C corresponds to mostly flat terrain with light tree densities. Path loss from obstacles signifies that there are from 0 to 2, randomly selected, walls between each RTU and the eNodeB. The wall pass through path loss represents a case where the placement of the AMR unit varies from yard installation to inside of structures. Each wall attenuates the signal by 6 dB [11]. Table 2: Key parameters for the simulation scenarios.

Parameter RTU eNodeBTx antenna gain -‐2 dBi 16,5 dBiBand width 10 MHz (UL) 10 MHz (DL)Transmission power 0,2 W 39,8 WReceiver sensitivity -‐106,5 dBm -‐120,7 dBmAntenna height 1.5 m 30 mBase frequency 1800 MHz 1990 MHzQoS class identifierRLC modeMaximum number of retransmissionsScheduling mode Link adaption and Channel Dependent SchedulingPathloss Suburban macrocell, terrain type C, path loss from obstacles -‐6dB * (0,1,2)

9 (non-‐GBR)Acknowledged

4

6.1.1 Listing of key simulation parameters Below is a brief elaboration of tunable simulation parameters. All of them have an effect on the simulations and they require careful selection. [12] 6.1.1.1 Antenna Gain



The attribute can be used to bypass the antenna gain computations at a node and use a provided gain value for all directions. Alternatively, setting the attribute to “Use Antenna Model” can use an external antenna model. In our simulations we use the antenna gains defined in Table 2. 6.1.1.2 Battery Capacity Battery Capacity is the total energy stored in the power supply (battery) of the device in Watt-Hours. In our simulations, RTUs and eNodeB are considered mains powered and with sufficient battery capacity to communicate in short-term emergency scenarios. 6.1.1.3 Operating power Operating Power represents the power consumption of the device for all purposes other than packet transmission in Watts. This parameter is not relevant in this operation scenario. 6.1.1.4 Path Loss Model The attribute specifies the type of path-loss model to be applied to received signals. Each path-loss model is appropriate for a certain kind of environment through which the signal propagates before reaching the receiver. The current alternatives in the simulator are:

• The "Free Space" path-loss model refers to the classical free space path-loss. • The "Suburban Fixed (Erceg)" path-loss model is defined in: V. Erceg et al., "An empirically

based path loss model for wireless channels in suburban environments", IEEE JSAC, vol.17, no.7, July 1999, pp. 1205-1222. Erceg's model is also referenced in IEEE802.16a-03/01 document.

• The "Outdoor to Indoor and Pedestrian Environment" and the "Vehicular Environment" are pathloss models described in the "Radio Tx Technologies for IMT2000" white paper of the ITU.

• The "Suburban Macrocell", "Urban Macrocell" and "Urban Microcell" models are described in 3GPP TR 25.996 v8.0.0, and are based on COST 231 Hata and Walfish-Ikegami path-loss models respectively.

6.1.1.5 Terrain Type This attribute setting is taken into consideration only when the Path-loss Model attribute is set to "Suburban Fixed (Erceg)". The terrain type setting of the Suburban Fixed (Erceg) path-loss model adjusts the model to the one of the three most common types of terrain found across the United States, as follows:

• Terrain Type A corresponds to hilly terrain with moderate-to-heavy tree densities • Terrain Type C corresponds to mostly flat terrain with light tree densities • Terrain Type B corresponds to a compromise between the terrains A and C

6.1.1.6 Macrocell Path-Loss Model D6.1.7 [1] document details extensively all the available and possible options for smart grid environments. It explains the empirical, the semi-empirical and the deterministic models for narrowband and wideband modeling of propagation loss in radio channels. The propagation model, which can be a perfect fit for smart grid environments with respect to the topology Section 4 can be Suburban Macro cell path-loss model specified by 3GPP [2].



Based on the terrain type and the path-loss to the signal from transmission to reception, Suburban Macro cell is chosen. We choose the path-loss parameters as shown in Figure 6-1 for the modeler. The terrain type C is the flat terrain with low density of trees. The literature regarding the terrain and parameters related can be found in [3] and the documentation behind the Suburban Macro cell model can be found in [2].

Figure 6-1: Snapshot if Simulator parameter Selection regarding path-loss. The parameters for suburban macrocell from the 3gpp document are shown in Table 3.

Table 3: Path Loss Channel Scenario [2]

The generalised macrocell path-loss is given by the formula from the 3gpp document is shown in the table above. But while specifically using the terrain type C the path-loss (PL) formula is [3]

where A is a constant based on free-space model and is



. The path Loss Component γ

, and the shadow fading (s) component s= yσ, where , a,b,c σy are data driven constants, do is a reference distance (100 m), λ is the wavelength, σ is the standard deviation of s,µσ (the mean of σ), hb is the height of the base station antenna, y,z are zero mean Gaussian random variables of unit standard deviation N[0,1], and d is the distance between the transmitter and receiver The numeric constants of the path-loss component can be found from the Table 4.

Table 4: Path-loss component values

6.1.1.7 Shadow Fading Standard Deviation Model Shadow fading is an additive correction (in dB) to the path-loss experienced by the received signal. The shadow fading term is introduced to model as the site-specific departure from the generic path-loss model due to obstructions in the signal path. To cover a big variety of sites, the shadow fading is assumed to be a normally distributed zero-mean random variable when expressed in dB. When expressed in watts, the shadow fading is log-normally distributed. In the simulations, shadow fading is not used, but a randomly selected number of wall penetrations, with the associated path-loss, is taken into account. 6.1.1.8 Maximum Power transmission



The power specified in this attribute refers to the total transmission power that a transmitter can output over the entire channel bandwidth. If the transmission occurs over a fraction of the available bandwidth (a subset of the total subcarrier set), then the power is scaled down proportionally to this fraction. This is a consequence of the fact that the power output per subcarrier is invariant from one transmission to another. Table 2 presents the respective transmission powers of RTUs and the eNodeB. 6.1.1.9 LTE PHY Profile The name of the PHY profile used by the eNodeB. PHY profiles are defined in the LTE configuration objects. 6.1.1.9.1 Receiver Sensitivity The parameter defines the minimum received power threshold value of the radio receiver in dBm for arriving packets. Packets with a power less than the threshold are not sensed and decoded by the receiver. The status of such packets is set to noise. The packets whose received power is higher than threshold are considered as valid packets. The receiver sensitivity is defined in Table 2. 6.1.1.9.2 LTE EPS bearer This attribute allows definition of EPS bearers that will be selected by the LTE UEs, and consequently be deployed in LTE networks. UEs will refer to the names of the bearers to choose the ones they want to use. For each selected bearer, a UE will define a traffic flow template to specify which higher layer data flows will be mapped to that bearer. 6.1.1.9.3 QoS Class Identifier The QoS Class Idenfier (QCI) value of the EPS bearer determines the QoS Class Definition of the bearer. QoS Class Definition that corresponds to each QCI value is specified in Table 6.1.7 of 3GPP 23.303 v8.3.1 (Release 8) document. Allowed value range is from 1 to 9. QCI 9 is also used internally for the default bearer. Bearers with QCI value from 1 to 4 are GBR bearers, and the ones with QCI value from 5 to 9 are non-GBR bearers. In the simulations non-GBR QCI values are used. 6.1.1.9.4 Uplink Guaranteed Bit rate (bps) This attribute specifies the guaranteed bit rate for this EPS bearer in the uplink. This attribute is taken into account only for GBR bearers. 6.1.1.9.5 Downlink Guaranteed Bit rate (bps) This attribute specifies the guaranteed bit rate for this EPS bearer in the downlink. This attribute is taken into account only for GBR bearers. 6.1.1.9.6 Uplink Single Carrier-FDMA Channel Configuration The parameter defines the LTE SC-FDMA uplink transmission bandwidth configuration. 6.1.1.9.7 Base Frequency (Ghz) The parameter defines the minimum frequency of the uplink transmission bandwidth for the Type 1 (FDD based) LTE PHY profile. Here the 1800 MHz frequency band is used.



6.1.1.9.8 DL OFDMA Channel Configuration The parameter defines the LTE OFDMA downlink transmission bandwidth configuration. 6.1.1.9.9 TFT Packet Filter The attribute specifies the match criteria for mapping higher layer traffic to EPS bearers. The filters are applied in the same order they are defined under this attribute. 6.1.1.9.10 Serving Enode ID The parameter specifies the eNodeB selection method. Use of this attribute depends on the efficiency mode.

• In "Efficiency Enabled" mode: When an explicit eNodeB is specified, a check is performed to ensure that the eNodeB services the EPC configured on the UE. If so, the UE selects this eNodeB irrespective of distance or power. If the eNode doesn't service the EPC configured on the UE, then the UE defaults to "Perform Cell Search" procedure.

o In the "Perform Cell Search" procedure, the UE selects the best (distance-based) eNode from the set of eNodeBs that service the EPC configured on the UE. If no such eNodeB is found then the UE persists with cell search.

• In "Physical Layer Enabled" mode: When an explicit eNodeB is specified, a check is performed to ensure that the eNodeB services the EPC configured on the UE. If so, the UE searches the frequency of the specified eNodeB first. The specified eNodeB will be selected if it meets "Cell Selection Criteria", even if it is not the best eNodeB. If the specified eNodeB does not service the EPC or if it does not meet the selection criteria or if it is not discoverd then the UE will default to "Perform Cell Search" procedure.

o In the "Perform Cell Search" procedure, the UE scans the frequencies of the eNodeBs servicing the EPC configured on the UE. In each frequency, the best eNodeB is evaluated based on Reference Signal Received Power (RSRP). If the best eNodeB (in a particular frequency) services the EPC and meets "Cell Selection Criteria" then it is short-listed. If the "Cell Selection Policy" is set to "First Suitable eNodeB" then the first short-listed eNodeB is selected by the UE. If the policy is set to "Best Suitable eNodeB" then the best eNodeB amongst the short-listed eNodeBs is selected by the UE.

In the simulations, “Efficiency Enabled” is selected with an explicit eNodeB that services the EPC used in the scenario.

6.2 Simulation scenarios We have a number of simulations scenarios that cover

• regular AMR communications with and without background traffic, • stand-alone emergency traffic, • stand-alone background traffic, • stand-alone emergency traffic with randomly delayed last gasp messages with and without

background traffic, and • two-way, regular AMR communications with background traffic.



The purpose of the scenarios is to enable us to identify what aspects of LTE-based smart grid communications affect the overall results and by how much.

6.2.1 Normal AMR traffic

In the first simulation scenario, all 750 RTUs transmit automatic meter reading (AMR) traffic to a server located somewhere beyond the evolved packet core (EPC). AMR traffic generation parameters are presented in Table 5. With 750 RTUs, the time taken for one-hour simulation would be excessively high due to the high amount of signaling and command traffic. For this reason, only one RTU per cluster of Figure 4-3 is transmitting AMR traffic to server. The volume of traffic is however, the same, as 25 RTUs would generate in total.

Table 5: Traffic generation parameters per RTU

Data type start time Generation interval Payload data Simulation durationAMR data random 5-‐20 min 15 min 250 B 1 h

6.2.2 Emergency traffic

In the second simulation scenario, in addition to the normal AMR traffic, which is now generated by all RTUs in a cluster, also emergency traffic (information on blackout, phase failure, etc.) is generated by RTUs to inform about possible failures. Traffic generation parameters for the simulation scenario are presented in Table 6. Emergency traffic is generated at the same time instance by the all RTUs. The simulator produced a memory failure when generating emergency traffic with 750 RTUs. Thus, the number of RTUs in the simulation had to be reduced to 500, which was a maximum operational limit of the simulator. To make the simulation runs temporally tolerable, 190-second simulation time was selected.


Data type start time Generation interval Payload data Simulation durationAMR data random 2-‐17 min 15 min 250 BEmergency data 2 min 30 s 100 B

190 s

6.2.3 Emergency traffic generation with uniform distribution The purpose of the scenario is to improve emergency traffic transmissions. Traffic generation parameters are presented in Table 7. Instead of all RTUs generating emergency traffic at the same time instance like in scenario 6.2.2, each RTU generates emergency traffic by adding random value to generation start time. The value is selected by the uniform distribution on the interval [0-1] s. Thus, all 750 RTUs generate emergency traffic packet inside the one second. When we consider that the last gasp message delay tolerance from Table 1 is less than 30 s, this the random delay is acceptable and forms an optimisation of the scenario.




Data type start time Generation interval Payload data Simulation durationAMR data random 5-‐20 min 15 min 250 BEmergency data 5 min + uniform [0-‐1] s 10 min 100 B

1 h

6.2.4 Background traffic Background traffic (BG) that corresponds to typical traffic in LTE network is preliminary specified in Table 14 and Table 15. More specific definition of the BG traffic application types is presented in this section. Also, simulations with only BG traffic are performed. The attributes of the selected traffic types are presented in Table 8. Each of the 930 UE generates BG traffic with random generation start times of each traffic application type. These application types are selected such that the amount of the traffic corresponds to 55 min simulation time because five first minutes of the simulation is reserved for the network initialization, i.e., during the five first minutes there is not any BG traffic generation. With BG traffic, acknowledgement packets are not applied in contrary to smart grid (SG) traffic.

Table 8: Attributes of the selected traffic application types

Application type generation start time [s] Interval [s] duration DirectionVoice Ip telephony and Silence supressed uniform(300 -‐ 3462.5) 137.5 s UL, DLVideo conference 128×120 pixels, 17.28 kB/ packet uniform(300 -‐ 3597.25) constant (0.1) 2.75 s UL, DLStreaming 15 kB/s, 1 kB/packet uniform(300 -‐ 3545) constant(0.0666) 55 s DLHTTP uniform (11-‐51) kB/page uniform(300 -‐ 3570) constant(25) 2 pages DLFTP 2670.5 kB/file uniform(300 -‐ 3555) 1 file DL Table 9 presents the details of IP telephony and Silence suppressed voice application specified in Table 8 [12].

Table 9: IP telephony and Silence suppressed voice application details

Voice Ip telephony and Silence supressedSilence Length exponential (0.65)Talk Sprut Length exponential (0.352)Encoder scheme G.729 A (silence)Voice Frames per Packet 1Compression delay [s] 0.02Decompression delay [s] 0.02

The evolved packet system (EPS) definitions are presented in Table 10 for the voice and videoconference applications [13]. Allocation retention policy is a priority used in admission control to preempt one or more lower priority guaranteed bit rate (GBR) bearers to admit higher priority to GBR bearer [12]. A smaller value signifies better priority. Network operators commonly select GBR



values. GBR values for these simulations were selected corresponding to amount of the generated voice and videoconference traffic so that packet delays were kept at a sufficiently low level. GBR value is the same for both directions, UL and DL. All the other BG traffic applications applied QoS class identifier number 9 (non-GBR) [12].

Table 10: EPS bearer definitions of the GBR BG traffic applications

QoS class identifier Allocation retention priority Guaranteed bit rate Voice 1 (GBR) 2 96 Kb/sVideo conference 2 (GBR) 4 1.5 Mb/s

Table 11 presents the generated BG traffic per UE when traffic is generated during 55 min. Table 11: Generated BG traffic per UE when traffic is generated during 55 min.

Application DL [kB] UL [kB] SUM [kB]Voice 49.5 49.5 99Video conference 475.2 475.2 950.4Streaming 825 0.512 825.5HTTP 22 -‐102 4.2 26.2 -‐106.2FTP 2670.5 0.512 2671Total 4042.2 -‐4122.2 (~88 %) 529.9 (~12 %) 4572.1-‐ 4652.1 Table 12 presents, per cluster and totally, generated BG traffic. A cluster contains 31 BG nodes. Totally there are 30 clusters, like in Figure 4-3, containing a total of 930 BG nodes. To reduce the time spent for simulation, only one node per cluster generates BG traffic. The volume of traffic is however, the same as 31 UEs would generate in total.

Table 12: Generated BG traffic when traffic is generated during 55 min

BG traffic Per cluster [MB] Total [MB] Total [MB/s]UL 16.4 492.8 0.15 (12%)DL 125.3 -‐ 127.8 3759.2 -‐ 3833.6 1.14 -‐ 1.16 (88 %)total 142.7-‐144.2 4252-‐4326.4 1.29 -‐ 1.31

6.2.5 Normal AMR traffic with background traffic

In addition to traffic scenario 6.2.1, also background traffic presented in Section 6.2.4 is generated in the network by regular UEs. The goal is to simulate, how normal AMR traffic affects the typical LTE traffic produced by UE.

6.2.6 Emergency traffic with background traffic



In addition to traffic specified in scenario 6.2.3, also background traffic presented in the previous scenario 6.2.4 is generated by regular UEs. The objective is to simulate the effect of emergency traffic in conjunction with normal AMR traffic on typical LTE traffic produced by UE.

6.2.7 Two-way normal AMR traffic with background traffic The scenario repeats the simulations of scenario 6.2.5 when also the server generates AMR data (Tarif updates, reconfiguration, etc.) in downlink direction. Traffic generation parameters for the simulation scenario are presented in Table 13. The server generates 750 packets evenly between the clusters, i.e., 1 packet is generated for each RTU with a repeating cycle. The downlink packet generation is evenly distributed throughout the generation time interval so as to not burden the network with unnecessary large simultaneous generation of data packets.

Table 13: Traffic generation parameters

Data type start time Generation interval Payload data Simulation durationAMR data (uplink) random 5-‐20 min 15 min 250 BAMR data (downlink) 5 min 4.3 s 250 B(750 packets)

1 h

6.2.8 Long Term Evolution Uplink and Downlink Traffic The objective is to calculate the offered traffic values for uplink and downlink traffic. We identify three different kinds of traffic in telecommunication systems.

• Offered Traffic: The traffic generated at the input of the system • Carried Traffic: The traffic serviced in the system • Lost Traffic: The traffic that is not serviced by the system.

We are most concerned with the offered traffic with the network. The parameters and their values can be seen from Table 14.

Table 14: Offered traffic to network Parameter

Description Average Data Produced per user 5 MB / hour (approximately) Number of RTUs 750 (all in single operator network) Number of LTE units in area (Unit may be a mobile terminal or a modem)

750* 3.7 (assume an average Finnish family where number of units equal to number of people)

Number of users per operator network (assume three operators with equal share of users)

925 users/ operator network

Total offered traffic from LTE units / operator 10.277 Mb/s Uplink offered traffic from LTE units / operator 2.06 Mb/s Downlink offered traffic from LTE units / operator 8.20 Mb/s Traffic ratio 4:1 (Downlink:Uplink)



The busy hour traffic model can be designed based on the previous studies done on LTE. The applications for background traffic are found from Table 15.

Table 15: Background traffic applications

Parameter (per subscriber) Session length/size Voice 2.5 min Video 0.05 min Streaming 1 min Web 2 pages FTP 2914 kB Data usage 5 MB/hr

The relevant equations for obtaining the parameters are

• Number of users: 925 users/ operator network • Average data volume per subscriber : 5 MB/hr

Average data rate per subscriber = Average data volume per subscriber [bit] / 3600s Total offered traffic [6] = Number of Subscribes * Average data rate per subscriber. When designing the background traffic for uplink and downlink, they do not pose the same load to the eNodeB. In this deliverable, the uplink is considered approximately 20 percent and downlink approximately 80 percent of the traffic, respectively, more accurate uplink and downlink traffic values are specified when defining more specific application traffic for Opnet modeler in Section 6.2.4. The traffic profile is used to describe the average subscriber behavior during the simulated period of time.

7 Metrics and Evaluation Methodology In the simulation results, load is calculated as a number of sent bytes per second in the network. A single simulation run calculates network load. The average load is calculated from the load by averaging certain number of consecutive samples. 10 simulation runs are performed with varying seed values to average the average load results. Peak load is defined as the maximum amount of the generated load per second during a simulation. Delivery ratio indicates the ratio of the successfully received packets to all generated packets. Network delay represents the duration from packet generation to its reception. In the simulation results, network delay is the average value of packet delays that occurred during one second. Average network delay is calculated from network delay by averaging a certain number of consecutive samples. Average network delay results are still further averaged by 10 simulation runs similar to average load values.



Instead of simulating long operation periods, shorter simulations were repeated 10 times with varying seed values in most cases. Thus, the simulations were performed with 10 averaging setups, e.g., locations of the nodes (and wall penetration losses) were randomly selected inside the specific cluster areas and traffic generation start times were randomly selected at the start of the each simulation run. In this case, the method provides more general results than simulating a longer operating period only once. The evaluated scenarios and used traffic priorities were described in Section 6.2.

8 Simulation results This Section presents the results of the simulation scenarios defined in Section 6.2. Key parameters for the simulation scenarios are presented in Table 2.

8.1 Normal AMR traffic Simulation results of the normal AMR traffic scenario are presented in this Section. Traffic parameters can be found from Table 5. Figure 8-1: shows the average load of AMR traffic as a function of time. The results are averaged between 10 simulation runs. AMR traffic generation starts after 5 minutes. Each of the 750 RTUs generate a packet of 250 B every 15 min with random generation start time. This corresponds to 208.3 B/s theoretical traffic value. From the figure it can be seen that the average load value is approximately same as the theoretical value. Thus, it is illustrated that correct amount of the AMR data is generated by RTUs inside the network. Delivery ratio was 100 %, i.e., the server received all transmitted AMR packets successfully.



0

50

100

150

200

250

0 5 10 15 20 25 30 35 40 45 50 55 60

Ave

rage

loa

d [B

/s]

Time [min]

Figure 8-1: Average load of AMR traffic as a function of time.

Figure 8-2 shows the load of AMR traffic as a function of time. Results are collected during one simulation run. From the curve it can be seen that peak load value is approximately 1,5 kB/s. Theoretically, the peak value of the load could be 750 RTUs multiplied with 250 B, 187,5 kB/s, but it has a negligible probability of occurrence. With 10 simulation runs, the peak value of the load varied between 1000 and 1500 B/s.



0

200

400

600

800

1000

1200

1400

1600

0 5 10 15 20 25 30 35 40 45 50 55 60

Loa

d [B

/s]

Time [min]

Figure 8-2: Load of AMR traffic as a function of time.

Figure 8-3 presents the network delay as a function of time. The results are averaged between 10 simulation runs with different averaging setups. From the figure it can be seen that network delay stays always below 35 ms. Throughout most of the simulations, the average network delay is below 20 ms.



0

5

10

15

20

25

30

35

40

0 5 10 15 20 25 30 35 40 45 50 55 60

Ave

rage

net

wor

k de

lay

[ms]

Time [min]

Figure 8-3: Average delay as a function of time.

Figure 8-4 presents the network delay as a function of time when results are collected during one simulation run. From the figure it can be seen that network delay stays always below 80 ms.



0

10

20

30

40

50

60

70

80

90

0 5 10 15 20 25 30 35 40 45 50 55 60

Net

wor

k de

lay

[ms]

Time [min]

Figure 8-4: Delay as a function of time. From the results of Figure 8-1: to Figure 8-4, we can deduce that regular SG traffic has very little effect on eNodeB or the network load. In addition, without background traffic the delivery ratio and network delay do not pose any obstacles for providing required QoS for smart metering.

8.2 Emergency traffic Simulation results of the emergency traffic scenario are presented in this Section. Traffic parameters can be found from Table 6. Figure 8-5 shows the load and throughput of the emergency and AMR traffic as a function of time. From the figure it can be seen that when 500 RTUs generate emergency packet at the exact same time instance, in the worst case, less than half of the packets can be delivered successfully. Thus, the network capacity is exceeded when generating emergency traffic. Packet delivery ratio for emergency and AMR traffic was 75 %.



0

10

20

30

40

50

60

90 100 110 120 130 140 150 160 170 180 190

Traf

fic [k

B/s]

Time [s]

Load

Throughput

Figure 8-5: Sent and received emergency and AMR traffic as a function of time

Figure 8-6 presents a network delay as a function of time. From the figure it can be seen that network delay is excessive high, even more than ten seconds. While this still satisfies the delay constraint set on the last gasp messages of Table 1, the packet delivery ratio constraint is not met. Hence, we need to alleviate this worst-case of traffic generation. Next we introduce a relatively small random delay in the scheduling of the last gasp messages.



0,01

0,1

1

10

100

90 100 110 120 130 140 150 160 170 180 190

Net

wor

k de

lay

[s]

Time [s] Figure 8-6: Delay over one simulation run of emergency message generation scenario as a

function of time.

8.3 Emergency traffic generation with uniform distribution This Section presents simulation results for the emergency traffic generation with uniform distribution scenario. Traffic parameters can be seen in Table 7. Figure 8-7 shows the load of emergency and AMR traffic as a function of time. From the curve it can be seen that peak load value is 75.25 kB/s. That corresponds to all 750 RTUs generating the emergency packet of 100 B inside the one second and some normal AMR traffic. Delivery ratio was 100 %, i.e., the server received all transmitted emergency and AMR packets successfully. As a conclusion, even a small spreading of emergency messages over time results into a huge improvement in the delivery ratio performance of the system.



0,25

0,75

75,25 75 75 75,25 75

0,1

1

10

100

0 5 10 15 20 25 30 35 40 45 50 55 60

Loa

d [k

B/s]

Time [min]

Figure 8-7: Load of emergency and AMR traffic as a function of time when the traffic has a short time window random delay in scheduling of the packets.

Average network delay as a function of time is presented in Figure 8-8. The network delay with one simulation run is presented in Figure 8-9. From the figures it can be seen that network delay is at a tolerable level. Average network delay is always below 30 ms and any instantaneous network delay stays below 100 ms. Throughout most of the simulations, the average network delay stays below 20 ms. With this setup, the last gasp message constraints of Table 1 are satisfied.



10

12

14

16

18

20

22

24

26

28

30

0 5 10 15 20 25 30 35 40 45 50 55 60

Ave

rage

net

wor

k de

lay

[ms]

Time [min]

Figure 8-8: Average delay as a function of time when the traffic has a short time window random delay in scheduling of the packets.



0

10

20

30

40

50

60

70

80

90

100

0 5 10 15 20 25 30 35 40 45 50 55 60

Net

wor

k de

lay

[ms]

Time [min]

Figure 8-9: Instantaneous delay as a function of time when the traffic has a short time window random delay in scheduling of the packets.

8.4 Background traffic Simulation results of the background traffic scenario are presented in this scenario. Traffic parameters are presented in Table 8. Figure 8-10 shows the average load of the BG traffic applications as a function of time. All of the following simulation results are averaged between 2 simulation runs. Total amount of the all transmitted BG traffic is approximately 1.3 MB/s that correspond well to theoretical value presented in Table 12 (1.29 – 1.31 MB/s). FTP traffic (DL) produces the highest amount of the traffic, about 750 kB/s. Streaming (DL) produces 300 kB/s. Video conference (UL/DL) produces a bit more than 200 kB/s. Voice (UL/DL) a bit less than 30 KB/s and HTTP(DL) a bit less than 20 kB/S.



0

100

200

300

400

500

600

700

800

900

1 000

1 100

1 200

1 300

1 400

0 5 10 15 20 25 30 35 40 45 50 55 60

Ave

rage

loa

d [k

B/s]

Time [min]

Video Conference

FTP

VoiceHTTP

Streaming

Total traffic

Figure 8-10: Average loads of BG traffic components.

Figure 8-11 presents the average network delay as a function of time. From the figure it can be seen that network delay is the highest with FTP, from 10 s to 2 min. The delay is realistic when concerning large, more than 2.5 MB packet transmissions during the busy hour. Less than one second HTTP page response time is tolerable in web browsing. Voice and videoconference delays are both clearly less than 100 ms, which is a tolerable latency [13]. Streaming produces the lowest delay, less than 40 ms, because streaming consists of constant DL traffic only.



0,001

0,010

0,100

1,000

10,000

100,000

1 000,000

0 5 10 15 20 25 30 35 40 45 50 55 60

Ave

rage

net

wor

k de

lay

[s]

Time [min]

Video Conference

FTP (download response time)

Voice

HTTP (page response time)

Streaming

8-11: Average network delays of BG traffic components.

8.5 Normal AMR traffic with background traffic The results for the normal AMR with background traffic simulation scenario are presented in this Section. The AMR traffic parameters are presented in Table 5 and BG traffic parameters in Table 8. Figure 8-12 shows the average load of AMR and BG traffic application types as a function of time. Generated AMR traffic can be seen more accurately in Figure 8-1: and Figure 8-2. AMR traffic is only a bit more than 0.2 kB/s. Thus, it does not have significant effect to total traffic. In fact, total traffic seems to be slightly less than in previous chapter without AMR traffic, because of a bit lower videoconference traffic.



0

100

200

300

400

500

600

700

800

900

1 000

1 100

1 200

1 300

1 400

0 5 10 15 20 25 30 35 40 45 50 55 60

Ave

rage

loa

d [k

B/s]

Time [min]

Video Conference

FTP

VoiceHTTP

AMR (smart grid)

Streaming

Total traffic

8-12: Average loads of AMR and BG traffic components.



Figure 8-13 presents the average network delay as a function of time. From the figure it can be seen that network delay with FTP is from 15 s to 3 min. Thus, adding of AMR traffic increased FTP delay at most by 1 minute. Delay of the HTTP traffic increased approximately by 0.3 ms. For the other BG traffic applications, there is no significant increase in average network delays. UL AMR traffic delay is a bit over 20 ms. Without BG traffic, AMR traffic delay is only a few milliseconds lower (Figure 8-1:).

0,001

0,010

0,100

1,000

10,000

100,000

1 000,000

0 5 10 15 20 25 30 35 40 45 50 55 60

Ave

rage

net

wor

k de

lay

[s]

Time [min]

Video Conference


Voice


AMR (smart grid)

Streaming

Figure 8-13: Average delays of AMR and BG traffic components.

8.6 Emergency traffic with background traffic The results of the emergency traffic with background traffic scenario simulations are presented in this Section. AMR traffic parameters are presented in Table 7 and BG traffic parameters in Table 8. Figure 8-14 presents average load of BG and AMR including emergency traffics as a function of time. Generated AMR and emergency traffic can be seen more accurately in Figure 8-7. As in the previous scenario, AMR and emergency traffics does not have significant effect to total traffic. Instead, videoconference traffic effects to the total traffic level.



0

100

200

300

400

500

600

700

800

900

1 000

1 100

1 200

1 300

1 400

0 5 10 15 20 25 30 35 40 45 50 55 60

Ave

rage

loa

d [k

B/s]

Time [min]

Video Conference

FTP

VoiceHTTP

AMR (smart grid)

Streaming

Total traffic

8-14: Average load of BG and AMR including emergency traffic.

Figure 8-15 presents the average network delay as a function of time. There is no significant difference between delay values when comparing to the result of the previous scenario without emergency traffic (Figure 8-13).



0,001

0,010

0,100

1,000

10,000

100,000

1 000,000

0 5 10 15 20 25 30 35 40 45 50 55 60

Ave

rage

net

wor

k de

lay

[s]

Time [min]

Video Conference


Voice


AMR (smart grid)

Streaming

8-15: Average delay of BG and AMR including emergency traffic.

8.7 Two-way normal AMR traffic with background traffic The results of the normal two-way normal AMR traffic with background traffic scenario simulations are presented in this Section. Two-way AMR traffic parameters are presented in Table 13 and BG traffic parameters in Table 8. Figure 8-16 shows the average load of AMR and BG traffic applications as a function of time. DL AMR traffic is only a bit less than 0.06 kB/s.



0,01

0,10

1,00

10,00

100,00

1 000,00

10 000,00

0 5 10 15 20 25 30 35 40 45 50 55 60

Ave

rage

loa

d [k

B/s]

Time [min]

Video Conference

FTP

Voice

HTTP

AMR UL (smart grid)

Streaming

Total traffic

AMR DL (smart grid)

8-16: Average load of AMR UL/DL and BG traffic.

Figure 8-17 presents the average network delay as a function of time. There is no significant difference between delay values when compared to the result of the previous scenarios without DL AMR traffic (Figure 8-13, Figure 8-15). DL AMR traffic has a very low latency, only a bit more than 2 ms.



0,001

0,010

0,100

1,000

10,000

100,000

1 000,000

0 5 10 15 20 25 30 35 40 45 50 55 60

Ave

rage

net

wor

k de

lay

[s]

Time [min]

Video Conference


Voice


AMR UL (smart grid)

StreamingAMRDL (smart grid)

8-17:. Average delay of AMR UL/DL and BG traffic.

8.8 Packet delivery ratios in scenarios with background traffic Table 16 presents the packet delivery ratios, in percentages, for the scenarios with BG traffic. All AMR and emergency traffic is delivered with 100 % probability. Applying the acknowledgement of packets increases the probability of delivery towards the 100 % ratio. With BG traffic applications, acknowledgement packets are not applied. For this reason, there are some packet delivery failures. With real-time traffic applications (voice and videoconferencing), acknowledgement packets are not possible because of the latency requirements. Acknowledgement packets could have been used with FTP, HTTP and streaming to improve the packet delivery ratios. In any case, streaming packets were delivered with almost 100 % probability. Running SG traffic on a shared LTE network does not have any effect to packet delivery ratios of BG traffic.



Table 16: Packet delivery ratios in percentages with BG traffic scenarios

Only BG traffic Normal AMR Normal AMR inc. emergency Two-‐way normal AMRAMR UL -‐ 100 100 100AMR DL -‐ -‐ -‐ 100Voice 99 99 100 100Video conference 87 88 89 88Streaming 100 100 100 100HTTP 96 94 95 95FTP 76 80 85 79

9 Conclusions In this deliverable, we have addressed several simulation scenarios to identify the requirements and impact of smart grid communications on LTE network. In order to have more realistic results, we have modelled our simulation environment with as much impact from real systems as feasibly possible. We began the work by defining a suburban scenario for smart grid communications and generalised it to cater for various environments. Furthermore, we defined the power outage scenario that addresses emergency scenarios of our simulations and provides a worst-case usage model of the LTE network. Next, we tackled the structure of the LTE network itself, the key parameters concerned, and defined the simulated scenarios along with their traffic requirements. The metrics of interest were average and instantaneous network load, throughput, delivery ratio, and average and instantaneous delay. The simulation results were obtained, in each scenario, for the above metrics and based on them we can make the following conclusions. Regular SG traffic has very little effect on eNodeB or the network load. The occupied fraction of channel capacity by AMR traffic is less than one per cent. In addition, the delivery ratio of regular SG traffic stays at approximately 100% and the network delay is only few tens of milliseconds. Therefore, no obstacles for using public LTE network for regular SG traffic can be perceived. When it comes to critical emergency events, such as the last gasp messages defined in the outage part of the document, the situation is somewhat different. The delay of last gasp messages can rise to the order of ten seconds, which is still acceptable, but the delivery ratio of the messages falls under the QoS limit, down to 75 %. The result comes under the assumption that the outage occurs and is detected simultaneously in the entire area of influence. To alleviate this problem, we recognise that the last gasp messages need to be delivered with very high probability, but they can tolerate even quite significant delay. We introduced an artificial, up to one-second random delay, in the transmission scheduling of a last gasp message. This spreading of the last gasp messages proved to be a very efficient method for mitigating network overloading. The results indicated that the delivery ratio rose once more close to 100% and the network delay fell to the order of tens to hundreds of milliseconds.



With respect to the impact of AMR traffic to regular LTE traffic and vice versa, the AMR traffic is only a bit more than 0.2 kB/s. Thus, it does not have significant effect to total traffic. Addition of AMR traffic increased FTP delay at most by 1 minute, which is a large increase, but not significant. The delay of the HTTP traffic increased approximately by 0.3 ms, which is perfectly acceptable in not impacting user experience. For the other regular LTE traffic applications, there is no significant increase in average network delays. Delivery ratios were not impacted at all. The randomly spread emergency traffic does not have a significant effect on total traffic. When we include AMR downlink traffic (tariff updates, control information, firmware updates, etc.) in our scenario, we observe that there is no significant difference between delay values when compared to the result of the previous scenarios without DL AMR. This may be partially to the fact that in the simulations, the DL AMR traffic is evenly spread over the entire DL traffic generation interval and the DL traffic does not produce multiple messages simultaneously. Even in the case that, e.g. tariffs need to be adopted simultaneously, the tariff information could be delivered in advance and just have the same effective start time. DL AMR traffic has a very low latency in this scenario. With the above simulation results as proof of concept, there is no reason why, with a small amount of intelligent deployment work, public LTE networks would not be a viable option for smart grid communications. Therefore, we will take our research further on two fronts: perform the same set of simulations for a hybrid network in which the clusters of Figure 4-3 are in fact sensor networks with a single LTE capable cluster, and the same suburban system, where we include local production of electricity. Local production and its effective utilisation within the same LV network requires bi-directional communications between the LTE RTUs in the same network and will increase the traffic manifold. Using sensor networks at cluster level may enable a more low-power operation of AMR metering that is advantageous during outages and other emergency scenarios in the smart grid.



References [1] V. Hovinen, J. Haapola, “D6.1.7: Propagation Models for Smart Grids Communications,”

SGEM FP2 T6.1 Deliverable, Dec. 2011. [2] 3GPP, “3rd Generation Parthnership Project; Technical Specification Group Radio Access

Network; Spatial channel model for Multiple Input Multiple Output (MIMO) simulations (3GPP TR 25.996, Release 8)”, V8.0.0, pp. 16-18, Dec 2008.

[3] Erceg, V.; Greenstein, L.J.; Tjandra, S.Y.; Parkoff, S.R.; Gupta, A.; Kulic, B.; Julius, A.A.; Bianchi, R.; , "An empirically based path loss model for wireless channels in suburban environments," Selected Areas in Communications, IEEE Journal on , vol.17, no.7, pp.1205-1211, doi: 10.1109/49.778178, Jul 1999, URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=778178&isnumber=16902

[4] P. Muszynski, “D6.1.1: Consolidated communication requirement description”, Unpublished Laboratorio Report (SGEM), Oct 2011.

[5] 3GPP, “3rd Generation Parthnership Project; Technical Specification Group Services and System Aspects; Policy and charging control architecture (3GPP TS 23.203, Release 8)”, V8.3.1, pp. 25-28, Sept 2008.

[6] H. Holma, et. al., “LTE for UMTS OFDMA and SC-FDMA Based Radio Access”, John Wiley & Sons Ltd.

[7] http://ewh.ieee.org/conf/tdc/IEEE_-_Outage_Management_-_042308_FINAL.pdf . [8] http://www.elp.com/index/display/article-display/3024698223/articles/electric-light-

power/volume-87/Issue_4/sections/improving-outage_management.html

[9] http://www.smartgridinformation.info/pdf/2664_doc_1.pdf

[10] http://ebookbrowse.com/sg-network-system-requirements-specification-v4-0-draft4-xls-d142503397 , last accessed 13.03.2012.

[11] MaxStream, “Indoor path loss”, Technical Report xstAN005a-Indoor, Sept. 2003.

[12] OPNET Technologies (2011) OPNET Modeler Version 16.1.

[13] Alcatel-Lucent (accessed on 21 March 2012) QoS in LTE PSCR Demo Days. URL: http://www.pscr.gov/projects/broadband/700mhz_demo_net/stakeholder_mtg_122010/day_1/5.2_qos_priority_preemption-alu.pdf.

sgem fp2 d6.1.8 v0.6 - sgemfinalreport.fisgemfinalreport.fi/files/sgem_fp2_d6.1.8.pdf · an outage...

Documents