ETSI GS F5G 011 V1.1.1 (2022-11)

Fifth Generation Fixed Network (F5G); Telemetry Framework and Requirements for Access Networks

DGS/F5G-0011Telemetry

General Information

• Status: Not Published
• Technical Committee: F5G - Fifth Generation Fixed Network
• Current Stage: 12 - Completion
• Due Date: 13-Dec-2022
• Completion Date: 25-Nov-2022

Standards Content (Sample)

GROUP SPECIFICATION
Fifth Generation Fixed Network (F5G);
Telemetry Framework and Requirements for Access Networks
Disclaimer
The present document has been produced and approved by the Fifth Generation Fixed Network (F5G) ETSI Industry
Specification Group (ISG) and represents the views of those members who participated in this ISG.
It does not necessarily represent the views of the entire ETSI membership.

2 ETSI GS F5G 011 V1.1.1 (2022-11)

Reference
DGS/F5G-0011Telemetry
Keywords
F5G; telemetry; YANG
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure Program:
https://www.etsi.org/standards/coordinated-vulnerability-disclosure
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
and/or governmental
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2022.
All rights reserved.
ETSI
3 ETSI GS F5G 011 V1.1.1 (2022-11)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definition of terms, symbols and abbreviations . 6
3.1 Terms . 6
3.2 Symbols . 7
3.3 Abbreviations . 8
4 Framework of Telemetry in Access Network . 9
4.1 Motivation and Business Drivers . 9
4.2 Telemetry Architecture Overview . 9
5 Technical Solutions . 10
5.1 UDP Streaming Telemetry Mode . 10 ®
5.2 gRPC Static Telemetry Mode . 11 ®
5.3 gRPC Dynamic Telemetry Mode . 12
6 Interface Requirements. 13
6.1 Overview . 13 ®
6.2 gRPC Layer Requirements . 13 ®
6.2.1 gRPC Static Telemetry mode . 13 ®
6.2.2 gRPC Dynamic Telemetry mode . 13
6.3 Telemetry Layer Requirements . 14
6.4 Collection Data Layer Requirements . 14
7 Telemetry Functional Requirements . 15
7.1 Overview . 15
7.2 Telemetry System . 15
7.3 OLT . 16
7.3.1 OLT Internal Functions . 16
7.3.2 Collection Capabilities Exchange Process . 17
7.3.3 OLT Performance Requirements . 18
8 Collection Parameters. 19
8.1 Overviews and Definitions . 19
8.2 Access Network Traffic Information Collection . 19
8.2.1 Overviews and Definitions . 19
8.2.2 Table of Access Network Traffic Information Collection . 22
8.3 Optical Link Information Collection . 23
8.3.1 Overviews and Definitions . 23
8.3.2 Table of Optical Link Information Collection . 24
8.4 ONU Information Collection . 24
8.4.1 Overviews and Definitions . 24
8.4.2 Table of GPON ONU Collection . 26
8.4.3 Table of EPON ONU Collection . 27
Annex A (informative): Examples of Telemetry Technical Solutions . 28
A.1 UDP Streaming Telemetry Mode use case . 28 ®
A.2 gRPC Static Telemetry Mode use case . 28 ®
A.3 gRPC Dynamic Telemetry Mode use case . 29
ETSI
4 ETSI GS F5G 011 V1.1.1 (2022-11)
Annex B (informative): Example Implementation of the Telemetry system . 30
B.1 Introduction . 30
B.2 Control Module . 30
B.3 Collector/Detector Module . 31
B.4 Data Lake . 32
B.4.1 Overview . 32
B.4.2 Telemetry Broker . 33
B.4.3 Telemetry Consumer . 34
B.4.4 Time Series Data Base . 34
B.5 Analytic Module . 35
B.5.1 Overview . 35
B.5.2 ML Inference Host . 35
B.5.3 Visualization Dashboard . 36
Annex C (informative): Feasible Implementation of an Extension of the Telemetry Collection
Encoding . 37
C.1 Introduction . 37
C.2 Implementation Details . 37
Annex D (informative): Change History . 39
History . 40

