Download 6 The model to classify the requirements for Smart Grid

INTERNATIONAL TELECOMMUNICATION UNION
TELECOMMUNICATION
STANDARDIZATION SECTOR
FOCUS GROUP ON
SMART GRID
Smart-O-32Rev.6
English only
STUDY PERIOD 2009-2012
Original: English
WG(s):
WG2
Geneva, 18-21 December 2011
DOCUMENT
Source:
WG2 Editor
Title:
Deliverable on Requirements of communication for smart grid
Contact:
Tetsuya Yokotani
Mitsubishi Electric Corporation
Japan
Tel: +81-467-41-2433
Fax: +81-467-41- 2519
Email:
[email protected].
co.jp
Contact:
Li Jian
China Academy of Telecommunication
Research of MIIT
China
Tel: +86-10-62300016
Fax: +86-10-62300034
Email: [email protected]
Contact:
Shingo Soma
Mitsubishi Electric Corporation
Japan
Tel: +81-467-41-2872
Fax: +81-467-41- 2519
Email:
[email protected]
Attention: This is not a publication made available to the public, but an internal ITU-T Focus Group document intended only for
use by participants of the Focus Group and their collaborators in ITU-T Focus Group related work. It shall not be made available to,
and used by, any other persons or entities without the prior written consent of ITU-T.
-2Smart-O-32Rev.6
Deliverable on Requirements of communication for smart grid
Summary
This deliverable describes requirements for three areas of Smart Grid, Smart Grid
Services/Applications area, Communication area and Physical Equipment area.
Keywords
Smart grid
Contents
1
Scope............................................................................................................................. 5
2
References..................................................................................................................... 5
3
Definitions .................................................................................................................... 5
4
Abbreviations and acronyms ........................................................................................ 6
5
Conventions .................................................................................................................. 7
6
The model to classify the requirements for Smart Grid ............................................... 8
6.1
Smart Grid Services/Applications area .......................................................... 9
6.2
Communication area ....................................................................................... 10
6.2.1
Communication network ................................................................................ 10
6.2.2
Information Access ......................................................................................... 11
6.3
Physical Equipment area ................................................................................ 11
7
Requirements for Smart Grid Services/Applications area ............................................ 12
7.1
Customer domain............................................................................................ 12
7.2
Operation domain ........................................................................................... 14
7.3
Service Provider domain ................................................................................ 14
7.4
Markets domain .............................................................................................. 15
7.5
Bulk Generation domain................................................................................. 15
7.6
Transmission and Distribution domains ......................................................... 16
7.7
Multi domains ................................................................................................. 16
8
Requirements for Communication area ........................................................................ 17
8.1
Communication Network domain .................................................................. 18
8.1.1
Networks......................................................................................................... 18
8.1.1.1 Wide Area Networks / Access Networks / Neighborhood Area Networks .... 18
8.1.1.1.1 Generally applied requirements ...................................................................... 18
8.1.1.1.2 Requirements applied to Access Networks using wireless technologies ....... 19
-3Smart-O-32Rev.6
8.1.1.1.3 Requirements applied to Optical Networks which are deployed along with
UHV transmission networks........................................................................... 19
8.1.1.1.4 Requirements applied to IMT ......................................................................... 20
8.1.1.2 Home Area Networks / Local Area Networks ............................................... 20
8.1.1.2.1 IP traffic parameters ....................................................................................... 21
8.1.2
Protocols and network functions .................................................................... 21
8.1.2.1 Network security ............................................................................................ 21
8.1.2.2 Capability of IP base transport ....................................................................... 21
8.1.2.3 Access control ................................................................................................ 21
8.1.2.4 Traffic engineering and QoS control .............................................................. 22
8.1.2.5 OAM function ................................................................................................ 24
8.1.2.6 Protection and restoration ............................................................................... 25
8.1.2.7 Connectivity and routing ................................................................................ 26
8.1.2.8 Network management ..................................................................................... 26
8.1.2.9 End networked device management ............................................................... 27
8.1.3
Logical Network Components ........................................................................ 28
8.1.3.1 GW (Gateway) and ESI .................................................................................. 28
8.1.3.2 Network cable ................................................................................................. 29
8.2
Information Access domain ............................................................................ 30
8.2.1
Data management ........................................................................................... 30
9.
Requirements for Physical Equipment area .................................................................. 30
9.1
Customer domain............................................................................................ 30
9.2
Distribution domain ........................................................................................ 31
9.3
Operation domain ........................................................................................... 32
9.4
Market/ Service Provider domains ................................................................. 32
9.5
Bulk Generation and Transmission domains .................................................. 33
9.6
Multi domains ................................................................................................. 33
10
Common requirements for all areas .............................................................................. 35
11
Gap analysis .................................................................................................................. 36
Annex A Summary of Smart Grid Requirements with Use cases ........................................... 39
Appendix I Source materials for requirements on technical elements ..................................... 44
I.1 Requirement on transmission .................................................................................. 45
I.2 Transport QoS requirements based on NGN ........................................................... 47
I.3 Other transport QoS requirements ........................................................................... 49
I.4 Application level QoS requirement ........................................................................ 51
I.5 Communication control requirements based on exiting architecture ...................... 52
I.6 Communication control requirements based on new architecture .......................... 55
-4Smart-O-32Rev.6
I.7 Service convergence function ................................................................................. 57
I.8 Requirements based on 3GPP base network ........................................................... 58
I.9 Requirements of IP-based HAN architecture .......................................................... 64
I.10 Requirements of expansion of M2M communication for smart grid .................... 65
I.11 Requirements on applications depending on services ........................................... 67
I.12 Requirements on communication focusing on electric vehicle for smart grid ..... 69
I.13 Requirements for the information exchange specification between the
household electrical appliances and power grid ............................................. 72
I.14 Optical fiber transmission in utilization field in the smart grid .......................... 73
I.15 Power grid geographic information system ......................................................... 74
Appendix II Source materials for requirements on components.............................................. 77
II.1 Detailed Requirements on GW .............................................................................. 77
II.2 Requirements on smart meter ................................................................................ 78
Bibliography............................................................................................................................. 80
-5Smart-O-32Rev.6
1
Scope
This deliverable document specifies requirements of Smart Grid based on the three different areas
defined in overview deliverable including Smart Grid Services/Applications area, Communication
area and Physical Equipment area.
2
References
The following ITU-T Recommendations and other references contain provisions, which, through
reference in this text, constitute provisions of this deliverable. At the time of publication, the
editions indicated were valid. All Recommendations and other references are subject to revision; all
users of this deliverable are therefore encouraged to investigate the possibility of applying the most
recent edition of the Recommendations and other references listed below. A list of the currently
valid ITU-T Recommendations is regularly published.
The reference to a document within this deliverable does not give it, as a stand-alone document, the
status of a Recommendation.
Normative references
[ITU-T G.1010]
ITU-T Recommendation G.1010 (2001) End-user multimedia QoS categories
[ITU-T G.9970]
ITU-T Recommendation G.9970 (2009) Generic home network transport
architecture
[ITU-T G.9971]
ITU-T Recommendation G.9971 (2010) Requirements of transport functions in
IP home networks
[ITU-T X.1500]
ITU-T Recommendation
information exchange
[ITU-T Y.1540]
ITU-T Recommendation Y.1540 (2007) Internet protocol data communication
service – IP packet transfer and availability performance parameters
[ITU-T Y.1541]
ITU-T Recommendation Y.1541 (2006) Network performance objectives for
IP-based services
[1]
NIST Special Publication 1108 (2010), NIST Framework and Roadmap for
Smart
Grid
Interoperability
Standards,
Release
1.0,
http://www.nist.gov/public_affairs/releases/upload/smartgrid_interoperability_f
inal.pdf
[2]
ISO/IEC 14543-4-1 (2008) Information technology - Home electronic system
(HES) architecture - Part 4-1: Communication layers - Application layer for
network enhanced control devices of HES Class 1.
[3]
ISO/IEC 14543-4-2 (2008) Information technology - Home electronic system
(HES) architecture - Part 4-2: Communication layers - Transport, network and
general parts of data link layer for network enhanced control devices of HES
Class 1.
3
X.1500
(2011)
Overview
Definitions
Definitions of terms in this deliverable are subject to the terminology deliverable.
of
cybersecurity
-6Smart-O-32Rev.6
4
Abbreviations and acronyms
AC
Alternating Current
AMI
Advance Metering Infrastructure
BEMS
CPN
DC
Building Energy Management Service
Customer Premises Network
Direct Current
DER
DR
Distributed Energy Resource
Demand Response
DSL
Digital Subscriber Line
EMS
Energy Management System
ESI
Energy Service Interface
EV
Electric Vehicle
FMC
Fixed Mobile Convergence
GIS
Geographic Information System
GPRS
General Packet Radio Service
GW
Gateway
H2G
Home to Grid
H/W
Hardware
HAN
Home Area Network
IF
Interface
IMS
Internet Multimedia Sub-system
IMT
International Mobile Telecommunication
IP
Internet Protocol
LAN
Local Area Network
M2M
Machine to Machine
MAC
Medium Access Control
MAN
Metropolitan Area Network
NAN
Neighborhood Area Network
NGN
Next Generation Network
OAM
Operation Administration and Maintenance
OTN
Optical Transport Network
PEV
Plug-in Electric Vehicles
PLC
Power Line Communication
PSU
Power Supply Unit
-7Smart-O-32Rev.6
PON
Passive Optical Network
QoS
Quality of Service
RAN
Radio Access Network
RPR
RSVP
Resilient Packet Ring
Resource Reservation Protocol
S/W
Software
SDH
Synchronous Digital Hierarchy
SIP
Session Initiation Protocol
SLA
Service Level Agreement
STP
Spanning Tree Protocol
TCP
Transport Control Protocol
SCADA
Supervisory Control and Data Acquisition
UDP
User Datagram Protocol
UHV
Ultra-High Voltage
V2G
Vehicle to Grid
V2I
Vehicle to Infrastructure
V2V
Vehicle to Vehicle
VRRP
Virtual Router Redundancy Protocol
WAN
Wide Area Network
5
Conventions
In this Deliverable:
The phrase "is required to" indicates a requirement which must be strictly followed and from which
no deviation is permitted if conformance to this Deliverable is to be claimed.
The phrase "is prohibited from" indicates a requirement which must be strictly followed and from
which no deviation is permitted if conformance to this Deliverable is to be claimed.
The phrase "is recommended" indicates a requirement which is recommended but which is not
absolutely required. Thus this requirement need not be present to claim conformance.
The phrase "is not recommended" indicates a requirement which is not recommended but which is
not specifically prohibited. Thus, conformance with this specification can still be claimed even if
this requirement is present.
The phrase "may optionally" indicates an optional requirement which is permissible, without
implying any sense of being recommended. This term is not intended to imply that the vendor's
implementation must provide the option and the feature can be optionally enabled by the network
operator/service provider. Rather, it means the vendor may optionally provide the feature and still
claim conformance with the specification.
-8Smart-O-32Rev.6
In the requirements Clauses 7 through 10, each sub-clause classifies requirements according to the
above conventions. Moreover, each requirement is assigned an identifier consisting of the following
elements for easy identification:
<AA-BB-BB-XX-C-D->
AA
Classification of a requirement based on the three areas
S/A: Smart Grid Services/Applications
COM: Communication
PHY: Physical Equipment
BB-BB
Sub-clause title
XX
Sequential number
C
Source of a requirement
I: Input document (requirement based on contributions and overview materials)
U: Use case (requirement extracted from a use case)
D
Requirement type
RQ: Required
P: Prohibited
R: Recommended
nR: not Recommended
O: may Optionally
Example: <COM-CN-Gen-01-I-R> indicates the first requirement in generally applied requirements
for Communication area based on a contribution. Its requirement type is “Recommended.”
6
The model to classify the requirements for Smart Grid
This clause describes the model used to classify the requirement in the following clauses. Based on
this model, detailed requirements are described in Clause 7 through 10. The model is named three
areas model which has Smart Grid Services/Applications area, Communications area and Physical
Equipment area. Figure 6-1 shows relationship between the seven domains model [1] and the three
areas. The left-side three areas are based on Figure 3/Overview deliverable. Moreover, the seven
domains are mapped to the three areas. This deliverable classifies requirements according to the
three areas in Figure 6-1.
-9Smart-O-32Rev.6
Smart Grid
Services/
Applications
Markets
Operation
Service
Provider
Generation
Transmission
&
Distribution
Customer
Markets
Markets
Operations
Operations
Service
Provider
Information Access
Communication
Communication Network
Communication Network
Communication Network
Customer Domain
Distribution Domain
Physical
Equipment Operation Domain
Bulk
Bulk
Generation
Generation
Customer
Customer
Transmission
Transmission
Distribution
Distribution
Market/Service Provider Domains
Bulk Generation and Transmission Domains
Figure 6-1: Relation between the seven domains model and the three areas model
6.1
Smart Grid Services/Applications area
This sub-clause describes the Smart Grid Services/Applications area of the three areas model. The
Smart Grid Services/Applications area includes six domains; Customer, Operation, Service
provider, Markets, Bulk Generation, and Transmission and Distribution. The Smart Grid
Services/Applications area contains functional requirements in conceptual domains listed below.
The following items are recommended of each domain.
 Customer domain
o Support the basic control functions. (e.g., lighting and temperature control) for
home appliances and electronic devices.
o Support the capability for in-home/building display of EMS (Energy Management
System), customer usage and reading of meters.
o Support auditing/logging functions for troubleshooting and security for EMS.
o Support the dynamic pricing response and energy usage management.
o Support integrated building and industrial intelligent automation

Operation domain
o Support the SCADA (Supervisory Control and Data Acquisition) systems to
monitor and control the status of devices in Bulk Generation, Transmission, and
Distribution domains.
o Support the function for the asset management and meter data management (i.e.,
- 10 Smart-O-32Rev.6
energy usage, energy generation, meter logs, and meter test results) to make
energy data available to authorized parties.

Service Provider domain
o Support the function for customer service, account management, billing
management and installation management.
o Support smart meter installation and maintenance.
o Support energy management for homes, building, and industries.

Markets domain
o Support electric power trading including retailing and wholesaling.
o Support dynamic pricing used in DR (Demand Response) and billing function.

Bulk Generation domain
o Support the function for managing the flow of power and ensuring reliability of
the plant control system.
o Support traditional and renewable energy generation and storage management.

Transmission and Distribution domains
o Support management and control functions for distributed energy generation,
distributed storage, substation, and local distribution network.
6.2
Communication area
This sub-clause describes the Communication area of the three areas model. The Communication
area consists of two sub-areas, communication network and information access. In Smart Grid
Communication area, the following items are recommended.
6.2.1 Communication network
Overall
 General high level requirement
o Consider security concerning confidentiality, integrity, availability, accountability
and privacy.
 Network security
o Provide secure communication network. This function includes authentication,
encryption, etc.
 Access control
o Support Access control capabilities to manage and access facilities in the network.
User plane
 Capability of IP base transport
o Specify support of IPv4 and IPv6.
 Traffic engineering and QoS control
o Support controlling function for guarantee of communication quality.
- 11 Smart-O-32Rev.6
Control plane
 OAM function
o Define specific OAM protocols, e.g., failure detection, alarm transfer and
performance monitoring.
 Protection and restoration
o Support protection and restoration capabilities for easy operation and minimizing
service outage for Smart Grid Services/Applications area and Physical Equipment
area for Smart Grid
 Connectivity and routing
o Support communication among multi-points by physical connectivity and routing
protocol
Management plane
 Network management
o Support manageable by network operators and service providers including Power
Company or user. Network management is provided in hierarchical fashion
according to network scale and the number of users.
 End networked device management
o Support function for end device management as the same manner as network
management.
6.2.2 Information Access
 Data management
o Reduce traffic load of communication network by application data aggregation,
suppression and unification of data structure.
6.3
Physical Equipment area
This sub-clause describes the Physical Equipment area of the three areas model. In Smart Grid
Physical Equipment area, the following items are recommended.
 Customer domain
o Support more than one device, e.g., sensors, and controllers. These devices provide
information to the Smart Grid Services/Applications area, and receive commands
to affect control of devices in the Physical Equipment area.
o Support energy related functionalities by devices. These functionalities include
home/industrial automation, advanced metering, smart grid control and
management.
o Support meter reading interface
o Support the CPN with direct access to consumer-specific usage data.
 Distribution domain
- 12 Smart-O-32Rev.6
o Supports monitor/control
distribution).
function
(energy
generation,
transmission
and
o Support function for storage/integration of renewable energy.
 Operation domain
o Support management function for individual device status and energy
consumption.
 Market/ Service Provider domains
o Support trading, prepayment and measurement function for markets.
o Support billing, aggregation and retailing function for service providers.
 Bulk Generation and Transmission domains
o Support control function for power plant and electricity transmission.
7
Requirements for Smart Grid Services/Applications area
This clause describes requirements for the Smart Grid Services/Applications area according to the
three areas model which is described in Clause 6. Correspondence between use case services and
requirements are shown in the table in Annex A. This table will improve readability of the
following clauses and sub-clauses.
7.1
Customer domain
<Note> The use case’s sub-title specified in Use Case deliverable is quoted in parentheses after the
requirement identifier for use case related requirements.
Recommend

<S/A-Cus-01-U-R> (Premise energy status display service)
It is recommended to support any collection function of status information from
devices, displaying capability and others.

<S/A-Cus-02-U-R> (Monitor of electric power and appliances operating status)
It is recommended to easiness of installation of H/W and S/W. e.g., S/Ws can be
installed in the same way regardless of services.

<S/A-Cus-03-U-R> (Flexible Energy Management service)
It is recommended to support flexible visualization for energy consumption of
dynamically specified managed group.

<S/A-Cus-04-U-R> (Charging management for appliances including electric vehicle at
home)
It is recommended to support electric power load management at home, including
PEV energy consumption control based on its charging status.

<S/A-Cus-05-U-R> (Charging management for appliances including electric vehicle at
home)
It is recommended to support management status of charge level, miles driven,
- 13 Smart-O-32Rev.6
driven pattern, status of PEV (Plug-in Electric Vehicles) in garage or not, charging
mode, etc.

<S/A-Cus-06-U-R> (Detailed metering information transfer to BEMS through ESI)
It is recommended to measure the detailed energy usage per device or facility.

<S/A-Cus-07-U-R> (BEMS controls electric consuming device through ESI)
It is recommended to control any energy consuming component in intra building
area.

<S/A-Cus-08-U-R> (renewable system management service)
It is recommended to support monitoring and control of any PSU (Power Supply
Unit) including inverter function, DC to AC conversion, control and management
capability of renewable distributed generation systems.

<S/A-Cus-09-U-R> (Management for V2G service)
It is recommended to support monitoring the EV’s (Electric Vehicle’s) battery state
and participation to V2G (Vehicle to Grid) service.

<S/A-Cus-10-U-R> (Management for V2G service)
It is recommended to support bidirectional metering related to charging and
discharging of V2G capable EV.

<S/A-Cus-11-U-R> (Management for V2G service)
It is recommended to support bidirectional electrical power control for charging
and discharging of EV.

<S/A-Cus-12-I-R>
It is recommended to support security function such as non-repudiation, data
integrity, user authentication, etc.

<S/A-Cus-13-U-R> (Management for V2G service)
It is recommended to support monitoring the electrical power state of power grid
such as electrical voltage level, frequency, etc.

<S/A-Cus-14-I-R>
It is recommended to support interoperability between or among V2G service
entities.

<S/A-Cus-15-I-R>
It is recommended to use a standardized profile for energy services in Home Area
Smart Grid (Home Grid) in transferring information for Energy Management
Service among multiple devices using more than one communications protocols.
These devices are listed below but not limited to them.

Smart meter,

ESI (Energy Service Interface) devices,

Energy consuming devices,

Energy storage devices,

Energy generating devices,
- 14 Smart-O-32Rev.6

Energy information display devices,
 Handheld smart devices.
Examples of standardized profiles are as follows:
- “ECHONET(Energy Conservation and Homecare Network)” [2][3]
- “Energy Service Profile” [b-1].

<S/A-Cus-16-I-R>
It is recommended to support measurement and control of energy demand response
in real-time or near real-time.
<Note> Near real-time means soft real-time where time constraint is assured
statistically.

<S/A-Cus-17-I-R>
It is recommended to support mechanisms enabling users to interact with the CPN
(e.g., configuring the CPN and its devices, and obtaining useful information from
the CPN).

<S/A-Cus-18-I-R>
It is recommended to support customer information management (e.g., billing, user
subscription, and others), energy market and dynamic pricing, and energy demand
response management and control.
Option

<S/A-Cus-19-I-O>
It may optionally support monitoring and management to electrical amount charge
of electrical vehicle.

<S/A-Cus-20-I-O>
It may optionally support electrical power management function based on pricing
information, DR message, EV operating schedule, battery state, etc.

<S/A-Cus-21-I-O>
It may optionally support user interface in vehicle for V2G service using electrical
vehicle.
7.2
Operation domain
Recommend

<S/A-Ope-01-I-R>
For efficient management and operation of smart grid, it is recommended to
provide the geographical information of smart grid components, which may be
provided by GIS (geographic information system) like capability.
7.3
Service Provider domain
<Note> The use case’s sub-title specified in Use Case deliverable is quoted in parentheses after the
requirement identifier for use case related requirements.
Recommend
- 15 Smart-O-32Rev.6

<S/A-SP-01-U-R> (energy management service)
It is recommended to support any computing capabilities to process the embedded
energy management algorithm.

<S/A-SP-02-U-R> (Dynamic pricing related service)
It is recommended to support electric energy storage capability and price based
control capability.

<S/A-SP-03-U-R> (Dynamic pricing information transfer to BEMS through ESI)
It is recommended to support pricing information which is to be transferred using
the predefined format between or among participants, such as BEMS (Building
Energy Management System) server, Energy service provider, energy provider and
ESI.

<S/A-SP-04-U-R> (senior care) (life support)
It is recommended to provide an external interface to third party application
providers. External interface includes protocol choice from physical layer to
application layer and data model for applications.
<Note> An external interface will enable development of third-party applications
to support a variety of services.

<S/A-SP-05-U-R> (DR message transfer to BEMS through ESI)
It is recommended to support power grid outage management and demand
responses services.
7.4
Markets domain
<Note> The use case’s sub-title specified in Use Case deliverable is quoted in parentheses after the
requirement identifier for use case related requirements.
Recommend
 <S/A-Mar-01-U-R> (electrical power trading service)
It is recommended to support any bidirectional metering and pricing capabilities
based on dynamic pricing.

<S/A-Mar-02-I-R>
It is recommended to support control capability for distributed energy resources.

<S/A-Mar-03-I-R>
It is recommended to support management capability for aggregation of electric
power from distributed energy resources.

<S/A-Mar-04-I-R>
It is recommended to support management capability for market participants and
dynamic pricing in the energy market.
7.5
Bulk Generation domain
Recommend
- 16 Smart-O-32Rev.6

<S/A-BG-01-I-R>
It is recommended to support the management and control of the energy
generation to meet the energy demands.

<S/A-BG-02-I-R>
It is recommended to support integrated network for communication with other
domains to intelligently manage the power grid.

<S/A-BG-03-I-R>
It is recommended to provide real-time monitoring and management information
to enable stable and optimized control operations.
<Note> Management information such as status of remote terminal units, fault
recorders, programmable logic controllers, and others.

<S/A-BG-04-I-R>
It is recommended to support integration of renewable energy sources into the
transmission and distribution system, and the use of storage systems to manage
the variability of renewable generation.
7.6
Transmission and Distribution domains
<Note> The use case’s sub-title specified in Use Case deliverable is quoted in parentheses after the
requirement identifier for use case related requirements.
Recommend
 <S/A-TaD-01-U-R> (electrical power sharing service)
It is recommended to support distribution of energy among electric power sharing
service participants.

<S/A-TaD-02-U-R> (electrical power sharing service)
It is recommended to support metering of energy for each of electric power sharing
service participants.

<S/A-TaD-03-U-R> (electrical power sharing service)
It is recommended to support billing of energy for each of electric power sharing
service participants.

<S/A-TaD-04-U-R> (electrical power sharing service)
It is recommended to support membership management of electric power sharing
service participants.

<S/A-TaD-05-U-R> (DER status transfer to BEMS)
It is recommended to support monitoring system for DER (Distributed Energy
Resource) to transfer generated energy information including power generation
type to EMS.
7.7
Multi domains
<Note> The use case’s sub-title specified in Use Case deliverable is quoted in parentheses after the
- 17 Smart-O-32Rev.6
requirement identifier for use case related requirements.
Recommend
 <S/A-Multi-01-U-R> (premise electrical power storage management service)
For energy storage, it is recommended to support status monitoring including
metering of energy usage.
<Note> This requirement applies to Bulk Generation and Transmission and
Distribution domains.
8
Requirements for Communication area
This clause describes requirements for the Communication area according to the three areas model
which is described in Clause 6.
Recommend
 <COM-Gen-01-I-R>
It is recommended for the Communication area to support scalability, reliability
and QoS including latency and bandwidth.
 <COM-Gen-02-I-R>
It is recommended for the Communication area to support combinations of
scalability, reliability and QoS including latency and bandwidth.
 <COM-Gen-03-I-R>
It is recommended to support various protocols in different layers selecting
options from the various standards
 <COM-Gen-04-I-R>
It is recommended that the Communication area supports interconnection of core
networks, access networks, CPN, and Neighborhood Area Networks.
 <COM-Gen-05-I-R>
It is recommended that the Communication area supports both real-time
communication and non-real-time communication to meet the requirement of a
large number of various applications.
<Note> [IEC 61850][b-2] specifies real-time and non-real-time applications for
field equipment.
 <COM-Gen-06-I-R>
It is recommended that the Communication area supports differentiated quality of
services for a large number of various applications.
 <COM-Gen-07-I-R>
It is recommended that the Communication area supports secured, real-time and
reliable two way communication.
 <COM-Gen-08-I-R>
- 18 Smart-O-32Rev.6
It is recommended that home appliances are connected to a smart meter and ESI
through HAN.
 <COM-Gen-09-I-R>
It is recommended that the Communication area supports secure information
exchange between household electrical nodes and servers in the power utility.
Option
 <COM-Gen-10-I-O>
It may optionally support new QoS functions for the Communication area, if
smart grid applications require.
8.1
Communication Network domain
8.1.1
Networks
8.1.1.1 Wide Area Networks / Access Networks / Neighborhood Area Networks
Wide Area Networks has a variety of forms (Transport Networks, Access Networks and
Neighborhood Area Networks). Examples of technologies of Transport Networks include IMT
(International Mobile Telecommunication), Mobile backhaul and Optical network. Example of
technologies of Access Network and Neighborhood Area Network include IMT, PLC (Power Line
Communication) and Mesh network. The following requirements are classified to ones generally
applied to any technologies and to technology-specific ones.
8.1.1.1.1
Generally applied requirements
Recommend
 <COM-CN-Gen-01-I-R>
It is recommended to support communication capability based on wired or wireless
network for control, monitoring, energy management, etc.
 <COM-CN-Gen-02-I-R>
It is recommended that the IP QoS parameters [ITU-T Y.1540] are characterized as
follows.
o IPTD (IP Transfer Delay)
o IPDV (IP Delay Variation)
o IPLR (IP Loss Ratio)
o IPER (IP Error Ratio)
o IPRR (IP Reordering Ratio)
<Note> Other dedicated parameters for smart grid can be added as required in
specification.
 <COM-CN-Gen-03-I-R>
It is recommended to provide throttling of connectivity usage on Cellular and low
bandwidth access.
 <COM-CN-Gen-04-I-R>
- 19 Smart-O-32Rev.6
It is recommended that the output from devices and servers is balanced so that the
data is sent at a rate that can be handled by the receiver and the bandwidth provided
by the communication path.
 <COM-CN-Gen-05-I-R>
It is recommended to apply various QoS to communications services and
data/information services.
 <COM-CN-Gen-06-I-R>
It is recommended to provide for round trip time criteria so that end-device data
reading is less than the time a customer end-device can tolerate.
<Note> Round trip time for device data reading is defined as time from request
sent by a service provider application to reply received by the same application.
 <COM-CN-Gen-07-I-R>
It is recommended to establish and supervise reliable, secure and highly prioritized
connections with guaranteed QoS between a network node and appliance or meter.
<Note> An example of a network node is a Gateway.
 <COM-CN-Gen-08-I-R>
It is recommended that establishment of a communication session is possible
regardless of the network addressing mechanism (IP static or dynamic addressing)
used.
8.1.1.1.2
Requirements applied to Access Networks using wireless technologies
The technology mentioned in the following requirement is not exhaustive. Other technologies may
be used.
<Note> The use case’s sub-title specified in Use Case deliverable is quoted in parentheses after the
requirement identifier for use case related requirements.
Recommend
 <COM-CN-AN-01-U-R> (remote monitoring and control service using handheld device)
It is recommended to support standard wireless communication protocols to
transfer the monitoring and control information from/to handheld devices.
8.1.1.1.3
Requirements applied to Optical Networks which are deployed along with UHV
transmission networks
The technology mentioned in the following requirement is not exhaustive. Other technologies may
be used.
Recommend
 <COM-CN-ON-01-I-R>
In the case of Ultra-high voltage power transmission where the distance between
the electricity substations/power plants is very long, and the optical communication
system and optical fibre are setup along with the electricity transmission line, it is
recommended that the non-relay ultra-long span optical transmission is used in the
- 20 Smart-O-32Rev.6
smart grid to save the construction cost and improve the reliability of the
communication network.
8.1.1.1.4
Requirements applied to IMT
The technologies mentioned in the following requirements are not exhaustive. Other technologies
may be used.
Recommend
 <COM-CN-IMT-01-I-R>
It is recommended to use 3rd Generation Secure Radio systems within the IMT2000 family, if RAN (Radio Access Network) is deployed in Communication area
and 3rd Generation Secure Radio Systems are available.
 <COM-CN-IMT-02-I-R>
It is recommended to use 4th Generation Secure Radio systems, within the IMTAdvanced family, if RAN is deployed in Communication area and 4th Generation
Secure Radio Systems are available.
 <COM-CN-IMT-03-I-R>
It is recommended that the User/Application Identity is independent of the 3rd
Party Communication area network identity when a dedicated network is not
deployed.
 <COM-CN-IMT-04-I-R>
It is recommended that a change of access provider is possible without requiring
hardware changes, unless a dedicated Utility network is in place.

e.g. it need not require physical change of Identity Modules.
 <COM-CN-IMT-05-I-R>
It is recommended to support remote provisioning of connectivity.
 <COM-CN-IMT-06-I-R>
It is recommended to support broadcast messages via point-to-multipoint to
vehicles located in a given geographical area from network to vehicles (unidirectional).
 <COM-CN-IMT-07-I-R>
It is recommended to support a continuously connected broadcast bearer, if SLA
(Service Level Agreement) and an application require fast MBMS (Multimedia
Broadcast and Multicast Services) transmission.
8.1.1.2 Home Area Networks / Local Area Networks
<Note> The use case’s sub-title specified in Use Case deliverable is quoted in parentheses after the
requirement identifier for use case related requirements.
Recommend
 <COM-CN-HAN-01-U-R> Home Security
It is recommended to deploy a sensor network as a part of home network
- 21 Smart-O-32Rev.6
infrastructure.
8.1.1.2.1
IP traffic parameters
Recommend
 <COM-CN-HAN-02-I-R>
It is recommended that HAN comply with home network requirements [ITU-T
G.9971].
 <COM-CN-HAN-03-I-R>
It is recommended that IP QoS parameters are characterized as follows:
o IPTD (IP Transfer Delay)
o IPDV (IP Delay Variation)
o IPLR (IP Loss Ratio)
o IPER (IP Error Ratio)
o IPRR (IP Reordering Ratio)
<Note> Other dedicated parameters for smart grid can be added.
8.1.2
Protocols and network functions
8.1.2.1 Network security
Recommend
 <COM-CN-NS-01-I-R>
It is recommended that the Communication area supports secure communication
using authentication and encryption.
 <COM-CN-NS-02-I-R>
It is recommended that the smart grid application is protected from attack and
virus.
 <COM-CN-NS-03-I-R>
It is recommended that smart grid application complies with CYBEX
(Cybersecurity information exchange framework) which has been discussed for
NGN and Cloud computing as new enhanced network security [ITU-T X.1500].
8.1.2.2 Capability of IP base transport
Recommend
 <COM-CN-IP-01-I-R>
It is recommended that the Communication area supports the capability of IP base
transport, such as IPv4 and/or IPv6. e.g., TCP, UDP.
8.1.2.3 Access control
Recommend
- 22 Smart-O-32Rev.6

<COM-CN-AC-01-I-R>
It is recommended to provide access control capability consisting of two layers,
which are physical layer and MAC layer aspects.

<COM-CN-AC-02-I-R>
It is recommended to provide each access interfaces as follows.

Wired access (e.g., Optical, xDSL, Coaxial), PLC,

Wireless access (e.g., Cellular, Wireless LAN, ZigBee, Bluetooth, other
sensor)

LAN/MAN, polling including interleave polling, demand assignment, no
prevention access, e.g., centralized switching
8.1.2.4 Traffic engineering and QoS control
Recommend

<COM-CN-QoS-01-I-R>
It is recommended to define SLA guideline, e.g., End-to-End SLA guideline, and
IP component(s) SLA guideline.
<Note> Figure 8-1 shows the examples of End-to-End model. (a) over WAN (End
device is GW) and (b) between end devices.
Customer
Domain 1 GW
WAN
Customer
GW Domain 2
(a) WAN case
Customer
Domain 1
WAN
Customer
Domain 2
End Device
End Device
(b) End-End case
Customer Domains in this figure are HAN which complies with
home network architecture specified in ITU-T G.9970.
Figure 8-1: An example of End-to-End model

<COM-CN-QoS-02-I-R>
It is recommended that traffic provisioning is applied, e.g., Provisioning interface,
admission control.

<COM-CN-QoS-03-I-R>
- 23 Smart-O-32Rev.6
It is recommended that traffic control function is applied, e.g., Policing, discard
control, delay control, multiplexing, traffic shaping.

<COM-CN-QoS-04-I-R>
It is recommended to apply the required quality at application level like [ITU-T
G.1010].

<COM-CN-QoS-05-I-R>
It is recommended that the Communication area between the edges of WAN, CPN
and NAN specifies required performance on IP layer. The performance is specified
for every application, and categorized into Classes 0, 1, 2, 3, 4, U [ITU-T Y.1541].
<Note> Real time transfer services, e.g., pricing service, may require shorter
transmit delay than that specified in Class 0.

<COM-CN-QoS-06-I-R>
It is recommended that Communication area provides controllable performance on
data link layer to comply with IP layer performance.

<COM-CN-QoS-07-I-R>
It is recommended to support SIP, if the Communication area supports the IMS
core network evolution of IMT-2000 & IMT-Advanced.
<Note> QoS of application to application is possible by using SIP Control
specified in IMS with Policy Control.

<COM-CN-QoS-08-I-R>
It is recommended to support GPRS, if the Communication area supports the IMS
core network evolution of IMT-2000 & IMT-Advanced.
<Note> end-to-end QoS of applications is possible using QoS guaranteed
tunnelling as specified in GPRS.

<COM-CN-QoS-09-I-R>
It is recommended that traffic flows on Network and/or Transport layers are
controlled by any protocols. e.g., RSVP, SIP, etc.
<Note> SIP is control protocol in NGN.

<COM-CN-QoS-10-I-R>
It is recommended that control architecture selects one of the 6 tunnelling schemes
shown in Figure 8-2. If SIP is applied as the control protocol, schemes 3 through 6
are available.
- 24 Smart-O-32Rev.6
HAN
WAN
Application server
GW
IP reach ability
GW
Scheme 1
VPN Tunnel
Scheme 2
SIP Tunnel
Scheme 3
SIP termination / initiation point
(SIP adaptation)
SIP Tunnel
VPN Tunnel
SIP Tunnel
SIP Tunnel
SIP Tunnel
SIP Tunnel
Scheme 4
Scheme 5
SIP conversion (SIP proxy)
SIP Tunnel
Scheme 6
Figure 8-2: Control architecture by SIP for smart grid

<COM-CN-QoS-11-I-R>
It is recommended to support the optimization of the existing IP-based transport
protocols to achieve both transport reliability and efficiency.
Option

<COM-CN-QoS-12-I-O>
It may optionally support new transport protocols to achieve both transport
reliability and efficiency.

<COM-CN-QoS-13-I-O>
It may optionally support SIP, if the NGN is required by IMS Core Network to
support access network based on fixed FMC solutions.
8.1.2.5 OAM function
<Note> The use case’s sub-title specified in Use Case deliverable is quoted in parentheses after the
requirement identifier for use case related requirements.
Recommend
 <COM-CN-OAM-01-I-R>
It is recommended to provide failure detection and alarm transfer.
- 25 Smart-O-32Rev.6
 <COM-CN-OAM-02-I-R>
It is recommended to provide hierarchical operations for failure detection and
alarm transfer.
 <COM-CN-OAM-03-I-R>
It is recommended to have communication path trace.
 <COM-CN-OAM-04-I-R>
It is recommended to have performance measurement.
 <COM-CN-OAM-05-U-R> (Flexible Energy Management service)
It is recommended to support communication function between displaying point
and sensing point for energy management.
 <COM-CN-OAM-06-U-R> (Flexible Energy Management service)
It is recommended to support information aggregation at interworking point to
avoid traffic congestion from a huge number of monitoring points.
 <COM-CN-OAM-07-U-R> (BEMS controls EV’s electric charge and discharge)
It is recommended to support communication capability between BEMS and EV
for energy management.
 <COM-CN-OAM-08-U-R> (EV information transfer to BEMS)
It is recommended that BEMS collects information of charging electric power in
EV, and then controls the charging of the EV.
 <COM-CN-OAM-09-U-R> (DR message transfer to BEMS through ESI)
It is recommended to support communication capability between BEMS server and
energy service provider (or energy provider).
 <COM-CN-OAM-10-U-R> (HAN device power metering service)
It is recommended to support any metering function and communication
capabilities to collect the consumed electric power usage.
8.1.2.6 Protection and restoration
Required

<COM-CN-PaR-01-I-RQ>
It is required to provide protection and service restoration capabilities.
<Note> This is for easy operations and service availability (i.e. minimizing service
outage) in the Services/Applications area and Physical Equipment area.
Recommend

<COM-CN-PaR-02-I-R>
It is recommended to provide IP routing protocol, e.g., VRRP.

<COM-CN-PaR-03-I-R>
It is recommended to provide Layer 2 bridging protocol, e.g., STP family.

<COM-CN-PaR-04-I-R>
- 26 Smart-O-32Rev.6
It is recommended to provide LAN/MAN MAC protocol, e.g., RPR.

<COM-CN-PaR-05-I-R>
It is recommended to provide Physical layer protection, e.g., OTN or SDH
protection.

<COM-CN-PaR-06-I-R>
It is recommended to provide Ethernet OAM function.

<COM-CN-PaR-07-I-R>
It is recommended to provide PON protocol, e.g., PON protection.

<COM-CN-PaR-08-I-R>
It is recommended to support one or more type according to target performance,
e.g., service outage period, localization, and useless traffic load.

<COM-CN-PaR-09-I-R>
It is recommended to have cooperations among protection types without
contradiction.
8.1.2.7 Connectivity and routing
Recommend

<COM-CN-CaR-01-I-R>
It is recommended to provide communication among multi-points.

<COM-CN-CaR-02-I-R>
It is recommended to support IP capability based on reachability.

<COM-CN-CaR-03-I-R>
It is recommended to support specific signalling protocol, e.g., SIP.

<COM-CN-CaR-04-I-R>
It is recommended to have static routing.
8.1.2.8 Network management
Recommend
 <COM-CN-NM-01-I-R>
It is recommended to support manageable network by network operators, service
provider including Power Company or user.
 <COM-CN-NM-02-I-R>
It is recommended that the network management is provided in hierarchical fashion
according to network scale and the number of users.
 <COM-CN-NM-03-I-R>
It is recommended to support monitoring/surveillance of networks to manage
failure, topology, performance, etc.
 <COM-CN-NM-04-I-R>
- 27 Smart-O-32Rev.6
It is recommended to support monitoring/surveillance of communication
components to manage component type, failure, etc.
 <COM-CN-NM-05-I-R>
It is recommended to provide provisioning of operation parameters.
 <COM-CN-NM-06-I-R>
It is recommended to provide remote testing function.
 <COM-CN-NM-07-I-R>
It is recommended to provide compression of information.
 <COM-CN-NM-08-I-R>
It is recommended to provide northbound interface for communication to the
higher network management entity.
8.1.2.9 End networked device management
Recommend

<COM-CN-EDM-01-I-R>
It is recommended that the Smart Grid applications provide the same management
to end devices. The end devices can be listed as follows.


electric vehicle

distributed energy resources

electric storage

appliances
<COM-CN-EDM-02-I-R>
It is recommended that the M2M/AMI system is able to send a message to a
sleeping device.
The M2M/AMI system delivers the message to the device when it becomes awake.

<COM-CN-EDM-03-I-R>
It is recommended that the M2M/AMI and Smart Grid Applications specify
scheduling requirements towards devices over the communication network.
The System is only able to allow access to the network during a (pre)defined time
period.

<COM-CN-EDM-04-I-R>
It is recommended that the M2M/AMI and Smart Grid Applications request
broadcast or multicast message delivery service from the related System.
The delivery is implemented through a combination of unicast and multicast e.g.
depending on the access network types.

<COM-CN-EDM-05-I-R>
It is recommended that the M2M/AMI and Smart Grid System optimize
communication paths, based on policies such as network cost or delay when
multiple routes exist.
- 28 Smart-O-32Rev.6

<COM-CN-EDM-06-I-R>
It is recommended that the M2M/AMI and Smart Grid system support data/media
exchange both towards and from the devices.
The devices include End Device, Gateway and Communications environment as
well as multiple traffic patterns.
More specifically the following traffic patterns are supported:

one-shot push/pull requests

periodic push/pull requests

event-driven requests

simultaneous delivery of multiple data/media streams to/from one Gateway
or Communications environment
8.1.3 Logical Network Components
8.1.3.1 GW (Gateway) and ESI
Gateway is a key logical component on communication services.
Recommend

<COM-CN-GW-01-I-R>
It is recommended that gateway meets the communications requirements of the
smart grid applications operating over the gateway. A gateway running smart grid
applications (ESI) has functional blocks shown in Figure 8-3.

<COM-CN-GW-02-I-R>
It is recommended that the gateway complies with IP Access GW [ITU-T G.9970]
[ITU-T G.9971], if it is associated with Telecom network.
The ESI consists of the gateway functions and Smart Grid applications as shown in Figure 8-3. A
utility company, a third party service provider or the customer, may control the Smart Grid
applications and there may be more than one ESI within a customer premises. This means the
energy services control interface should be accessible through the utility NAN, through the WAN,
and through the customer’s LAN.
For example; a utility company may access the ESI through the NAN, while a third party service
provider may access the ESI directly through a WAN that is directly connected to the ESI, or
through the WAN into the premises LAN to the ESI. The customer would normally access the ESI
directly through the LAN or HAN, or indirectly through a gateway when the customer needs to
access ESI function.
- 29 Smart-O-32Rev.6
Application processing including
Smart Grid applications Convergence
function
(Assistance of
transfer function)
Comm.
control
function
PHY
(Assistance of
#3
transfer
Application
function)
control
WAN
/NAN
HAN/LAN
(Non-IP)
PHY
#2
PHY
#1
Transfer control function
HAN/LAN
(IP)
Figure 8-3: ESI functional blocks
The following recommendations deal with the gateway with ESI:

<COM-CN-GW-03-I-R>
It is recommended to support management of electric power load in house,
including EV energy consumption control based on the EV charging status.

<COM-CN-GW-04-I-R>
It is recommended to support management status of charge level, miles driven,
driven pattern, status of whether or not EV is in e.g., garage.

<COM-CN-GW-05-I-R>
It is recommended to support device management e.g., change EV’s modes.
Option

<COM-CN-GW-06-I-O>
It may optionally support gateway that complies with IP Access GW [ITU-T
G.9970] [ITU-T G.9971], if it is associated with Utility network.
8.1.3.2 Network cable
To meet the smart grid requirements of different communication features, deployment issues,
suitable type of communication cables are employed.
- 30 Smart-O-32Rev.6
Option

<COM-CN-Cbl-01-I-O>
In the customer domain and distribution domain of smart grid, it may optionally
support composite cable that integrates the optical fiber with the low voltage power
line as the communication medium at the physical layer.
8.2
Information Access domain
8.2.1
Data management
Recommend

<COM-IA-DM-01-I-R>
It is recommended to have capability of distributed data management for Smart
Grid applications defined in use cases.

<COM-IA-DM-02-I-R>
It is recommended to reduce traffic load of communication network by data
aggregation, suppression and unification of interface.

<COM-IA-DM-03-I-R>
It is recommended to support the common method to set and get conditions of any
home/office equipment.

<COM-IA-DM-04-I-R>
It is recommended to support the function of virtual device management to show
complicated configuration consisting of plural home/office equipment as one
virtual device.
9.
Requirements for Physical Equipment area
9.1
Customer domain
<Note> The use case’s sub-title specified in Use Case deliverable is quoted in parentheses after the
requirement identifier for use case related requirements.
Recommend

<PHY-Cus-01-U-R> (home grid alarm service)
It is recommended to support any monitoring capabilities based on sensor.

<PHY-Cus-02-I-R>
For smart home appliances, it is recommended to exchange the information of
remote control and management, e.g., power on/off, adjust the working mode, etc.

<PHY-Cus-03-I-R>
For smart meter, it is recommended to exchange the information of electricity
voltage, frequency, utility power consumption and dynamic pricing.

<PHY-Cus-04-I-R>
For electrical vehicle, it is recommended to exchange the information of
authentication, charging control, accounting, etc.
- 31 Smart-O-32Rev.6

<PHY-Cus-05-U-R> (HAN device power management service)
It is recommended to support device management in terms of monitor, control and
operation of home devices including adaptation capabilities for the legacy devices.
Option
ITU-T has discussed vehicle communication as expansion of NGN. Smart grid applications can be
provided on this communication. In this case, the following requirements are specified.
The following are requirements for Electric Vehicle for smart grid.

<PHY-Cus-06-I-O>
It may optionally support vehicle communications including V2V, V2I and V2G in
mobile environments.

<PHY-Cus-07-I-O>
It may optionally support interworking with several grid interfaces, e.g., V2G and
H2G.

<PHY-Cus-08-I-O>
It may optionally support charging/billing/energy management in V2G.

<PHY-Cus-09-I-O>
It may optionally support new applications combined telecom services for EV.

<PHY-Cus-10-I-O>
It may optionally support remote management of the battery charging of EV.

<PHY-Cus-11-I-O>
It may optionally support energy efficient transportation of EV (energy savings).

<PHY-Cus-12-U-O> (External clients use the AMI to interact with devices at customer
site)
It may optionally support communication to the service provider, such as energy
management companies, to facilitate monitoring and control of the customer
equipment located at the customer’s premise by CPN directly or through NAN.
9.2
Distribution domain
These requirements may also be related to transmission domain.
Recommend

<PHY-Dis-01-I-R>
It is recommended to support integration of distributed renewable and nonrenewable energy resources.

<PHY-Dis-02-I-R>
It is recommended to have capability of real-time data acquisition, aggregation,
distribution automation, and management.
- 32 Smart-O-32Rev.6
9.3
Operation domain
Option

<PHY-Ope-01-I-O>
It may optionally support remote meter management function.
The management function includes meter status, activation/de-activation capability,
error messaging, and fraud detection.

<PHY-Ope-02-I-O>
It may optionally support time synchronization with high accuracy and security.
9.4
Market/ Service Provider domains
<Note> The use case’s sub-title specified in Use Case deliverable is quoted in parentheses after the
requirement identifier for use case related requirements.
Recommend

<PHY-MaSP-01-U-R> (energy information service)
It is recommended to support any communication capability to transfer metering
value and status, and computing capabilities to manipulate the collected data as
energy information.
Option

<PHY-MaSP-02-I-O>
It may optionally provide the storage to store the latest value in smart meter
memory.

<PHY-MaSP-03-I-O>
It may optionally provide periodic reading information function in meter by
authorized market participant(s);

<PHY-MaSP-04-I-O>
It may optionally support remote changes of tariff.

<PHY-MaSP-05-I-O>
It may optionally support a pay-as-you-go or prepayment function (capable of
being introduced/activated remotely).

<PHY-MaSP-06-U-O> (HAN device power metering service)
It may optionally support measurement function of detailed metering of electrical
energy consumption by each HAN device and amount of home.

<PHY-MaSP-07-U-O> (Building Automation Software/System Optimization using
Electric Storage)
It may optionally support the function for receiving, storage and processing of the
tariff schedule.
- 33 Smart-O-32Rev.6

<PHY-MaSP-08-I-O>
It may optionally support mutual authentication and authorization by the operation
centre and the service provider.

<PHY-MaSP-09-U-O> (External clients use the AMI to interact with devices at customer
site)
It may optionally support a secure environment for the storage, processing and
transmission of confidential information data and other sensitive data. This
sensitive data can be optionally unknowable to unauthorized external entities.

<PHY-MaSP-10-I-O>
It may optionally support secure lightweight connectivity for IP or non-IP smart
meter.

<PHY-MaSP-11-I-O>
It may optionally support non-repudiation of service, data integrity, and antitamper function.
9.5
Bulk Generation and Transmission domains
Recommend

<PHY-BGaT-01-I-R>
It is recommended to support remote load control, monitoring, protection and
control of DER, which is typically embedded in the transmission and distribution
systems or in distributed micro-grids.

<PHY-BGaT-02-I-R>
It is recommended to support to sense and measure accurate and real time grid
information (e.g. real time electrical loads) for managing the operations of power
grid.
9.6
Multi domains
Recommend

<PHY-Multi-01-I-R>
It is recommended to support intelligent devices, integrated networks, and
advanced method to maintain stability on the power grid by balancing generation
(supply) with load (demand) across the transmission network.
<Note> This requirement applies to Transmission and Distribution domains.

<PHY-Multi-02-I-R>
It is recommended to support to maintain and synchronize high resolution clocks in
substations and the power grids.
<Note> This requirement applies to Bulk Generation and Transmission domains.

<PHY-Multi-03-I-R>
- 34 Smart-O-32Rev.6
It is recommended to support various communication methods (e.g., centralized,
hierarchical, and peer-to-peer communication) within grid domain.
<Note> This requirement applies to Bulk Generation, Transmission and
Distribution domains.

<PHY-Multi-04-I-R>
It is recommended to support communications with the Operations domain in realtime to manage the power flows with the consideration of factors, including
dynamic pricing, energy transmission cost, reliability, security and others.
<Note> This requirement applies to Transmission and Distribution domains.
- 35 Smart-O-32Rev.6
10
Common requirements for all areas
This clause describes common requirements for the all areas.
<Note> The use case’s sub-title specified in Use Case deliverable is quoted in parentheses after the
requirement identifier for use case related requirements.
Recommend
 <ALL-01-U-R> (energy information service)
It is recommended to support any communication capability to transfer metering
value and status, and computing capabilities to manipulate the collected data as
energy information.
- 36 Smart-O-32Rev.6
11
Gap analysis
In Clause 7, 8, 9, 10 of this document, 174 requirements were identified. Gap analysis in detail was
achieved on these 174 requirements to identify related SDOs and SG (Study Group) / TC
(Technical Committee), etc. In the case of ITU-T, related Questions are also identified. As a lot of
the requirements relate to a plural of SDOs such as ITU-T, IEC, IEEE, etc. 273 relations are
identified (see attached Excel file). The large table in the first spread sheet of the Excel file shows
each study “Status” of each requirement within the identified SDOs. The status was classified as
“Already studied”, “Study in progress”, and “For further study”.
As a result of the second Gap analysis after reflection of above analysis, 51% of the relations
indicate ITU-T, and 20% of them indicate IEC (Table 11-1, Chart 11-1). However, as the analysis
was done by mainly ITU-T related people, the activities of other SDOs such as IEEE, ETSI, etc.
may be caused underestimation.
Note: The figures in Table 1 indicate the number of “Relations” but not the number of
“Requirements”. As shown above, 273 “Relations” was identified from 174 “Requirements”, so be
careful for the figures in the tables.
In the case of ITU-T, 64% of them are seemed “already studied”, 19% of them are “in progress”,
and 17% of them are in the status of “For further study” (Chart 11-2).
Relations assigned separately by Study Groups are shown (Table 11-2, Chart 11-3). SG13, SG15,
SG16, and SG12 are observed as major places of the studies, while SG2, SG17, SG11, and SG9 are
also related.
Table 11-1: The number of requirements by related SDOs
ITU-T
IEC
3GPP
ETSI
IEEE
ISO/IEC JTC 1
IETF
ITU-R
Total
Already studied For further study Study in progress Not identified
89
24
27
5
8
23
19
5
18
8
1
8
10
4
2
6
2
1
5
2
1
4
1
132
35
84
22
Total
140
55
23
17
16
9
8
5
273
- 37 Smart-O-32Rev.6
Chart11-1:
Chart11- 2:
Requirements Ratio of related SDOs
Study Status of requirements in ITU-T
Table 11-2: Gap analysis in ITU-T
SG13
SG15
SG16
SG12
SG2
SG17
SG11
SG9
Total
Already studied
29
24
8
14
7
3
3
1
89
For further study
8
6
8
1
Study in progress Not identified
7
5
12
3
1
24
27
Chart 11-3: Requirements by SG
0
Total
44
35
28
18
7
4
3
1
140
- 38 Smart-O-32Rev.6
The table below shows examples of detailed analysis
Table 11-3: Example detailed analysis
Identifier
Requirements
Analysis
Status
1
S/A-Cus-01-U-R
It is recommended to support any collection
function of status information from devices,
displaying capability and others.
Seems new function
for multimedia
devices
For
further
study
2
S/A-Cus-12-I-R
It is recommended to support security function
such as non-repudiation, data integrity, user
authentication, etc.
For customer
premises, not
enough studied
For
further
study
3
S/A-Cus-19-I-O
It may optionally support monitoring and
management to electrical amount charge of
electrical vehicle.
Seems new function
For
further
study
4
COM-Gen-08-I-R
It is recommended that home appliances are
connected to a smart meter and ESI through
HAN.
Smart meter
interface is not fixed
For
further
study
5
COM-Gen-09-I-R
It is recommended that the Communication area
supports secure information exchange between
household electrical nodes and servers in the
power utility.
Not studied for
servers in the power
utility
For
further
study
6
COM-Gen-10-I-O
It may optionally support new QoS functions for
the Communication area, if smart grid
applications require.
May be required
new Qos functions
with smart grid
applications
For
further
study
7
COM-IA-DM-02-I-R
It is recommended to reduce traffic load of
communication network by data aggregation,
suppression and unification of interface.
Influence of utility
networks has not
studied
For
further
study
8
PHY-Cus-06-I-O
It may optionally support vehicle
communications including V2V, V2I and V2G in
mobile environments.
Vehicle
communications has
not enough studied
For
further
study
9
PHY-Cus-07-I-O
It may optionally support interworking with
several grid interfaces, e.g., V2G and H2G.
Vehicle
communications has
not enough studied
For
further
study
10
PHY-Cus-08-I-O
It may optionally support charging/billing/energy
management in V2G.
Vehicle
communications has
not enough studied
For
further
study
11
PHY-Cus-09-I-O
It may optionally support new applications
combined telecom services for EV.
Vehicle
communications has
not enough studied
For
further
study
12
PHY-Cus-10-I-O
It may optionally support remote management of
the battery charging of EV.
Vehicle
communications has
not enough studied
For
further
study
13
PHY-Cus-11-I-O
It may optionally support energy efficient
transportation of EV (energy savings).
Vehicle
communications has
not enough studied
For
further
study
- 39 Smart-O-32Rev.6
Annex A Summary of Smart Grid Requirements with Use cases
The following Table A-1 shows relation between the requirements in this Deliverable and the use cases in the Use Case Deliverable. The table’s rows
correspond to use cases in the Use Case Deliverable and its columns correspond to the three areas, i.e., Smart Grid Services/Applications area,
Communication area and Physical Equipment area. The requirements in this Deliverable are placed either in a “common requirement” sub-column or
an “extract from the Use Cases” sub-column in each area’s column according to source of the requirements, except for the requirements concerning all
three areas, which are classified as “All areas.”
Example: In the group of ‘Demand Response’ in the left column, Use case ‘DR&CEE11: Energy management service’ has requirements on Smart Grid
Services/Applications area and Physical Equipment, as shown in each area’s column. The requirement on Smart Grid Services/Applications area has
identifier ‘S/A-SP-01-U-R’. The requirement on Physical Equipment area has identifier ‘PHY-Cus-12-U-O’.
Table A-1: Summary of Smart Grid Requirements
Smart Grid Services/Applications area
common
extract from the
requirement
Use Cases
Communication area
extract from the Use
common requirement
Cases
Demand Response
DR &
CEE1
DR &
CEE2
DR &
CEE3
DR &
CEE4
DR &
CEE5
DR &
CEE6
Customer Reduces Their Usage in Response to Pricing
or Voluntary Load Reduction Events
Customer Uses an EMS or IHD
Customer Uses Smart Appliances
DRMS Manages Demand Through Direct Load Control
DRMS Manages Demand in Response to Pricing Signal
External clients use the AMI to interact with devices at
customer site
Physical Equipment area
common
extract from the
requirement
Use Cases
SP
COM-Gen-01-I-R,
COM-Gen-02-I-R,
COM-Gen-03-I-R,
COM-Gen-04-I-R,
COM-Gen-05-I-R,
COM-Gen-06-I-R,
COM-Gen-07-I-R,
COM-Gen-08-I-R,
COM-Gen-09-I-R,
COM-Gen-10-I-O,
COM-CN-Gen-01-I-R,
COM-CN-Gen-02-I-R,
PHY-MaSP-02-I-O,
PHY-MaSP-03-I-O,
PHY-MaSP-04-I-O,
PHY-MaSP-05-I-O,
PHY-MaSP-08-I-O,
PHY-MaSP-10-I-O,
PHY-MaSP-11-I-O,
- 40 Smart-O-32Rev.6
DR &
CEE7
Dynamic pricing - ESP Energy and Ancillary Services
Aggregation
DR &
CEE8
DR &
CEE9
DR &
CEE10
DR &
CEE11
DR &
CEE12
DR &
CEE13
DR &
CEE14
DR &
CEE15
Utility Procures Energy and Settles Wholesale
Transactions Using Data from AMI System
Voltage, Var, and Watt Control (VVWC) with DR, DER,
PEV, and ES
Energy control
Energy management service
S/A-SP-01-U-R
Dynamic pricing related service
Dynamic pricing information transfer to BEMS through
ESI
S/A-SP-02-U-R
DR message transfer to BEMS through ESI
Demand response signal generation for controlling home
appliances
S/A-SP-05-U-R
S/A-SP-03-U-R
WASA
WASA1
Contingency Analysis (CA)-Future (advanced)
WASA2
Inter-Area Oscillation Damping
Monitoring Distribution Operations with DR, DER, PEV,
and ES
Wide-Area Control System for the Self-Healing Grid
(SHG)
WASA3
WASA4
WASA5
WASA6
Synchro-Phasors
Voltage Var and Watt Control (VVWC) with DR, DER,
PEV, and ES
WASA7
Load Shedding
WASA8
Voltage Security
WASA9
WASA1
0
WASA1
1
Wide-Area Monitoring and Control
Monitoring of high voltage power transmission line and
transmission tower
The use case regarding the Unmanned Aerial Vehicle
(UAV) for overhead transmission line
Energy Storage
Building Automation Software/System Optimization
ES1
using Electric Storage
S/A-BG-01-I-R,
S/A-BG-02-I-R,
COM-CN-Gen-03-I-R,
COM-CN-Gen-04-I-R,
COM-CN-Gen-05-I-R,
COM-CN-Gen-06-I-R,
COM-CN-Gen-07-I-R,
COM-CN-Gen-08-I-R,
COM-CN-ON-01-I-R,
COM-CN-IMT-01-I-R,
COM-CN-IMT-02-I-R,
COM-CN-IMT-03-I-R,
COM-CN-IMT-04-I-R,
COM-CN-IMT-05-I-R,
COM-CN-IMT-06-I-R,
COM-CN-IMT-07-I-R,
COM-CN-HAN-01-I-R,
COM-CN-HAN-02-I-R,
COM-CN-HAN-03-I-R,
COM-CN-NS-01-I-R,
COM-CN-NS-02-I-R,
COM-CN-NS-03-I-R,
COM-CN-IP-01-I-R,
COM-CN-AC-01-I-R,
COM-CN-AC-02-I-R,
COM-CN-QoS-01-I-R,
COM-CN-QoS-02-I-R,
COM-CN-QoS-03-I-R,
COM-CN-QoS-04-I-R,
COM-CN-QoS-05-I-R,
COM-CN-QoS-06-I-R,
COM-CN-QoS-07-I-R,
COM-CN-QoS-08-I-R,
COM-CN-QoS-09-I-R,
COM-CN-QoS-10-I-R,
COM-CN-QoS-11-I-R,
COM-CN-QoS-12-I-R,
COM-CN-QoS-13-I-R,
COM-CN-OAM-01-I-R,
COM-CN-OAM-02-I-R,
COM-CN-OAM-03-I-R,
COM-CN-OAM-04-I-R,
COM-CN-PaR-01-I-RQ,
COM-CN-PaR-02-I-R,
PHY-Cus-12U-O
COM-CN-OAM-09-U-R
PHY-BGaT-01-I-R,
- 41 Smart-O-32Rev.6
ES2
Impact of PEV as Load and Electric Storage on
Distribution Operations
ES3
ES Owners Discharge Energy into the Power System
ES4
ES Owners Store Energy from the Power System
ES5
ES7
Electric Storage Provides Fast Voltage Sag Correction
RTO/ISO Dispatches Electric Storage to Meet Power
Demand
Utility Dispatches Electric Storage to Support
Intentional Islanding
ES8
Dynamic pricing based Storage Control
ES9
Premise electrical power storage management service
ES10
Energy Storage Clustering
ES6
S/A-BG-03-I-R,
S/A-BG-04-I-R,
S/A-Multi-01-U-R
Electric Vehicle to Grid interaction
EVGi1
Electric Vehicle Load Management
EVGi2
EVGi3
Customer Connects PEV to Premise Energy Portal
Impact of PEV as Load and Electric Storage on
Distribution Operations
EVGi4
EV Network Test
EVGi5
PEV Default Charge Mode
EVGi6
Utility Provides Accounting Services to PEV
EVGi6
S/A-Cus-09-U-R,
S/A-Cus-10-U-R,
S/A-Cus-11-U-R,
S/A-Cus-13-U-R,
Management for V2G Service
AMI Systems
Building Automation Software/System Optimization
AMI1
using Electric Storage
AMI2
DRMS Manages Demand Through Direct Load Control
AMI3
Electrical Vehicle Load Management
S/A-Ope-01-I-R
AMI4
AMI5
External clients use the AMI to interact with devices at
customer site
Impact of PEV as Load and Electric Storage on
Distribution Operations
COM-CN-PaR-03-I-R,
COM-CN-PaR-04-I-R,
COM-CN-PaR-05-I-R,
COM-CN-PaR-06-I-R,
COM-CN-PaR-07-I-R,
COM-CN-PaR-08-I-R,
COM-CN-PaR-09-I-R,
COM-CN-CaR-01-I-R,
COM-CN-CaR-02-I-R,
COM-CN-CaR-03-I-R,
COM-CN-CaR-04-I-R,
COM-CN-NM-01-I-R,
COM-CN-NM-02-I-R,
COM-CN-NM-03-I-R,
COM-CN-NM-04-I-R,
COM-CN-NM-05-I-R,
COM-CN-NM-06-I-R,
COM-CN-NM-07-I-R,
COM-CN-NM-08-I-R,
COM-CN-EDM-01-I-R,
COM-CN-EDM-02-I-R,
COM-CN-EDM-03-I-R,
COM-CN-EDM-04-I-R,
COM-CN-EDM-05-I-R,
COM-CN-EDM-06-I-R,
COM-CN-GW-01-I-R,
COM-CN-GW-02-I-R,
COM-CN-GW-03-I-R,
COM-CN-GW-04-I-R,
COM-CN-GW-05-I-R,
COM-CN-GW-06-I-O,
COM-CN-Cbl-01-I-O,
COM-IA-DM-01-I-R,
COM-IA-DM-02-I-R,
COM-IA-DM-03-I-R,
COM-IA-DM-04-I-R,
PHY-BGaT-02-I-R,
PHY-Multi-02-I-R,
PHY-Multi-03-I-R,
PHY-MaSP-07U-O
PHY-Ope-01-I-O,
PHY-Ope-02-I-O,
PHY-Cus-12U-O,
PHY-MaSP-09U-O
- 42 Smart-O-32Rev.6
AMI6
AMI7
Dynamic pricing - ESP Energy and Ancillary Services
Aggregation
AMI8
Utility Provides Accounting Services to PEV
Voltage, Var, and Watt Control (VVWC) with DR, DER,
PEV, and ES
AMI9
HAN device power metering service
PHY-MaSP-06U-O
COM-CN-OAM-10-U-R
Distribution Grid Management
Coordination Emergency and Restorative Actions in
DGM1
Distribution
Monitoring Distribution Operations with DR, DER, PEV,
DGM2
and ES
Impact of PEV as Load and Electric Storage on
DGM3
Distribution Operations
DGM4
DGM5
Service Restoration
Voltage, Var, and Watt Control (VVWC) with Dr, DER,
PEV, and ES
S/A-Multi-01-U-R
DGM6
Electrical power sharing service
S/A-TaD-01-U-R,
S/A-TaD-02-U-R,
S/A-TaD-03-U-R,
S/A-TaD-04-U-R,
DGM7
DER status transfer to BMS
S/A-TaD-02-U-R
PHY-Dis-01-I-R,
PHY-Dis-02-I-R,
PHY-Multi-01-I-R,
PHY-Multi-03-I-R,
PHY-Multi-04-I-R,
Market Operations
MO1
Electrical power trading service
MO2
The use case of unattended smart business hall in
smart grid
S/A-Mar-02-I-R,
S/A-Mar-03-I-R,
S/A-Mar-04-I-R
PHY-MaSP-02-I-O,
PHY-MaSP-03-I-O,
PHY-MaSP-04-I-O,
PHY-MaSP-05-I-O,
PHY-MaSP-08-I-O,
PHY-MaSP-10-I-O,
PHY-MaSP-11-I-O,
S/A-Cus-12-I-R,
S/A-Cus-14-I-R,
S/A-Cus-15-I-R,
S/A-Cus-16-I-R,
S/A-Cus-17-I-R,
S/A-Cus-18-I-R,
S/A-Cus-19-I-O,
S/A-Cus-20-I-O,
PHY-Cus-02-I-R,
PHY-Cus-03-I-R,
PHY-Cus-04-I-R,
PHY-Cus-06-I-O,
PHY-Cus-07-I-O,
PHY-Cus-08-I-O,
PHY-Cus-09-I-O,
PHY-Cus-10-I-O,
S/A-Mar-01-U-R
Existing User's Screens
EUS1
Energy monitor
EUS2
Energy information service
EUS3
EUS4
Premise energy status display service
Remote monitoring and control service using handheld
device
EUS5
Home grid alarm service
S/A-Cus-01-U-R
COM-CN-AN-01-U-R,
PHY-MaSP-01U-R
PHY-Cus-01U-R
- 43 Smart-O-32Rev.6
EUS6
Monitor of electric power and appliances operating
status
EUS7
Flexible Energy Management service
Managing Appliances Through/By Energy G/W
Charging management for appliances including electric
MA1
vehicle at home
MA2
S/A-Cus-21-I-O,
PHY-Cus-11-I-O,
S/A-Cus-02-U-R
S/A-Cus-03-U-R
COM-CN-OAM-05-U-R,
COM-CN-OAM-06-U-R
S/A-Cus-04-U-R,
S/A-Cus-05-U-R
PHY-Cus-05U-R
MA3
HAN device power management service
Detailed metering information transfer to BEMS through
ESI
S/A-Cus-06-U-R
MA4
BEMS controls electric consuming device through ESI
S/A-Cus-07-U-R
Control of Electric Vehicle
CEV1
Charging for electric vehicle
CEV2
Electric Vehicle Roaming
CEV3
EV information transfer to BEMS
COM-CN-OAM-08-U-R
CEV4
BEMS controls EV's electric charge and discharge
COM-CN-OAM-07-U-R
Distributed Energy Generation/ Injection
DEGI1
Renewable system management service
S/A-Cus-08-U-R
Other use cases
SPB1
Senior case
SPB2
Life support
GICT1
Home security
GICT2
Monitor of climate change
LBS
LBS-based Home Device Control
EUS2
Energy information service
S/A-Cus-02-U-R,
S/A-SP-04-U-R
S/A-Cus-02-U-R,
S/A-SP-04-U-R
COM-CN-HAN-01-I-R
ALL areas
ALL-01-U-R
- 44 Smart-O-32Rev.6
Appendix I Source materials for requirements on technical elements
Appendix I shows contributed requirements on technical elements. The requirements in Clause 7
through 10 were derived from the contributed requirements. They are listed here as source
information.
The contributed requirements are described by the following template.
New Requirement No.
Identification of requirements in main text
Requirement No.
Identification of requirements
Domains
Communication features
Identification of planes and layers
Requirement
Type of requirement
Required or May Optionally, and its condition if needed.
Required in Case A, May Optionally in Case B
Background
To enhance readability, some description is provided.
Reference
Gap analysis
Relationship between this requirement and conventional standard
Detailed technical requirements are mapped into matrix of Plane and Layer as shown in Figure I-1.
- 45 Smart-O-32Rev.6
Transport plane
Application
(e.g., Data model for
Smart Grid)
I.4
Transport Layer
(e.g., TCP)
I.3
Control plane
Management plane
I.11, I.15
I.5
I.7
I.6, I.12
I.8
Network Layer
(e.g., IP)
I.2
I.9, I.13, II.2
Data link Layer
(e.g., MAC)
I.1, I.14
Physical Layer
Overall
10, I.10, II.1, II.3
Figure I-1: Classification of points for requirements
I.1 Requirement on transmission
When optical network is deployed for smart grid applications, it is better that the number of
connecting point between optical and electric portions is minimized. For this purpose, the following
requirement is described.
New requirement no
COM-CN-ON-01-I-R
Requirement No.
I-i-0065-1
Address
All
Position of requirements
Physical layer
Requirement
The O-E-O relay systems should be reduced in the wide area
optical transmission and the non-relay ultra-long span optical
transmission are required be used in the smart grid.
Type of requirement
Required.
- 46 Smart-O-32Rev.6
Background
In the electricity grid, the transmission voltage is improved to
reduce the line losses. In recent years Ultra-high voltage (UHV)
electricity transmission techniques are being researched and
deployed. High voltage transmission plays an important role in
smart grid because it can reduce the electricity network cost, save
the land and space, and promote the transmission distance. That’s
why UHV transmission networks are under construction in many
countries, such as USA, China, Japan, etc.
As the UHV transmission technique develops, the distances
between the electricity substations/ power plants are becoming
longer and longer. For example, the distance in the 500kV
alternating current (AC) transmission system can reach 300 km,
and for ±500 kV direct current (DC) transmission systems, the
distance may be over 1000km. Many projects deploying UHV
techniques have been built all over the world, e.g. China has
completed 1000kV AC Xiangjiaba to Shanghai and ±800kV DC
Jindongnan to Jingmen UHV transmission demonstration
projects.
On the other hand, the optical fiber transmission techniques will
be no doubt widely deployed in smart grid for transmitting
various data owing to its huge capacity, interference tolerance,
low maintenance cost and low transmission loss.
When developing UHV transmission networks, generally, the
optical transmission systems and fiber composite cable, such as
Optical Fiber Composite Overhead Ground Wire (OPWG), are
setup along with the electricity transmission lines. To guarantee
the Signal Noise Ratio (SNR) of the optical transmission system,
the O-E-O optical relay system needs to be used. But high
voltage transmission lines are generally built in wild areas, e.g.
over the mountains, the cost of a O-E-O relay system is very
expensive. It is not reliable and hard to repair when it fails. Thus,
it makes it more difficult to reduce the cost and promote the
reliability of smart grid.
As a result, minimizing the optical relay systems is a requirement
of smart grid to save the construction and operation cost, and to
promote the stability and safety. Non-relay ultra-long span
optical transmission becomes the best candidate technique to
guarantee the SNR in this situation.
Ultra-long span optical transmission is also called Ultra-long
haul optical transmission. It includes a serial of optical
transmission techniques which are used to realize the ultra-long
distance optical signal transmission without any O-E-O
conversions. These techniques include optical fiber (such as ITUT G.652B), Raman amplifier, erbium-doped fiber amplifier
(EDFA), remote pump, chromatic-dispersion compensation
(CDC), forward error correction (FEC, such as G.709), and etc.
Reference
none
- 47 Smart-O-32Rev.6
Gap analysis
I.2 Transport QoS requirements based on NGN
Smart grid applications should be transferred on WAN or End-to-End shown in Figure I-2
according to specified QoS classes based on NGN. On the other hand, if these applications require
new QoS features, such as new QoS class, traffic descriptor, mechanisms and others, FG-SMART
inputs these requests to ITU-T related SGs, such as SG12, SG13, and SG15.
- 48 Smart-O-32Rev.6
Domain 1
GW
WAN
Domain 2
GW
(a) WAN case
Domain 1
WAN
Domain 2
End Device
End Device
(b) End-End case
If Domain is Customer, this Domain is HAN which complies with
home network architecture specified in ITU-T SG9 and SG15.
Figure I-2: QoS management model
The detailed requirements are described as follows.
New Requirement No.
COM-CN-QoS-05-I-R, COM-CN-QoS-06-I-R
Requirement No.
I-i-0035-1
Address
WAN
Position of requirements
Plane: Transport
Layer: Network and Data Link Layers
Requirement
If information is communicated on IP, QoS class should be specified in
each communication for smart grid. Required performance between
edges of WAN on IP layer should be specified every application, and
should be categorized into Classes 0, 1, 2, 3, 4, U according to ITU-T
Y.1541 [ITU-T Y.1541]. Moreover, on data link layer, performance
should be controlled to comply with IP layer performance.
Type of requirement
Required in the case of transport on NGN or managed IP network
May Optionally in other cases
Background
Information for smart grid includes critical data which is sensitive of
delay, delay variation, and loss. Therefore, performance on WAN
should be clarified.
Reference
ITU-T Y.1541
Gap analysis
Currently, ITU-T Y.1541 does not mention smart gird in guidance for
IP QoS classes. Since smart grid can be supported as an application on
NGN or other managed IP network including utility network, smart grid
should be added to guidance for IP QoS classes.
- 49 Smart-O-32Rev.6
New Requirement No.
COM-CN-QoS-05-I-R, COM-CN-QoS-06-I-R
Requirement No.
I-i-0035-2
Address
WAN and HAN
Position of requirements
Plane: Transport
Layer: Network and Data Link Layers
Requirement
Requirement I-i-0035-1 should be applied for HAN in addition to
WAN.
Type of requirement
May Optionally
Background
QoS guarantee service can extend to end devices beyond GW, such as
NGN Release 2.
Reference
ITU-T Y.2011 [b-ITU-T Y.2011], ITU-T Y.ngn_hn, ITU-T G.9971
Gap analysis
Current recommendations do not mention smart grid service.
New Requirement No.
COM-CN-Gen-02-I-R, COM-CN-HAN-03-I-R
Requirement No.
I-i-0035-3
Address
WAN and HAN
Position of requirements
Plane: Transport
Layer: Network and Data Link Layers
Requirement
Traffic flow on IP layer and on Data link layer should be characterized
by IP QoS parameters as follows.
IPTD (IP Transfer Delay)
IPDV (IP Delay Variation)
IPLR (IP Loss Ratio)
IPER (IP Error Ratio)
IPRR (IP Reordering Ratio)
Moreover, other dedicated parameters for smart grid can be added.
Type of requirement
Required
Background
To guarantee QoS classes, characterized parameters of traffic flows are
required.
Reference
Gap analysis
I.3 Other transport QoS requirements
In addition to NGN, when WAN is configured by wireless network, such as 3G and LTE, smart grid
applications comply with QoS capability specified in 3GPP. Moreover, wireless communication
over broadband wired line by FMC is also categorized into this case.
- 50 Smart-O-32Rev.6
New Requirement No.
COM-CN-QoS-07-I-R, COM-CN-QoS-13-I-O
Requirement No.
I-i-0062-1
Address
WAN
Position of requirements
Plane: Transport
Layer: Network and Data Link Layers
Requirement
QoS of application to application SHALL be possible using SIP Control
specified in IMS with Policy Control to the Transport Plane.
Type of requirement
Required: Case A if supported in the Communications network the IMS
core network evolution of IMT-2000 & IMT-Advanced.
May Optional in Case B where the NGN required IMS Core Network
support – access network based on fixed FMC solutions
Background
This refers to Session Initiation Protocol & control using SIP & the QoS
guarantees as specified in IMS. The access network may require GPRS
Tunnelling as specified in 3GGP for Mobile networks specified in IMT2000 & IMT-Advanced or other FMC required QoS enforcement. To
provide communication with guarantee of quality and robust security,
NGN control architecture based on IMS, as defined in www.3gpp.org
TS 22.228 (Stage 1) TS 23.228 (Stage 2) & TS 24.229 (Stage 3) can be
applied for these services. Therefore, this section focuses on control
mechanisms by SIP.
This Specification is evolving in Release 10 (2010) & Release 11
(2011), based on the NIMTC “Network Improvements for Machine
Type Communications” covering Smart Metering and Smart Grid as
contributed by 3GPP Members [www.3gpp.org TR 23.888] Title:
“Architectural Enhancements for machine-type communications”.
Reference
3GPP TS 22.228 [b-3]; TS 23.228 [b-4] & TS 24.229 [b-5]: IMS
www.3gpp.org
Gap analysis
3GPP TR 23.888 [b-6] NIMTC Feasibility Study for Machine Type
Communications www.3gpp.org
New Requirement No.
COM-CN-QoS-08-I-R
Requirement No.
I-i-0062-2
Address
WAN
Position of requirements
Plane: Transport
Layer: Network and Data Link Layers
Requirement
QoS of application to application SHALL be possible using QoS
guaranteed tunnelling as specified in GPRS.
Type of requirement
Required: Case A if supported in the Communications network the IMS
- 51 Smart-O-32Rev.6
core network evolution of IMT-2000 & IMT-Advanced.
Background
This refers to the QoS guarantees as specified in GPRS. The access
network may require GPRS Tunnelling as specified in 3GGP for Mobile
networks specified in IMT-2000 & IMT-Advanced. To provide
communication & enforce policies guarantee of quality and robust
security. The services are to be included in [www.3gpp.org TS 23.060].
This Specification is evolving in Release 10 (2010) & Release 11
(2011), based on the NIMTC “Network Improvements for Machine
Type Communications” covering Smart Metering and Smart Grid as
contributed by 3GPP Members [www.3gpp.org TR 23.888] Title:
“Architectural Enhancements for machine-type communications”.
Reference
3GPP TS 23.060 [b-7] & TS 29.060 [b-8]: GPRS www.3gpp.org
Gap analysis
3GPP TR 23.888 NIMTC Feasibility Study for Machine Type
Communications www.3gpp.org
I.4 Application level QoS requirement
Application level QOS requirements have been specified in ITU-T G.1010. Smart grid applications
should be added in this recommendation.
New Requirement No.
COM-CN-QoS-04-I-R
Requirement No.
I-i-0035-4
Address
WAN and HAN
Position of requirements
Plane: Transport
Layer: Application
Requirement
Required quality on application revel is required for smart grid.
Type of requirement
Required
Background
ITU-T G.1010 describes required communication quality, such as delay,
and loss tolerance, for triple play services. Therefore, Required end-toend quality for smart grid is should be added.
Reference
ITU-T G.1010
Gap analysis
Current recommendation, ITU-T G.1010, does not mention smart grid
service on required performance. Since smart grid service includes
critical communication, it should be added into G.1010.
- 52 Smart-O-32Rev.6
I.5 Communication control requirements based on exiting architecture
Control mechanisms to connect components for smart grid related components should be required.
IP technology and SIP technology are promising candidates. NGN and IMS frame works can be
applied for connection among devices.
New Requirement No.
COM-CN-QoS-09-I-R, COM-CN-QoS-10-I-R
Requirement No.
I-i-0035-5
Address
WAN and HAN
Position of requirements
Plane: Control
Layer: Network and Transport
Requirement
Traffic flows on Network and/or Transport layers are controlled by
some protocols if need Typically, SIP is applied as one of control
protocols. Control architecture is shown in Figure I-3. Communication
for smart grid is controlled according to this architecture.
Type of requirement
Required
Background
SIP is control protocol in NGN. It is reasonable that network for smart
grid is similar or identical to NGN, because critical information is
transferred on this network.
Reference
ITU-T Y.2001, ITU-T Y.2011
Gap analysis
Recommendations of NGN do not mention smart grid. Smart grid
should be included in NGN.
HAN
WAN
Application server
GW
IP reach ability
GW
Scheme 1
VPN Tunnel
Scheme 2
SIP Tunnel
Scheme 3
SIP Tunnel
SIP termination / initiation point
(SIP adaptation)
VPN Tunnel
SIP Tunnel
SIP Tunnel
SIP Tunnel
SIP Tunnel
Scheme 4
Scheme 5
SIP conversion (SIP proxy)
SIP Tunnel
Scheme 6
- 53 Smart-O-32Rev.6
Figure I-3: Control architecture by SIP for smart grid
Network configuration including RAN should be clarified. The position of RAN in WAN should be
described.
New Requirement No.
COM-CN-IMT-01-I-R
Requirement No.
I-i-0062-3
Address
WAN
Position of requirements
Plane: Control
Layer: Network and Transport
Requirement
Use of 3rd Generation Secure Radio systems within the IMT-2000
family SHALL be possible if RAN is deployed.
Type of requirement
Required if RAN is deployed in Communication Network
Background
Based on SLAs between Energy Providers and Communications
Network Providers, where 3rd Generation Secure Radio Systems are
available. Secure delivery is be ensured using the Subscriber Identity
Module (SIM), if required. ITU-R M.1822 - Framework for services
supported by IMT
Reference
ITU-R M.687 - International Mobile Telecommunications-2000 (IMT2000)
ITU-R M.816 - Framework for services supported on International
Mobile Telecommunications-2000 (IMT-2000)
ITU-R M.817 - International Mobile Telecommunications-2000 (IMT2000). Network architectures
ITU-R M.819 - International Mobile Telecommunications-2000 (IMT2000) for developing countries
ITU-R M.1034 - Requirements for the radio interface(s) for
International Mobile Telecommunications-2000 (IMT-2000)
ITU-R M.1035 - Framework for the radio interface(s) and radio subsystem functionality for International Mobile Telecommunications-2000
(IMT-2000)
ITU-R M.1036 - Frequency arrangements for implementation of the
terrestrial component of International Mobile Telecommunications-2000
(IMT 2000) in the bands 806-960 MHz, 1 710-2 025 MHz, 2 110-2 200
MHz and 2 500-2 690 MHz
ITU-R M.1078 - Security principles for International Mobile
Telecommunications-2000 (IMT-2000)
ITU-R M.1079 - Performance and quality of service requirements for
- 54 Smart-O-32Rev.6
International Mobile Telecommunications-2000 (IMT-2000) access
networks
ITU-R M.1168 - Framework of International Mobile
Telecommunications-2000 (IMT-2000)
Gap analysis
The IMT-2000 family is evaluated by NIST in the Wireless
Characteristics Matrix at PAP02Wireless < SmartGrid < TWiki.
New Requirement No.
COM-CN-IMT-02-I-R
Requirement No.
I-i-0062-4
Address
WAN
Position of requirements
Plane: Control
Layer: Network and Transport
Requirement
Use of 4th Generation Secure Radio systems within the IMT-Advanced
family SHALL be possible when RAN is deployed.
Type of requirement
Required if RAN is deployed in Communication Network.
Background
Based on SLAs between Energy Providers and Communications
Network Providers, where 4th Generation Secure Radio Systems are
available. Secure delivery is be ensured using the Subscriber Identity
Module (SIM), if required.
Key features of ´IMT-Advanced´
 a high degree of commonality of functionality worldwide while
retaining the flexibility to support a wide range of services and
applications in a cost efficient manner;
 compatibility of services within IMT and with fixed networks;
 capability of inter-working with other radio access systems;
 high quality mobile services;
 user equipment suitable for worldwide use;
 user-friendly applications, services and equipment;
 worldwide roaming capability; and,
 enhanced peak data rates to support advanced services and
applications (100 Mbit/s for high and 1 Gbit/s for low mobility
were established as targets for research)*.
These features enable IMT-Advanced to address evolving user needs
and the capabilities of IMT-Advanced systems are being continuously
enhanced in line with user trends and technology developments.
Reference
ITU-R M.1645 - Framework and overall objectives of the future
development of IMT-2000 and systems beyond IMT-2000
Gap analysis
The IMT-2000 family is evaluated by NIST in the Wireless
Characteristics Matrix at PAP02Wireless < SmartGrid < TWiki. The
secure reliable radio communications systems will evolve to IMTAdvanced supporting Higher Bit Rates, Network availability &
- 55 Smart-O-32Rev.6
coverage of broadband, etc... see Recommendation ITU-R M.1645.
New Requirement No.
COM-CN-IMT-01-I-R, COM-CN-IMT-02-I-R
Requirement No.
I-i-0096-1
Address
EV, WAN, and HAN
Position of requirements
Plane: Transport and Control
Layer: Physical to Transport
Requirement
Use of IMT-2000 systems and IMT-Advanced systems, details of
which, including femtocell architecture, 3GPP and 3GPP2 develop,
shall be possible.
Type of requirement
Required
Background
IMT-2000 systems and IMT-Advanced systems, details of which
3GPP and 3GPP2 develop, are among typical mobile
telecommunication networks. Together with a femto base station and
a data-offload feature for it, they could be considered as an element of
a home area network.
Reference
IMT-2000 detailed specifications, developed in 3GPP and 3GPP2,
referred to in ITU-T Recommendations Q.1741.1~6, Q.1742.1~8, and
ITU-R Recommendations M.1457-9, are to be referenced.
Subsequent Recommendations and/or revised ones are developed as
new Releases are issued in 3GPP and 3GPP2; these are supposed to
address IMT-Advanced systems, too. Users of this deliverable are
encouraged to investigate the possibility of applying those upcoming
Recommendations as well.
Gap analysis
IMT-2000 systems are evaluated and IMT-Advanced systems are
partly evaluated by NIST in the Wireless Characteristics Matrix at
PAP02Wireless < SmartGrid < TWiki.
I.6 Communication control requirements based on new architecture
New transport protocols can be applied for smart grid applications as in the following requiremt.
Co-operation between new protocols and exiting protocols, e.g., IP, should be under study.
New Requirement No.
COM-CN-QoS-11-I-R
Requirement No.
I-i-0064-1
Address
All
Position of
requirements
Transport layer
- 56 Smart-O-32Rev.6
Requirement
Optimizing the existing IP-based transport protocols or creating new
transport protocols to achieve both transport reliability and efficiency
should to be considered in Smart Grid.
Type of requirement
Required if new transport protocol is installed.
Background
With IP being used in supporting and developing more and more
services and applications, we can foresee, more and more equipments or
systems in smart grid will use IP-based technology built in order to
achieve better interoperability.
Information collection and transmission related to the power usage and
electricity infrastructure working status is one of the basics in the smart
grid, including information collection from load management
equipments in distribution part, distribution automation terminal
equipments, smart meters in the customer side, and so on. In many
cases, smart grid requires to get responses reliably periodically and
timely. The information needs to be collected and transmitted in a target
time interval (e.g. 1~2 mins) or in a specific interval (e.g. 15 mins). The
volume of most information is very small, while the frequency is quite
high.
The efficiency of the existing IP-based transport protocols is not high
enough to satisfy this requirement. For example, TCP has 20 bytes
length fixed header without including the optional part, while the
information payload, transported in TCP may be only several bytes or
even several bits. If these protocols are used directly for these
information transmissions, the usage efficiency of the transport channel
especially for wireless access will be very low. To solve this problem,
the caching mechanisms are often used. But in many cases, the time
requirement cannot be met in such method. As a result, it becomes
necessary and important to optimize the existing IP-based transport
protocols.
Packet loss in the wired networks is mainly caused by the congestion.
But in wireless networks, bit errors caused by wireless channel and
packet losses caused by handover are being dealt as the same as
congestion by traditional TCP and congestion control measures will be
taken, thus reduces unnecessary end-to-end throughput.
Taking into account other factors such as geography, wireless
information collection equipments (such as various sensors) may be
rolled out with the development of smart gird. So in order to improve
the utilization of radio spectrum resources, Optimizing the existing IPbased transport protocols or creating new transport protocols is required.
Reference
none
Gap analysis
draft-ietf-6lowpan-hc-11 “Compression Format for IPv6 Datagrams in
6LoWPAN Networks”; draft-aayadi-6lowpan-tcphc-00 “TCP header
compression for 6LoWPAN” .
Refer to: www.ietf.org
.
- 57 Smart-O-32Rev.6
I.7 Service convergence function
To provide reliable and effective communication, two platforms is specified between customer
domain and others, such as Management PF and Agent PF. Customer domain communicates
Management PF using IF-2. Other domains communicate this PF using IF-3. In addition to this
scenario, a part of these domains can be supplied by Agent PF to simplify functionality of these
domains and IF-3. Various services provided by Customer domain converge on Agent PF using IF4 in this scenario.
Power Company,
Market,
Service provider,
Operations domains
Customer domain
Agent PF
IF-4
IF-3
IF-3 Management IF-2
GW
PF
Figure I-4: Management PF and Agent PF for service convergence
New Requirement No.
COM-IA-DM-03-I-R, COM-IA-DM-04-I-R
Requirement No.
I-i-0103-1
Address
WAN
Position of requirements
Plane: Control
Layer: Network and Transport
Requirement
To simplify accessing to and controlling interfaces of home/office
equipment such as home appliances and sensors in consumer domain,
the followings shall be supported at the interface between Management
PF and Service providers.
The interface provides
- 58 Smart-O-32Rev.6
- the common method to set and get conditions of any home/office
equipment
- the function of virtual device management to show complicated
plural home/office equipment as one virtual device
Type of requirement
Required
Background
There are various kinds of equipment in home and office. The access
and control method to them is complicated to develop applications. To
connect the consumer domain and other domains, a component to
simplify accessing to and controlling the interfaces of home/office
equipment is required, such as Management PF.
Reference
Smart-I-41, Smart-I-70r3
Gap analysis
This WAN interface and function such as Management PF had not been
mentioned in NIST.
I.8 Requirements based on 3GPP base network
If smart grid applications are provided on WAN complying with 3GPP, the remarkable
requirements should be supported as follows.
Specific issues for smart grid applications should be highlighted.
New Requirement No.
COM-CN-IMT-04-I-R
Requirement No.
I-i-0068-1
Address
WAN
Position of
requirements
Plane: Management
Requirement
The solution must avoid operator lock-in for the service provider and/or
end user. Changing access provider at initial deployment or afterwards
shall be possible without requiring hardware changes, e.g. it need not
require physical changing of Identity Modules.
Type of requirement
Required where existing Communication networks/systems based on
3GPP are reused
Background
See TR 22.812
Reference
3GPP TS 22.368 [b-9] www.3gpp.org
3GPP TR 23.888 www.3gpp.org
ETSI TR 102 691 [b-10]
Gap analysis
3GPP TR 23.888 NIMTC Feasibility Study for Machine Type
Communications www.3gpp.org
New Requirement No.
COM-CN-IMT-05-I-R
Layer: Network and Transport
- 59 Smart-O-32Rev.6
Requirement No.
I-i-0068-2
Address
WAN
Position of
requirements
Plane: Management
Requirement
Remote provisioning of connectivity SHALL be possible.
Type of requirement
Required if subscription is required on a per user basis on reuse of a
capability in Communication networks/systems based on 3GPP
Background
This refers to remote provisioning of SIM related information (e.g. based
on MCIM-type functionality). When the user turns on the device for the
first time, SIM information such as operator data may not be in place.
Typically, the user can be requested to enter “country of residence” and
other information that can be used for the registration process and
selection of operator information. As a result, home operator information
(e.g. AKA related information) is downloaded so the device can register
for network connectivity. Other means than end-user provided
information can be used for selecting network provider, including service
and/or device provider supplied information
Reference
3GPP TS 22.368 www.3gpp.org
3GPP TR 33.812 [b-11] www.3gpp.org
Layer: Network and Transport
Gap analysis
New Requirement No.
COM-CN-IMT-06-I-R
Requirement No.
I-i-0068-5
Address
WAN
Position of
requirements
Plane: Transport and Control
Requirement
It shall be possible to broadcast messages via point-to-multipoint
relations to vehicles located in a given geographical area from network to
vehicles (uni-directional).
Type of requirement
Required where existing Communication networks/systems based on
3GPP
Background
Avoid increasing delay in most unicast scenarios with increasing number
of receivers.
Reference
3GPP TS 22.368 www.3gpp.org
3GPP TR 23.888 www.3gpp.org
ETSI TR 102 691
Gap analysis
3GPP TR 23.888 NIMTC Feasibility Study for Machine Type
Communications www.3gpp.org
New Requirement No.
COM-CN-IMT-07-I-R
Layer: Network and Transport
- 60 Smart-O-32Rev.6
Requirement No.
I-i-0068-7
Address
WAN
Position of
requirements
Plane: Transport and Control
Requirement
For fast Multimedia Broadcast and Multicast Services (MBMS)
transmission, a continuously connected broadcast bearer should be
established
Type of requirement
May Optionally, if required on SLA & application, e.g., safety based
application, in 3GG base network.
Background
MBMS is recommended for THW distribution in areas with very high
vehicle density
Reference
3GPP TS 22.368 www.3gpp.org
3GPP TR 23.888 www.3gpp.org
Gap analysis
3GPP TR 23.888 NIMTC Feasibility Study for Machine Type
Communications www.3gpp.org
New Requirement No.
COM-CN-Gen-03-I-R
Requirement No.
I-i-0068-9
Address
WAN
Position of
requirements
Plane: Transport and Control
Requirement
Throttling connectivity usage SHALL be possible, on Cellular & low
bandwidth access.
Type of requirement
Required on Communication Network based on 3GPP
Background
Based on SLAs, the usage of connectivity is monitored and throttled, on
Cellular & low bandwidth access, if needed.
Reference
3GPP TS 22.368 www.3gpp.org
3GPP TR 23.888 www.3gpp.org
ETSI TR 102 691
Gap analysis
3GPP TR 23.888 NIMTC Feasibility Study for Machine Type
Communications www.3gpp.org
Layer: Network and Transport
Layer: Network and Transport
New Requirement No.
Requirement No.
I-i-0068-10
Address
WAN
Position of
requirements
Plane: Transport and Control
Requirement
The latency shall minimum be (TBD) ms.
Layer: Network and Transport
- 61 Smart-O-32Rev.6
This may be a General requirement not just for WAN.
Type of requirement
Required on Communications network based on 3GPP.
Background
Delays acceptable for PLC (Power Line Communications) based
Metering, to 6ms latency related to Tele-protection
Reference
3GPP TS 22.368 www.3gpp.org
3GPP TR 23.888 www.3gpp.org
ETSI TR 102 691
Gap analysis
3GPP TR 23.888 NIMTC Feasibility Study for Machine Type
Communications www.3gpp.org, considering times 50ms-100ms
New Requirement No.
COM-CN-Gen-04-I-R
Requirement No.
I-i-0068-11
Address
WAN
Position of
requirements
Plane: Transport and Control
Requirement
Devices, servers and services shall ensure that output from it is sent at a
rate that can be handled by the receiver and the communication path.
Layer: Network and Transport
This may be a end2end requirement not just on the WAN.
Type of requirement
Required on Communications Network based on 3GPP.
Background
The platform shall not overload external entities or services running on it
with input.
A service should not overload other entities with input.
Reference
3GPP TS 22.368 www.3gpp.org
3GPP TR 23.888 www.3gpp.org
ETSI TR 102 691
Gap analysis
3GPP TR 23.888 NIMTC Feasibility Study for Machine Type
Communications www.3gpp.org
New Requirement No.
COM-CN-Gen-05-I-R
Requirement No.
I-i-0068-12
Address
WAN
Position of
requirements
Plane: Transport and Control
Requirement
Separation of communications services and data/information services.
Separate QoS may be applied to the services.
Type of requirement
Required where existing Communication networks/systems based on
3GPP.
Background
Existing communications infrastructures shall be re-used with a minimum
Layer: Network and Transport
- 62 Smart-O-32Rev.6
of impact. Communications services have a device focus. Separate from
communications services is the functionality to handle and process
application related data. This is provided by a separate infrastructure that
is information-centric.
Reference
3GPP TS 22.368 www.3gpp.org
3GPP TR 23.888 www.3gpp.org
ETSI TR 102 691
Gap analysis
3GPP TR 23.888 NIMTC Feasibility Study for Machine Type
Communications www.3gpp.org
New Requirement No.
Requirement No.
I-i-0068-13
Address
WAN
Position of
requirements
Plane: Transport and Control
Requirement
Depending on the application, for safety related applications the update
rate for periodic messages SHALL be between specific values (TBD).
Latency SHALL be below TBD ms.
Layer: Network and Transport
This may be a General requirement not just for WAN.
Type of requirement
Required where existing Communication networks/systems are reused.
Background
Safety relevant applications demand a low latency and a sufficient update
rate; changes must be detected as fast as the car driver, or even faster.
Refers to periodic messages from the M2M platform towards devices.
Note: 100ms is fesible in 3GPP networks today & 50ms may be fesible in
future.
Reference
3GPP TS 22.368 www.3gpp.org
3GPP TR 23.888 www.3gpp.org
ETSI TR 102 691
Gap analysis
3GPP TR 23.888 NIMTC Feasibility Study for Machine Type
Communications www.3gpp.org
New Requirement No.
COM-CN-Gen-06-I-R
Requirement No.
I-i-0068-14
Address
WAN
Position of
requirements
Plane: Transport and Control
Layer: Network and Transport
- 63 Smart-O-32Rev.6
Requirement
RTT for device data reading (defined as request sent from service
provider application to reply received by same application; two
transmission paths & some processing time) shall be less than the time of
a customer service call.
Note: round-trip time (RTT) is a big factor in helping to decide what to
do in each case. The Time taken for a customer service call is undefined
but may be unacceptable in times of overload.
This may be a General requirement not just for WAN.
Type of requirement
Required where existing Communication networks/systems based on
3GPP are reused.
Background
Support use case “smart meter via concentrator”, The smart meter reading
procedure shall be performed in the time frame of a call (received by the
utility call center).
Reference
3GPP TS 22.368 www.3gpp.org
3GPP TR 23.888 www.3gpp.org
ETSI TR 102 691
Gap analysis
3GPP TR 23.888 NIMTC Feasibility Study for Machine Type
Communications www.3gpp.org
New Requirement No.
COM-CN-Gen-07-I-R
Requirement No.
I-i-0068-15
Address
WAN
Position of
requirements
Plane: Transport and Control
Requirement
It shall be possible to establish and supervise reliable, secure and highly
prioritized connections with guaranteed QoS between network node
(operated by the broker, the mobile operator or the service provider) and
the device.
Type of requirement
Required where existing Communication networks/systems based on
3GPP.
Background
The security industry is often business critical. It is therefore important
that the connection of alarms and video surveillance cameras (CCTV) can
be trusted and guaranteed. The same is valid for Vehicle RD device or the
Vehicle Gateway.
Reference
3GPP TS 22.368 www.3gpp.org
3GPP TR 23.888 www.3gpp.org
ETSI TR 102 691
Layer: Network and Transport
- 64 Smart-O-32Rev.6
Gap analysis
3GPP TR 23.888 NIMTC Feasibility Study for Machine Type
Communications www.3gpp.org
New Requirement No.
COM-CN-Gen-08-I-R
Requirement No.
I-i-0068-16
Address
WAN
Position of
requirements
Plane: Transport and Control
Requirement
Solutions shall be able to establish a communication session regardless of
network addressing mechanism used, e.g. in case of an IP based network
the session establishment shall be possible when IP static or dynamic
addressing is used.
Type of requirement
Required support where requirement exists.
Background
Static IP address are required by some customers, other examples include
IDSN E.164, IMSI E.214, teluri, sipuri, etc..
Reference
3GPP TS 22.368 www.3gpp.org
3GPP TR 23.888 www.3gpp.org
ETSI TR 102 691
Gap analysis
3GPP TR 23.888 NIMTC Feasibility Study for Machine Type
Communications www.3gpp.org
Layer: Network and Transport
I.9 Requirements of IP-based HAN architecture
When end devices for smart grid applications support IP, IP-bases HAN can be installed. The
architecture of this case is required as follows.
New Requirement No.
COM-CN-HAN-02-I-R
Requirement No.
I-i-0036-1
Address
HAN
Position of requirements
Plane: Transport, Control, Management
Layer: Network and Data link
Requirement
HAN should comply with IP base home network requirements
described in ITU-T G.9971.
Type of requirement
Required
Background
Communication of smart grid is one of applications in HAN.
Requirements of managed home network by network operator are
described in ITU-T G.9971. However, it has not mentioned smart grid.
- 65 Smart-O-32Rev.6
Reference
ITU-T G.9971
Gap analysis
See, background
I.10 Requirements of expansion of M2M communication for smart grid
Machine to Machine communication can be expanded to support smart grid applications. In this
case, the following remarkable requirements should be conformed.
New Requirement No.
COM-CN-EDM-02-I-R
Requirement No.
I-i-0068-3
Address
WAN, HAN, and GW
Position of requirements
All
Requirement
It shall be possible to send a message addressed to a sleeping device.
The AMI/M2M System will deliver the message to the device when it
becomes awake
Type of requirement
To Be Clarified: Necessity depending on domains
Background
Battery operated M2M Devices may have long sleep times.
M2M Applications should be able to send a message to a sleeping M2M
Device, as an example, and have it delivered to the device by the
network when the device is awake. The application should not be
burdened with keeping track of when the device is awake, especially for
devices behind a gateway, for example behind a Zigbee coordinator.
Reference
ETSI TR 102 691
Gap analysis
New Requirement No.
COM-CN-EDM-03-I-R
Requirement No.
I-i-0068-4
Address
WAN, HAN, and GW
Position of requirements
All
Requirement
M2M/AMI & Smart Grid Applications shall be able to specify
scheduling requirements (e.g. message delivery) towards devices over
the service/transport network.
The System shall be able to only allow access to the network during a
(pre)defined time period.
Type of requirement
Required if implemented in cooperation between energy providers and
communication providers.
Background
In many M2M/AMI applications there is generally a flexibility in when
the data is collected from the End Device or pushed into the End
Device. For example, in smart metering it may be sufficient to get a
- 66 Smart-O-32Rev.6
meter reading once every hour and that could be any time within each
hour. The System will benefit from being able to schedule the data
transmission when the network is least congested as this can reduce the
communication costs.
Reference
ETSI TR 102 691
Gap analysis
New Requirement No.
COM-CN-EDM-04-I-R
Requirement No.
I-i-0068-6
Address
WAN, HAN, and GW
Position of requirements
All
Requirement
M2M/AMI & Smart Grid Applications in the Network and Applications
Domain shall be able to request broadcast or multicast message delivery
service from the related System. The delivery may be implemented
through a combination of unicast and multicast e.g. depending on the
access network types.
Type of requirement
Required on Communication Network for M2M
Background
Some M2M/AMI Applications in the Network and Applications
Domain require the same message to be delivered to a number of
Devices. The delivery may be implemented through a combination of
unicast and multicasts depending on the access network types.
Reference
ETSI TR 102 691
Gap analysis
New Requirement No.
COM-CN-EDM-05-I-R
Requirement No.
I-i-0068-8
Address
WAN
Position of
requirements
Plane: Transport and Control
Requirement
The M2M/AMI & Smart Grid System shall be able to optimize
communication paths, based on policies such as network cost or delay
when multiple routes exist.
Type of requirement
Required on Communications Network for M2M.
Background
In some M2M/AMI & Smart Grid Applications the End Device may be
able to communicate over multiple access technologies such as wireline
and wireless with different time-dependent communication costs.
M2M/AMI & Smart Grid Applications will thus benefit from appropriate
route selection.
Layer: Network and Transport
Note: The following requirements text is for further discussion:
A- Operators policies take precedence within an operator domain while
- 67 Smart-O-32Rev.6
M2M/AMI & Smart Grid Application policies apply between different
operators domains.
B- Upon a transmission failure the M2M/AMI & Smart Grid System
shall seek the use of other communication routes.”
Reference
3GPP TS 22.368 www.3gpp.org
3GPP TR 23.888 www.3gpp.org
Gap analysis
3GPP TR 23.888 NIMTC Feasibility Study for Machine Type
Communications www.3gpp.org
New Requirement No.
COM-CN-EDM-06-I-R
Requirement No.
I-i-0068-17
Address
WAN
Position of
requirements
Plane: Transport and Control
Requirement
The M2M/AMI & Smart Grid system must support data/media exchange
both towards and from the End Device, Gateway and Communications
environment as well as multiple traffic patterns. More specifically the
following traffic patterns must be supported:
1 One-shot push/pull requests
2 Periodic push/pull requests
3 Event-driven requests
4 Simultaneous delivery of multiple
data/media streams to/from one Gateway
or Communications environment
Type of requirement
Required where existing Communication networks/systems.
Background
The M2M SE platform is a mediator between the data sources and
Service providers and must support multiple traffic patterns towards the
southbound interface (data source side)
Reference
3GPP TS 22.368 www.3gpp.org
3GPP TR 23.888 www.3gpp.org
ETSI TR 102 691
Gap analysis
3GPP TR 23.888 NIMTC Feasibility Study for Machine Type
Communications www.3gpp.org
Layer: Network and Transport
I.11 Requirements on applications depending on services
To provide smart grid applications, application level requirements are specified. These requirements
depend on provided applications. The following requirement is described as one of examples.
New Requirement No
S/A-Cus-15-I-R
Requirement No.
I-i-0073-1
- 68 Smart-O-32Rev.6
Address
All
Position of
requirements
Application Layer
Requirement
Transferring information for Smart Energy Service between two and
among devices is required to use "Energy Service Profile" in Home
Area Smart Grid (Home Grid). Those devices are listed here but not
limited such as utilities or provider device, Smart meter, ESI(Energy
Service Interface) devices, energy consuming devices, energy storage
devices, energy generating devices, energy information display devices,
handheld smart devices, and others.
Type of requirement
Required
Background
Home Grid refers to Smart Grid in Home Area Network environment.
Smart energy services refer to services which support to enhance energy
efficiency for home user acting as an energy consumer and provider
simultaneously (called as an energy prosumer) with energy storage such
as electrical vehicle. The energy service contains as follows : energy
management, energy trading, energy sharing, energy information
reporting/display, energy usage guidance, and so on.
To describe some of these services, ZigBee SEP(Smart Energy Profile)
1.0 and 2.0(draft) specification defines the object with following the two
categories.
Application Layer Business Objective Messages
- Demand Response / Load Control
- Messaging
- Confirmation Resource
- Pricing
- Pre-Payment
- Metering
- Plug-in Electric Vehicles
- Distributed Energy Resource (DER) Control and Capability
- Billing
- Registration Data Function Set
Application Layer Supporting Messages
Base Function Set:
Time, Basic Device Information, Configuration, Device Capability,
Commission Information, Alarm Log, Power Configuration ,
Randomization, Device Management/Configuration, Migration of
Network Services to Other Devices in the Network, Firmware
- 69 Smart-O-32Rev.6
Download, Diagnostics & Monitoring
Reference
none
Gap analysis
Smart Energy Profile 2.0 [b-12], DRAFT Application Protocol
Specification
Refer to: www.zigbee.org
I.12 Requirements on communication focusing on electric vehicle for smart grid
ITU-T has discussed vehicle communication as expansion of NGN capability. Smart grid
applications can be provided on this communication. In this case, the following requirements are
specified.
New Requirement No.
PHY-Cus-06-I-O, PHY-Cus-07-I-O
Requirement No.
I-i-0039-2
Address
Electric vehicle, WAN and HAN
Position of requirements
Plane: Transport, Control and Management
Layer: Network and Data Link Layers
The followings should be supported for smart grid for electric vehicle:
Requirement

Support of vehicle communications including V2V, V2I, V2G
in mobile environments;

Support of interworking with several grid interfaces, e.g., V2G
and H2G.
Type of requirement
May Optionally
Background
Smart grid is included in an application of electric vehicle services.
Reference
ITU-T Y.2281 (Y.NGN-vehicle)
Gap analysis
ITU-T Y.2281 do not mention smart grid.
NOTE: V2V (Vehicle to Vehicle), V2I (Vehicle to Infrastructure), V2G (Vehicle to Grid), H2G
(Home to Grid)
New Requirement No.
PHY-Cus-08-I-O, PHY-Cus-09-I-O, PHY-Cus-10-I-O, PHY-Cus-11-I-O
Requirement No.
C-i-0039-2
Address
Electric vehicle and intelligent transport systems
Position of
requirements
Plane: Control and Management
Requirement
The followings should be supported for smart grid for electric vehicle:

Support of charging/billing/energy management;
- 70 Smart-O-32Rev.6

Support of new applications combined telecom services;

Support of remote management of the battery charging;

Support of energy efficient transportation (energy savings).
Type of requirement
May Optionally
Background
Smart grid is included in an application of electric vehicle services.
Reference
ITU-T Y.2281 (Y.NGN-vehicle)
Gap analysis
ITU-T Y.2281 do not mention smart grid.
New Requirement No.
S/A-Cus-09-U-R, S/A-Cus-10-U-R, S/A-Cus-11-U-R, S/A-Cus-12-I-R,
S/A-Cus-13-U-R, S/A-Cus-14-I-R
COM-CN-Gen-01-I-R
S/A-Cus-19-I-O, S/A-Cus-20-I-O, S/A-Cus-21-I-O
Requirement No.
Address
Customer Domain
Position of requirements
Service and application
Requirement
To provide V2G services, it is required to support following
requirements
<Recommended requirements for V2G services>
- To support monitoring the EV’s battery state participating to
V2G service
- To support bidirectional metering related to charging and
discharging of V2G capable EV
- To support bidirectional electrical power control for charging
and discharging of EV
- To support communication capability based wire or wireless
network for control, monitoring, energy management, etc.
- To support security function such as non-reputation, data
integrity, user authentication, etc.
- To support monitoring the electrical power state of power grid
such as electrical voltage level, frequency, etc.
- To support interoperability between or among V2G service
entities
<Optional requirements for V2G services>
- To support electrical power management function based on
Dynamic pricing information, DR message, EV operating
schedule, battery state, etc.
- To support monitoring and management for electrical vehicle
- To support user interface for smart energy service using
- 71 Smart-O-32Rev.6
electrical vehicle
Type of requirement
Conditional Required in providing the service
Background
Electrical power system requires balancing between the generated
electrical power and electrical load, power consumed by energy
consumer at any time. As I described in previous description, using of
renewable energy can makes fluctuation into electrical power system.
Using V2G service based on ICT technology, the uncertainty of
electrical power system can be mitigated.
V2G is a system in which EV (electrical vehicle) communicates with
power grid to sell electrical power based on demand response services
by either delivering electrically into the grid or by throttling their
charging rate. Furthermore, the electric vehicle can be used as a
electrical power resources in the V2G system during power grid does
not have adequate power to respond to user demand.
Reference
ITU-T Y.2281 (Y.NGN-vehicle)
Gap analysis
none
Fig. I-5 shows conceptual configuration diagram for the V2G service. Charging and discharging of
EV’s battery are controlled by ICT technology on “grid operator”, charging station, EV’s ICT based
control system, etc.
Figure I-5: Conceptual configuration diagram for V2G service
- 72 Smart-O-32Rev.6
I.13 Requirements for the information exchange specification between the household
electrical appliances and power grid
New Requirement No.
PHY-Cus-02-I-R, PHY-Cus-03-I-R, PHY-Cus-04-I-R
Requirement No.
I-i-0182-1
Address
Position of
requirements
service and application
Requirement
The standardization work should be carried out in the information
exchange interface between the household electrical nodes and the servers
in power utility.
Type of requirement
Required
Background
With the optical fibre access, power line communication or wireless
communication technologies, the real-time power consumption
information of the household electrical appliances, like TV，air
conditioners and electric water heater , can be achieved and monitored online in the utility sector of smart grid by using the smart meters or smart
sockets.
The power consumption information like voltage, frequency and power, is
provided to assist the consumers in altering their power consumption
behaviour by means like remotely controlling appliances power on/off, or
to urge them to reduce the power consumption during peak hours, which
can save consumers money and help reduce CO2 emissions and save
energy.
Many research institute and organizations have do a lot of research and
standardization work in automatic electrical control for household or home
network communication for household appliances field. Some standard
have been set up, such as IEC 60730. However, there is not any standard
about the information exchange interface between the household electrical
nodes and power grid.
We propose that the research and standardization work should be carried
out in the information exchange interface between the household electrical
nodes and power grid
the information exchange specification should offer the data include
voltage, frequency , power and time-of-use price, and define the form of
data type， information exchange process, communication protocol，
coding style, and request/response process.
Reference
Gap analysis
none
- 73 Smart-O-32Rev.6
I.14 Optical fiber transmission in utilization field in the smart grid
New Requirement No.
COM-CN-Cbl-01-I-O
Requirement No.
I-i-0183-1
Address
Position of requirements
Physical layer
Requirement
One kind of composite cable that integrates the optical fibre with the
low voltage power line is required. Further study and standardization is
needed.
Type of requirement
May Optionally
Background
In the smart grid, a robust strong communication network is necessary
to carry out the following applications:
1) AMI: allows the power company to collect, measure, and analyze
energy consumption data from electric meter, outage notification,
and billing purposes in real time via two-way communications.
2) Smart power consumption: Customers can get the details of their
energy consumption, electricity bills, and control their electronic
households according to the tips given by the power company.
3) Distributed generation access: The reliable communications will be
required to monitor, control and effectively use the renewable
energy like photovoltaic generators
4)
Community distribution automation: Realize the distribution
devices control and monitoring, real-time power quality monitoring,
faults location and rapid response to faults that increase the operation
speed to faults and reduce the recovery time.
5)
EV orderly charging: Realize charging data acquisition, charge
pile control, data process and storage, charging events recording,
charging data inquiry, charging control and linkage.
The optical fibre communication is the best choice to construct a robust
strong communication network that links the smart grid and end users,
meet the requirements of explosive growth of real time communication
between the power consumers and the grid.
Like Optical Ground Wire (OPGW) and Optical Phase Conductor
(OPPC), Optical Fibre Composite Low-voltage Cable (OPLC) is a new
type of composite cable which integrates the optical units consisting of
optical fibres and beam tubes into low-voltagecables. OPGW，
referring to ITU L.34, is widely used in high-voltage power lines. OPPC
is widely used in middle-voltage power lines.
With OPLC，fibre can be layout to the home only once in the
- 74 Smart-O-32Rev.6
construction of cable home, which significant saves the cable resources
and pipeline resources, which can accelerate fibre optic access network
deployments, and realize the simultaneous transmission of energy and
information.
OPLC offers the broadband access, and allows data, voice and video
service delivery. Except with the power business such as AMI,
distributed generation, EV charging, etc, the OPLC is capable of
carrying the information services such as internet, telecommunication,
TV broadcasting services known as ‘triple play’, as well as smart home
service such as water and gas meter’s data collection and home security.
Reference
[1] State Grid Corporation of China, Optical fibre composite lowvoltage cable standard.
Gap analysis
I.15 Power grid geographic information system
New Requirement No.
S/A-Ope-01-I-R
Requirement No.
I-i-0218-1
Address
Position of
requirements
Application layer
Requirement
It is recommended to provide the geographical information of
smart grid components, which can be provided by geographic
information system (GIS).
Type of requirement
Required
Background
Most power grid resources are naturally related to geometric
places. GIS is moving from its traditional role as a visualization
engine to a key foundational technology required for smart grid
solutions. GIS has been widely used in the electric industry, to
realize structurally management and visually 3D display of power
grid resources. Every phase of utility business, including
generation, transmission, transforming, distribution, dispatching,
marketing and communication, needs GIS to improve the ability
for data acquisition, analysis and processing. It is also a base
support for smart grid self-healing and reliability.
Power grid infrastructures are important components in the city
plan. Utilities need to share and exchange power grid infrastructure
information with government and other related organizations. The
power grid resource spatial information, provided by power grid
GIS, can be exchanged and shared between the power utility and
the government agencies.
- 75 Smart-O-32Rev.6
Power grid GIS play a fundamental role in the following smart grid
solutions:
1.
Production management system: Based on GIS, to realize the
spatial information management on overhead line, electric
cable, station-type, underground pipe network and key devices.
And to realize functionalities including transmission line
topology analysis, power supply / outage area analysis,
customer load characteristics, power flow Calculation, short
circuit calculation and line inspection touring. Also to enhance
failure/ alarm analyses function and improve the ability to
operate and supervise power grid.
2.
Power grid plan and design: To perform works including
transmission corridor plan, optimal substation allocation and
transformer sizing, route distance analysis.
3.
GIS aided marketing application: To manage geometric
information of business offices / outlets, the connection
between customers and the distribution assets.
4.
Vehicle dispatching and monitoring: Using technologies like
sensor networks, smart tags, GPS, GIS and wireless
communication, to realize the on-line dispatching and
monitoring of vehicles.
5.
Smart mobile terminal operation: Smart mobile terminals,
which mainly include smart inspection touring terminal on
transmission / distribution lines, tablet PC or PDA for field
operations, etc. provide customized function design and
development for different specialties, and meet the
requirements of field operating staff or administrators.
Supported applications cover smart inspection touring,
handheld meter reading, on-site repair, mobile emergency
administration, etc. Advanced communication networks play
an important roll in the seamless connection between
production management information systems and smart mobile
terminal, and have guaranteed the integration of management
and field operation.
6.
Communication resource management: To combine the
communication resources and grid geometric information, e.g.
the geometric information and topology of optic cable
network, to analysis optic cable routes, to calculate the shortest
routes, to locate faults, to improve the ability for
communication network planning and designing.
7.
Disaster prevention & mitigation and emergency respond
administration: To integrate the spatial information,
environment information, power grid information and disaster
information. To provide meteorological alarming figures,
pollution range figures, fire risk figures, wind velocity figures,
thunder figures, and water regimen figures, and to improve the
ability of disaster preventions and alarming. When disaster
- 76 Smart-O-32Rev.6
occurs, to locate the accident regions, to evaluate the effected
ranges and losses, and to increase the response speed for
electric accident handling, using the GIS.
Reference
Gap analysis
none
- 77 Smart-O-32Rev.6
Appendix II Source materials for requirements on components
Appendix II shows contributed requirements on components. The requirements in Clause 7 through
10 were derived from the contributed requirements. They are listed here as source information.
The contributed requirements are described by the following template.
New Requirement No.
Identification of requirements in main text
Requirement No.
Identification of requirements
Domains
Communication features
Identification of planes and layers
Requirement
Type of requirement
Required or May Optionally, and its condition if needed.
Required in Case A, May Optionally in Case B
Background
To enhance readability, some description is provided.
Reference
Gap analysis
Relationship between this requirement and conventional standard
II.1 Detailed Requirements on GW
GW consists of many types in smart grid network. Classification of GW type and definition of
functional requirements in each type should be discussed. The following requirement describes
basic communication function only.
New Requirement No.
COM-CN-GW-02-I-R, COM-CN-GW-06-I-O
Requirement No.
C-i-0036-1
Address
GW between HAN and WAN
Position of requirements
Plane: Transport, Control, Management
Requirement
GW for smart grid should comply with IP Access GW described in
ITU-T G.9970 and G.9971.
Type of requirement
Required (GW associated with Telecom network)
May Optionally (GW associated with Utility network)
- 78 Smart-O-32Rev.6
Background
Smart grid is included in an application of home network services.
Reference
ITU-T G.9970, G.9971
Gap analysis
ITU-T G.9970 and G.9971 do not mention smart grid.
New Requirement No.
COM-CN-GW-03-I-R, COM-CN-GW-04-I-R, COM-CN-GW-05-I-R
Requirement No.
C-i-0097-1
Address
GW between WAN and HAN
Position of requirements
Plane: Transport
Layer: Application
Requirement
GW should support the followings.
- Electric power load management at home, including EV energy
consumption control based on the EV charging status
- Status management of such as charge level, miles driven, driven
pattern, status of whether or not EV is in e.g., garage
- Device management e.g., change EV to charge mode
Type of requirement
Required.
Background
See the use case “Charging management for appliances including
electric vehicle at home” in the WG1 use case deliverable.
Reference
Gap analysis
II.2 Requirements on smart meter
Smart meters are associated with mainly unity network for remote metering. The following
requirement is described as one of examples.
Smart meter is regarded as a kind of GW.
New Requirement No.
PHY-MaSP-02-I-O, PHY-MaSP-03-I-O, PHY-Ope-01-I-O,
PHY-MaSP-04-I-O, PHY-MaSP-05-I-O, PHY-MaSP-06-U-O,
PHY-MaSP-07-U-O, PHY-Cus-12-U-O, PHY-MaSP-08-I-O,
PHY-MaSP-09-U-O, PHY-Ope-02-I-O, PHY-MaSP-10-I-O,
PHY-MaSTP-11-I-O
Requirement No.
C-i-0039-1
Address
Smart meter and server
Position of requirements
Plane: Control, Management
Requirement
The followings are recommended to support smart metering:
- 79 Smart-O-32Rev.6