ETSI
5 ETSI GS F5G 011 V1.1.1 (2022-11)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are publicly available for ETSI members and non-members, and can be
found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to
ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the
ETSI Web server (https://ipr.etsi.org/).
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become,
essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its

Members. 3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and of the 3GPP
Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of the ®
oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association.
Foreword
This Group Specification (GS) has been produced by ETSI Industry Specification Group (ISG) Fifth Generation Fixed
Network (F5G).
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.

ETSI
6 ETSI GS F5G 011 V1.1.1 (2022-11)
1 Scope
The present document defines the F5G Telemetry Framework and Requirements for the F5G Access Network. The
framework specifies the key functions and interfaces. The F5G Access Network telemetry requirements include
requirements for the functions, the overall system, and the interfaces with their data models (configuration and
streaming/collection).
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
[1] ETSI GS F5G 004 (V1.1.1): "Fifth Generation Fixed Network (F5G); F5G Network Architecture".
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
TM
[i.1] IEEE 802.3 -2008: "IEEE Standard for information technology".
[i.2] Recommendation ITU-T G.988: "ONU management and control interface (OMCI) specification". ®
[i.3] Google Developers | Protocol Buffers | Encoding.
NOTE: Available at https://developers.google.com/protocol-buffers/docs/encoding.
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in ETSI GS F5G 004 [1] and the following apply:
Access Network Telemetry (ANT): monitoring technology that remotely collects data in push mode from the OLT
alignment error packet: packet with bad FCS and with a non-integral number of octets
NOTE: The definition of this term comes from IEEE 802.3 [i.1].
ETSI
7 ETSI GS F5G 011 V1.1.1 (2022-11)
ANT object: specific physical or logical entity in the OLT or ONU (e.g. a PON port, a service flow, etc.)
equipment sampling capability: minimum time interval for the OLT to gather the target telemetry data
NOTE: This time interval can be shorter than the sample interval.
EXAMPLE: The equipment sampling capability is x seconds, and the sample interval is y seconds. (x can be
shorter than y). A single ANT object is created from the equipment sampled data according to the
configuration rules.
error packet: include the following data frames:
• Correct and incorrect data frames with a frame length less than 64 bytes.
• Correct and incorrect data frames whose frame size is greater than the maximum MTU.
• Data frames with FCS errors whose frame length ranges from 64 to the maximum MTU.
• Data frames with alignment errors whose frame length ranges from 64 to the maximum MTU.
NOTE: The definition of this term comes from IEEE 802.3 [i.1].
fragment packet: packets with less than 64 octets in length, excluding framing octets but including FCS octets
NOTE 1: These packets have, and had either a bad FCS with an integral number of octets (FCS error) or a bad FCS
with a non-integral number of octets (alignment error).
NOTE 2: The definition of this term comes from IEEE 802.3 [i.1].
jabber packet: packet that is greater than 1 518 octets in length, excluding framing octets but including FCS octets
NOTE 1: These packets have, and had either a bad FCS with an integral number of octets (FCS error) or a bad FCS
with a non-integral number of octets (alignment error).
NOTE 2: The definition of this term comes from IEEE 802.3 [i.1].
oversized packet: packet with length greater than 1 518 octets
NOTE: The definition of this term comes from IEEE 802.3 [i.1].
sample interval: time interval for the ANT object in the Telemetry message reported by the OLT to the collector
NOTE: This value is configured by the configuration module of the telemetry system.
sample timestamp: timestamp at which the current ANT object was sampled
sensor group: group of multiple sensor paths
sensor path: data model path of the sensor, which describes the specific ANT objects for collection
service flow: service flow is a consequence of traffic classification based on the identifiers in the Ethernet packets on a
physical port or logical port
NOTE 1: For example, an identifier can be a VLAN ID, which means Ethernet packets are classified based on
VLANs.
NOTE 2: A service flow can also be a Layer 2 logical channel that carries services between an access node (OLT)
and a subscriber (ONU).
undersized packet: packet with length less than 64 octets
NOTE: The definition of this term comes from IEEE 802.3 [i.1].
3.2 Symbols
Void.
ETSI
8 ETSI GS F5G 011 V1.1.1 (2022-11)
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
10G-EPON 10 Gbit/s Ethernet Passive Optical Network
AI Artificial Intelligence
ANT Access Network Telemetry
BER Bit Error Ratio
BIP Bearer Independent Protocol
CLI Command-Line Interface
CPU Central Processing Unit
CRC Cyclic Redundancy Check
DG Dying Gasp
DOW Drift Of Window
DPU Data Pre-processing Unit
EPON Ethernet Passive Optical Network
FCS Frame Check Sequence
FEC Forward Error Correction
GEM GPON Encapsulation Mode ®
GNMI gRPC Network Management Interface
® ®
GPB Google Protocol Buffer
GPON Gigabit-Capable Passive Optical Networks
® ®
gRPC Google Remote Procedure Call
HEC Hybrid Error Correction
HTTP Hyper Text Transfer Protocol
ID Identity Document
IP Internet Protocol
IPTV Internet Protocol Television
JSON Java Script Object Notation
LOF Loss Of Frame
LOS Loss Of Signal
LP Line Protocol
MAC Message Authentication Code
MIB Management Information Base
ML Machine Learning
MSB Most Significant Bit
MTU Maximum Transmission Unit
NE Network Entity
NETCONF Network Configuration Protocol
ODN Optical Distribution Network
OLT Optical Line Terminal
ONU Optical Network Unit
P2MP Point to Multipoint
PON Passive Optical Network
RPC Remote Procedure Call
SNI Service Node Interface
SNMP Simple Network Management Protocol
TCONT Transmission - Container
TCP Transmission Control Protocol
TLS Transport Layer Security
TSDB Time Series Database
UDP User Datagram Protocol
UNI User Network Interface
VLAN Virtual Local Area Network
XG 10 GigabitMAC
XG-PON 10-Gigabit-capable Passive Optical Network
XGS-PON 10-Gigabit-capable Symmetric Passive Optical Network
YANG Yet Another Next Generation data modelling language
ETSI
9 ETSI GS F5G 011 V1.1.1 (2022-11)
4 Framework of Telemetry in Access Network
4.1 Motivation and Business Drivers
Figure 1 depicts the current Access Network deployment. A traditional data pulling methods is used, such as SNMP,
syslog and CLI to pull data from the OLT to monitor Access Network and troubleshoot any issues. The interface uses
proprietary MIBs from different OLT equipment vendors which are difficult to automate. So, each request to pull data
is resource intensive and impact the performance of the OLT, and adds complexity because there is more than one pull
request per OLT. The pulling method does not efficiently scale.

Figure 1: Traditional Access Network architecture
As the complexity of the Access Network increases, it is crucial to maintain the network health. To achieve this, the
Access Network can provide better visibility compared to existing methods via automated real-time data collection.
Telemetry replaces the pull method, and uses the push method to continuously stream data from the OLT and provides
notifications to the data collection platform. Telemetry has the advantages of scale, speed and automation. With the
flexibility of telemetry, the data of interest can be selected from the OLT and the OLT can transmit it in a structured
format to a data collection platform for monitoring. In addition, the data collection platform can expose F5G Access
Network information to the application layer.
Telemetry introduces finer granular data points and more frequent data streaming in the Access Network. It enables
better performance monitoring and therefore better control over large Access Network. Telemetry data can assist in the
prediction of network problems and take preventative actions without impacting the performance of the OLT. The
operators can gain better visibility and insight into the network. The operator can enhance the network operational
performance by using data analytics. Telemetry technology opens the door to big data and machine learning methods in
the Access Network.
4.2 Telemetry Architecture Overview
Figure 2 illustrates the F5G Access Network architecture of the telemetry technologies. The Access Network equipment
supports the telemetry collection function, which adopts the active push mode, supports structured data and has higher
execution efficiency and real-time collection accuracy. To meet the needs of refined, visualized, intelligent monitoring
of operation and maintenance, telemetry provides the basis of big data analysis for the rapid locating of network
problems and network quality optimization and adjustment.
In the deployment scenario of Access Network equipment which supports telemetry technology, the telemetry
architecture can be partitioned into the telemetry system and the OLT. The telemetry system is responsible for the
subscription configuration, receiving telemetry collection data reported from the OLT, and data processing, storage and
analysis. The OLT is responsible for reporting telemetry collection data according to the subscription configuration.
ETSI
10 ETSI GS F5G 011 V1.1.1 (2022-11)
Telemetry system
telemetry data streaming
subscribe configuration
ODN
ONU
OLT
SNI UNI
Figure 2: Telemetry architecture in the Access Network
5 Technical Solutions
5.1 UDP Streaming Telemetry Mode
The telemetry system shall support both control and collection features. The control modules should support the
NETCONF protocol to send subscription configuration. The corresponding parameters are described in Clause 6 of the
present document. If UDP streaming telemetry mode is chosen, the OLT equipment should support UDP encapsulated ®
data reporting. The serialization of the data is based on GPB .
If UDP streaming telemetry mode is chosen for the telemetry collection, the OLT shall continuously stream the data to
the several collectors, once the subscriptions are created as part of the configuration of the OLT and it shall remain the
OLT configuration until the subscription is removed. The schematic diagram of UDP streaming telemetry mode is
shown in Figure 3.
Control modules Collector modules
Streaming protocol：UDP
Configuration protocol：NETCONF ®
Encoding：GPB
OLT ®
NOTE: Encoding methods other than GPB are possible.

Figure 3: UDP streaming telemetry mode
The specific protocol stack layer is shown in Table 1.
ETSI
11 ETSI GS F5G 011 V1.1.1 (2022-11)
Table 1: The telemetry stack layer and requirements of UDP telemetry mode
Telemetry Stack Requirements
Collection data layer Carries encoded telemetry collection data.
Defines the data header when telemetry data is sent, including sampling
Data layer
Telemetry layer path, sampling timestamp, etc. The specific parameters are defined in
clause 6.3 of the present document.
Optional support for fragmentation and encoding format indication through
Message header layer
the message header layer.
UDP provides simple information transmission service, but information
UDP transport layer
might be lost. ®
5.2 gRPC Static Telemetry Mode
The telemetry system shall support both control and collection features. The control modules should support the
NETCONF protocol to send subscription configuration. The corresponding parameters are described in clause 6. If ®
gRPC static telemetry mode is chosen, the OLT equipment should support data encapsulation and reporting as a
® ®
gRPC client. The schematic diagram of gRPC static telemetry mode is shown in Figure 4.
Collector modules
Control modules
Configuration protocol：NETCONF ®
Streaming protocol：gRPC ®
Encoding：GPB
OLT ®
NOTE: Encoding methods other than GPB are possible.
®
Figure 4: gRPC Static Telemetry Mode ®
If gRPC static telemetry mode is chosen for the telemetry collection, the OLT shall continually stream the telemetry
data to the several collectors once the subscriptions are created as part of the configuration and it shall remain the OLT
configuration until the configuration is removed. The specific protocol stack layer is shown in Table 2.
ETSI
12 ETSI GS F5G 011 V1.1.1 (2022-11) ®
Table 2: The telemetry stack layer and requirements of gRPC Static Telemetry Mode
Telemetry Stack Requirements
Collection data layer Carries encoded telemetry collection data.
Defines the data header when telemetry data is sent, including sampling
Telemetry layer path, sampling timestamp, etc. The specific parameters are defined in
Data Layer
clause 6.3 of the present document.
Defines the RPC interfaces when the OLT equipment is reporting
RPC layer
telemetry data as a client.
® ®
gRPC layer Defines the gRPC protocol interaction format of remote procedure calls. ®
HTTP 2.0 layer gRPC is carried on the HTTP 2.0 protocol.
Optional. OLT and telemetry system can perform channel encryption and
TLS transport layer mutual authentication based on the TLS protocol to realize secure
transmission.
TCP provides a connection-oriented, reliable information transmission
TCP transport layer
service. ®
NOTE: The UDP Streaming mode is similar to the gRPC static mode.
®
5.3 gRPC Dynamic Telemetry Mode
The telemetry system shall support both subscription and collection features. The telemetry system should support
® ®
creating subscriptions to the OLT as a gRPC client and receiving streaming data. If gRPC dynamic telemetry mode is
® ®
chosen, the OLT equipment should support data encapsulation and reporting as a gRPC server which supports gRPC ®
Network Management Interface (gNMI). The schematic diagram of gRPC static telemetry mode is shown in Figure 5. ®
gRPC client(collector) ®
® Streaming protocol：gRPC
Subscribe protocol：gRPC ®
Encoding：GPB
OLT ®
NOTE: Encoding methods other than GPB are possible.
®
Figure 5: gRPC Dynamic Telemetry Mode ®
If gRPC dynamic telemetry mode is chosen for the telemetry collection, the OLT shall continually stream the
telemetry data to the one certain collector when this collector sends the subscriptions to the OLT. This dynamic
subscription shall terminate when the collector cancels the subscription or when the session terminates. The dynamic
telemetry mode is suitable when the collector exactly knows its telemetry requirements. This mode is convenient as a
centralized way of configuring the network and requesting operational data. The specific protocol stack layer is shown
in Table 3.
ETSI
13 ETSI GS F5G 011 V1.1.1 (2022-11) ®
Table 3: The telemetry stack layer and requirements of gRPC Dynamic Telemetry Mode
Telemetry Stack Requirements
Collection data layer Carries encoded telemetry collection data.
Defines the data header when telemetry data is sent, including sampling
Telemetry layer path, sampling timestamp, etc. The specific parameters are defined in
Data Layer
clause 6.3 of the present document.
Defines the RPC interfaces when the OLT equipment is reporting
RPC layer
telemetry data as a server.
® ®
gRPC layer Defines the gRPC protocol interaction format of remote procedure call. ®
HTTP 2.0 layer gRPC is carried on the HTTP 2.0 protocol.
Optional. OLT and telemetry system can perform channel encryption and
TLS transport layer mutual authentication based on the TLS protocol to realize secure
transmission.
TCP provides a connection-oriented, reliable information transmission
TCP transport layer
service.
6 Interface Requirements
6.1 Overview ®
The gRPC layer, the telemetry layer and the collection data layer play different roles in the telemetry system. The
® ®
gRPC layer shall only exist when the streaming protocol is gRPC . The telemetry layer and the collection data layer
shall always exist in telemetry messages and carries the main contents. ®
Clause 6 of the present document specifies the technical requirements and the key parameters of the gRPC layer, the
telemetry layer and collection data layer. ®
6.2 gRPC Layer Requirements ®
6.2.1 gRPC Static Telemetry mode
® ®
When the streaming protocol is gRPC and it is gRPC Static Telemetry mode, the OLT shall stream collection data ®
through an RPC interface to the telemetry system as a gRPC client according to the telemetry configuration. The
structure of this RPC interface has been defined in this layer.
The RPC structure shall contain the following elements:
• Request ID.
• Streaming telemetry data structure and its elements are defined by the Telemetry layer. The telemetry layer
requirements are defined in clause 6.3. ®
6.2.2 gRPC Dynamic Telemetry mode
® ®
When the streaming protocol is gRPC and it is gRPC Dynamic Telemetry mode, the telemetry system shall send a
subscription request through an RPC interface to the OLT. The structure of this subscribe RPC interface has been
defined in this layer.
The subscribe RPC interface structure shall contain the following elements:
• Request ID.
• Encoding method.
• Data model path of the sensor which describes the specific ANT objects for collection.
• Sample interval.
ETSI
14 ETSI GS F5G 011 V1.1.1 (2022-11)
When the OLT receives the subscription request, it shall stream the collection data through a corresponding RPC reply ®
to the telemetry system as a gRPC server.
The reply of the subscription request via the RPC interface shall contain the following elements:
• Subscription ID.
• Request ID.
• Streaming telemetry data structure and its elements are defined by the Telemetry layer. The telemetry layer
requirements are defined in clause 6.3. ®
When the gRPC dynamic telemetry session needs to be terminated, a cancel subscription request RPC shall be sent by
the telemetry system.
The cancel subscription request via the RPC interface shall contain the following elements:
• Request ID.
• Subscription ID.
When the OLT receives the cancel subscription request, it shall reply the result of the cancel request.
The reply of the cancel subscription request via the RPC interface shall contain the following elements:
• Request ID.
• Response code.
• Error description.
6.3 Telemetry Layer Requirements
® ®
When the streaming protocol is gRPC , the telemetry layer is carried in the gRPC layer. When the streaming protocol
is UDP, the telemetry layer can exist independently in the data layer of the telemetry message. This layer defines the
data header of the telemetry collection data. It shall contain the following elements:
• OLT node ID.
• Subscription ID.
• Data model path of sensor which describes the specific ANT objects for collection.
• Collection ID.
• Collection start time.
• Collection end time.
• Message timestamp.
• Encoding method.
• Current time interval of data sampling.
• Data sampling timestamp.
• The specific collection data structure and its elements are defined by the collection data layer. The collection
data layer requirements are defined in clause 6.4 of the present document.
6.4 Collection Data Layer Requirements
The collection data structure is carried in the telemetry structure. The collection data structure defines the telemetry
collection items of the Access Network. For these specific collection items refer to clause 8 of the present document.
ETSI
15 ETSI GS F5G 011 V1.1.1 (2022-11)
For the actual collected data, the value '0' is meaningful data which shall be reported. If some collection items cannot be
sampled by the OLT due to the inability of the OLT, the specific items should be indicated in the collection data layer.
According to the equipment capabilities and user needs, an "empty" collection item can be indicated in either one of the
following ways:
• If one collection item cannot be sampled by the OLT, it will not be generated in the telemetry message.
• The telemetry message transport mechanism can support the capability to optimize the message when the
collection item is empty and it is able to signal the reason why a particular collection item is not available. In
® ®
the case that the encoding format of the collection data layer is GPB , the GPB encoding may need
extensions for a more efficient telemetry streaming. These extensions compress the telemetry message and are
more explicit explaining why a telemetry collection item cannot be collected. Refer to Annex C for more
details on a feasible implementation.
7 Telemetry Functional Requirements
7.1 Overview
For higher precision network monitoring and the automation of network optimization, the telemetry system and the
OLT shall implement some basic telemetry functions. Clause 7 of the present document specifies the functions required
for the basic telemetry scenarios in the Access Network.
7.2 Telemetry System
The telemetry system is an automated controller for Access Network telemetry. It shall implement telemetry collection
and may have the capability to dynamically configure and generate the telemetry subscriptions. In addition, the
telemetry system can provide a telemetry service interface for other applications using the telemetry data.
The telemetry system consists of six functional components as illustrated in Figure 6 and are described as follows.

Figure 6: Telemetry System
ETSI
16 ETSI GS F5G 011 V1.1.1 (2022-11)
• Telemetry models store: storage for telemetry models of different OLT versions and the storage for defined
metrics for the analytic module such as window size, time lag, sample interval, start time, etc. The collection
interface of the collector/decoder module can be generated based on the models stored in the telemetry model
store. The telemetry models stored in the telemetry model store are used to generate NETCONF interfaces on
the control module. In addition, the telemetry model store can provide configurations of telemetry data
structures for the data lake and define metrics of analytic module for Telemetry data.
• Control module: interfaces to the OLT via a NETCONF client in order to subscribe to different data streams.
It also sets the periodicity and the granularity of streams and other parameters defining the data collection
settings.
• Collector/Decoder module: interfaces to the OLT. It collects the subscribed telemetry data streams, decodes
them based on the collection interface, and populates the data lake.
• Data lake: stores the history of the collected streams. It can provide inputs to the northbound telemetry
services and the analytic module.
• Analytic module: implements the different policies and network rules in order to forecast the network and it
automates some actions for network optimization based on the collected data. It can use some Machine
Learning/Artificial intelligence techniques and generate corresponding ML/AI models to propose different
advanced network services, such as real-time forecasting for future networking. The collected data used by the
analytic module should be verified to be completed, valid and non-redundant for training and analysis
accuracy. It should be able to subscribe to a specific stream or change the settings of the collection parameters
by communicate directly to the control module. Its different services or properties are exposed to the
northbound telemetry services.
• Northbound telemetry services: exposes the different services delivered by the telemetry system to external
systems.
7.3 OLT
7.3.1 OLT Internal Functions
The OLT internal functions are the essential blocks to enabling Access Network telemetry. The internal functional
blocks are:
• Sensor Path: The sensor path describes the specific ANT objects for collection.
• Exclude Filters: Filter to exclude certain values from the collection values.
• Sensor Group: The sensor group represents a reusable grouping of multiple sensor paths and exclusion filters.
• Subscriptions: The subscriptions contain both static subscription and dynamic subscription. A static telemetry
subscription is configured locally on the OLT through the telemetry system, and is permanently saved on the ®
OLT even if the OLT restarts. A dynamic subscription is typically configured through an gRPC channel, and ®
does not persist if the OLT restarts or if the gRPC channel is reset or torn down. A telemetry subscription
consists of a set of collector addresses, sensor groups and exclusion filters. ®
• Encoding: Data which is streamed by the OLT may be encoded into GPB encoding format.
• Transport protocol: The OLT can stream telemetry data through one of the following supported transport
protocols: ®
- gRPC .
- UDP.
• UDP Streaming Initiation: The telemetry system cannot start the UDP streaming initiation. The OLT can
continuously stream the telemetry data through UDP.
ETSI
17 ETSI GS F5G 011 V1.1.1 (2022-11) ®
• gRPC Session Initiation: There are two options for who initiates the streaming data as described in clause 5:
- Option one is that the telemetry system initiates a session with the OLT and subscribes to collection data ®
to be streamed by a gRPC channel. ®
- Option two is that the OLT initiates the sessions by several gRPC channels to more than one collector
based on the subscription.
• Collection Capabilities Exchange: Items such as different model formats, and optional feature can impact the
collector decoding of the telemetry data. The OLT should support sending explicit telemetry collection items
which are modelled by the model file to the collector.
7.3.2 Collection Capabilities Exchange Process
The collection capabilities exchange process between the OLT and the telemetry system (collector) is shown in
Figure 7.
The telemetry collection data shall be defined by the telemetry data models. Before the telemetry subscription is sent to
the OLT, the telemetry system sends a model request to the OLT and the OLT should report the telemetry data models
to the collector in the telemetry system. It is assumed that the connectivity between the OLT and the telemetry system
including L3 is stable. The collector compares the local telemetry data models with models reported by the OLT. In
case of a mismatch, various options are possible including the telemetry system updates the local telemetry data models
...