Support of storage of most recent readings in the smart meter
memory;

Support of provision of periodic meter reading information on
request by authorized market participant(s);

Support of remote meter management (meter status,
activation/de-activation capability, error messaging, fraud
detection);

Support of remote changes of tariff;

Support of a pay-as-you-go or prepayment facility (capable of
being introduced/activated remotely).

Support of detailed metering of electrical energy consumed by
each HAN device and the home total. (Reference: Use Case AMI HAN device power metering service)

Support to receive, store and process the tariff schedule.
(Reference: Use Case AMI1)

Support to communicate with HAN directly or through smart
metering infrastructure, such as energy management companies, to
facilitate to monitor and control the customer equipments located at
the customer’s premise. (Reference: Use Case AMI4 & Use Case
DR- Energy management service)

Support of mutual authentication and authorization with the
operation center and the service provider.

Support a secure environment for the storage, process and
transmission of customer confidential data and other sensitive data.
These sensitive data is required to be unknowable to unauthorized
external entities. (Partly from Use Case AMI4)

Support accurate and secure time synchronization.

Support secure lightweight connectivity for IP or non-IP smart
meter.

Support non-repudiation of service, data integrity, and antitamper.
Type of requirement
May Optionally
Background
Smart grid is included in an application of smart metering.
Reference
ITU-T F.USN-SM, “Requirements and capabilities of ubiquitous sensor
networks for smart metering applications and services”
NIST Special Publication 1108, “NIST Framework and Roadmap for
Smart Grid Interoperability Standards, Release 1.0”
Gap analysis
ITU-T has started to develop a draft recommendation for smart
metering.
- 80 Smart-O-32Rev.6
Bibliography
[b-ITU-T F.USN-SM] ITU-T F.USN-SM (2011), Requirement and capabilities of ubiquitous sensor
networks for smart metering applications and services.
[b-ITU-T G.1000] ITU-T G.1000 (2001), Communications Quality of Service: A framework and
definitions
[b-ITU-T G.9960] ITU-T Recommendation G.9960 (2010) Unified high-speed wire-line based
home networking transceivers - System architecture and physical layer
specification
[b-ITU-T Y.2001] ITU-T Y.2001 (2004), General overview of NGN
[b-ITU-T Y.2011] ITU-T Y.2011 (2004), General principles and general reference model for Next
Generation Networks
[b-ITU-T Y.2291] ITU-T Y.2291 (ngn_hn) (2011), Architectural overview of next generation
home networks
[b-ITU-T Y.2281] ITU-T Y.2281 (Y.NGN-vehicle) (2011). Framework of networked vehicle
services and applications using NGN
[b-ITU-R M.687] ITU-R M.687 (1997), International Mobile Telecommunications-2000 (IMT2000)
[b-ITU-R M.816] ITU-R M.816 (1997), Framework for services supported on International
MobileTelecommunications-2000 (IMT-2000)
[b-ITU-R M.817] ITU-R M.817 (1992), International Mobile Telecommunications-2000 (IMT2000). Network architectures
[b-ITU-R M.819] ITU-R M.819 (1997), International Mobile Telecommunications-2000 (IMT2000) for developing countries
[b-ITU-R M.1034] ITU-R M.1034 (1997), Requirements for the radio interface(s) for International
Mobile Telecommunications-2000 (IMT-2000)
[b-ITU-R M.1035] ITU-R M.1035 (1994), Framework for the radio interface(s) and radio sub
system functionality for International Mobile Telecommunications-2000 (IMT2000)
[b-ITU-R M.1036] ITU-R M.1036 (2007), Frequency arrangements for implementation of the
terrestrial component of International Mobile Telecommunications-2000 (IMT
2000) in the bands 806-960 MHz, 1710-2025 MHz, 2110-2200 MHz and 25002690 MHz
[b-ITU-R M.1078] ITU-R M.1078 (1994), Security principles
Telecommunications-2000 (IMT-2000)
for
International
Mobile
[b-ITU-R M.1079] ITU-R M.1079 (2003), Performance and quality of service requirements for
International Mobile Telecommunications-2000 (IMT-2000) access networks
[b-ITU-R M.1168] ITU-R
M.1168
(1995),
Framework
Telecommunications-2000 (IMT-2000)
of
International
Mobile
- 81 Smart-O-32Rev.6
[b-ITU-R M.1645] ITU-R M.1645 (2003), Framework and overall objectives of the future
development of IMT-2000 and systems beyond IMT-2000
[b-1]
IEC 61850 (2011), Communication networks and systems in substations
[b-2]
Bluetooth Technology Overview For Smart Meters and Home Area Networks (2010)
[b-3]
3GPP TS 22.228 (2011), Service requirements for the Internet Protocol (IP) multimedia
core network subsystem (IMS), www.3gpp.org
[b-4]
3GPP TS 23.228 (2011), IP Multimedia Subsystem (IMS), www.3gpp.org
[b-5]
3GPP TS 24.229 (2011), IP multimedia call control protocol based on Session Initiation
Protocol (SIP) and Session Description Protocol (SDP); Stage 3, www.3gpp.org
[b-6]
3GPP TS 23.888, System improvements for Machine-Type Communications (MTC),
www.3gpp.org
[b-7]
3GPP TS 23.060 (2011), General Packet Radio Service (GPRS); Service description; Stage
2, www.3gpp.org
[b-8]
3GPP TS 29.060 (2011), General Packet Radio Service (GPRS); GPRS Tunnelling
Protocol (GTP) across the Gn and Gp interface, www.3gpp.org
[b-9]
3GPP TS 22.368 (2011), Service requirements for Machine-Type Communications (MTC);
Stage 1, www.3gpp.org
[b-10] ETSI TR 102 691 V1.1.1 (2010), Machine-to-Machine communications (M2M); Smart
Metering Use Cases
[b-11] 3GPP TR 33.812 (2009), Feasibility study on the security aspects of remote provisioning
and change of subscription for Machine to Machine (M2M) equipment, www.3gpp.org
[b-12] draft Smart Energy Profile 2.0 Public
http://zigbee.org/Standards/Downloads.aspx
Application
Protocol
Specification,
[b-13] NIST Priority Action Plan 2 (PAP2) (2011), Guidelines for Assessing Wireless Standards
for Smart Grid
[b-14] ETSI TS 102 689 V1.1.1 (2010), Machine-to-Machine communications (M2M); M2M
service requirements