ETSI GS MEC 029 V2.1.1 (2019-07)

Multi-access Edge Computing (MEC); Fixed Access Information API

DGS/MEC-0029FixedAPI

General Information

• Status: Published
• Publication Date: 16-Jul-2019
• Technical Committee: MEC - Multi-access Edge Computing
• Current Stage: 12 - Completion
• Due Date: 05-Jul-2019
• Completion Date: 17-Jul-2019

Standards Content (Sample)

GROUP SPECIFICATION
Multi-access Edge Computing (MEC);
Fixed Access Information API
Disclaimer
The present document has been produced and approved by the Multi-access Edge Computing (MEC) 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 MEC 029 V2.1.1 (2019-07)

Reference
DGS/MEC-0029FixedAPI
Keywords
API, MEC, service
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

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
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 2019.
All rights reserved.
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.
ETSI
3 ETSI GS MEC 029 V2.1.1 (2019-07)
Contents
Intellectual Property Rights . 6
Foreword . 6
Modal verbs terminology . 6
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 7
3 Definition of terms, symbols and abbreviations . 8
3.1 Terms . 8
3.2 Symbols . 8
3.3 Abbreviations . 8
4 Overview . 9
5 Description of the features (informative) . 10
5.1 FAI service introduction . 10
5.2 Sequence diagrams . 10
5.2.1 Introduction. 10
5.2.2 Sending a request for the available FAI . 10
5.2.3 Sending a request for the device information . 11
5.2.4 Sending a request for cable line information . 11
5.2.5 Sending a request for optical network information . 11
5.2.6 REST based subscribe-notify model . 12
5.2.6.1 Subscribing to event notifications . 12
5.2.6.2 Receiving notification on expiry of FAI event subscription . 13
5.2.6.3 Updating subscription for FAI event notifications . 13
5.2.6.4 Unsubscribing from FAI event notifications . 14
5.2.7 Receiving FAI event notifications about the ONU alarms . 14
5.2.8 Receiving FAI event notifications about the device information. 15
5.2.9 Receiving FAI event notifications about the cable modem connectivity state . 16
5.2.10 Receiving FAI event notifications about the ANI alarms . 16
6 Data model . 17
6.1 Introduction . 17
6.2 Resource data types . 17
6.2.1 Introduction. 17
6.2.2 Type: FaInfo . 17
6.2.3 Type: DeviceInfo . 18
6.2.4 Type: CableLineInfo . 19
6.2.5 Type: PonInfo . 20
6.3 Subscription data types . 21
6.3.1 Introduction. 21
6.3.2 Type: OnuAlarmSubscription . 21
6.3.3 Type: DevInfoSubscription . 23
6.3.4 Type: CmConnSubscription . 23
6.3.5 Type: SubscriptionLinkList . 24
6.3.6 Type: AniAlarmSubscription . 25
6.4 Notification data types . 26
6.4.1 Introduction. 26
6.4.2 Type: OnuAlarmNotification . 26
6.4.3 Type: DevInfoNotification . 26
6.4.4 Type: CmConnNotification . 27
6.4.5 Type: ExpiryNotification . 27
6.4.6 Type: AniAlarmNotification . 27
6.5 Referenced structured data types . 28
6.5.1 Introduction. 28
ETSI
4 ETSI GS MEC 029 V2.1.1 (2019-07)
7 API definitions . 31
7.1 Introduction . 31
7.2 Global definitions and resource structure . 31
7.3 Resource: Resource: fa_info. 33
7.3.1 Description . 33
7.3.2 Resource definition . 33
7.3.3 Resource methods . 33
7.3.3.1 GET . 33
7.3.3.2 PUT . 34
7.3.3.3 PATCH . 34
7.3.3.4 POST . 34
7.3.3.5 DELETE . 34
7.4 Resource: device_info . 35
7.4.1 Description . 35
7.4.2 Resource definition . 35
7.4.3 Resource methods . 35
7.4.3.1 GET . 35
7.4.3.2 PUT . 36
7.4.3.3 PATCH . 36
7.4.3.4 POST . 36
7.4.3.5 DELETE . 36
7.5 Resource: cable_line_info . 36
7.5.1 Description . 36
7.5.2 Resource definition . 36
7.5.3 Resource methods . 37
7.5.3.1 GET . 37
7.5.3.2 PUT . 38
7.5.3.3 PATCH . 38
7.5.3.4 POST . 38
7.5.3.5 DELETE . 38
7.6 Resource: optical_network_info . 38
7.6.1 Description . 38
7.6.2 Resource definition . 38
7.6.3 Resource methods . 38
7.6.3.1 GET . 38
7.6.3.2 PUT . 39
7.6.3.3 PATCH . 39
7.6.3.4 POST . 39
7.6.3.5 DELETE . 39
7.7 Resource: subscriptions . 40
7.7.1 Description . 40
7.7.2 Resource definition . 40
7.7.3 Resource methods . 40
7.7.3.1 GET . 40
7.7.3.2 PUT . 41
7.7.3.3 PATCH . 41
7.7.3.4 POST . 41
7.7.3.5 DELETE . 43
7.8 Resource: existing subscription . 43
7.8.1 Description . 43
7.8.2 Resource definition . 43
7.8.3 Resource methods . 43
7.8.3.1 GET . 43
7.8.3.2 PUT . 44
7.8.3.3 PATCH . 46
7.8.3.4 POST . 46
7.8.3.5 DELETE . 46
Annex A (informative): Mapping of permissions for RESTful API and topic based alternative
transport . 48
A.1 Overview . 48
ETSI
5 ETSI GS MEC 029 V2.1.1 (2019-07)
A.2 Mapping of permissions - RESTful and topic based alternative transport . 48
Annex B (informative): Complementary material for API utilization . 49
History . 50

ETSI
6 ETSI GS MEC 029 V2.1.1 (2019-07)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is 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 IPR Policy, no investigation, 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.
Foreword
This Group Specification (GS) has been produced by ETSI Industry Specification Group (ISG) Multi-access Edge
Computing (MEC).
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
7 ETSI GS MEC 029 V2.1.1 (2019-07)
1 Scope
The present document describes a MEC service on Fixed Access Information for Fibre (e.g. G-PON, XG-PON,
NG-PON2, XGS-PON), Cable (DOCSIS 3.1), xDSL, and Point-to-Point Fibre Ethernet access networks. It describes
the information flows, required information, and as applicable, specifies the necessary operations, data model and data
format.
The present document also specifies the RESTful API.
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
http://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 MEC 001: "Multi-access Edge Computing (MEC); Terminology".
[2] ETSI GS MEC 002: "Multi-access Edge Computing (MEC); Phase 2: Use Cases and
Requirements".
[3] IETF RFC 6749: "The OAuth 2.0 Authorization Framework".
NOTE: Available at https://tools.ietf.org/html/rfc6749.
[4] IETF RFC 6750: "The OAuth 2.0 Authorization Framework: Bearer Token Usage".
NOTE: Available at https://tools.ietf.org/html/rfc6750.
[5] IETF RFC 5246: "The Transport Layer Security (TLS) Protocol Version 1.2".
NOTE: Available at https://tools.ietf.org/html/rfc5246.
[6] IETF RFC 2818: "HTTP Over TLS".
NOTE: Available at https://tools.ietf.org/html/rfc2818.
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.
[i.1] ETSI GS MEC 009: "Multi-access Edge Computing (MEC); General principles for MEC Service
APIs".
ETSI
8 ETSI GS MEC 029 V2.1.1 (2019-07)
[i.2] ETSI GS MEC 011: "Multi-access Edge Computing (MEC); Edge Platform Application
Enablement".
[i.3] ETSI GS MEC 012: "Multi-access Edge Computing (MEC); Radio Network Information API".
[i.4] ETSI GS MEC 028: "Multi-access Edge Computing (MEC); WLAN Information API".
[i.5] Broadband Forum TR-106: "Data Model Template for TR-069-Enabled Devices".
[i.6] DOCSIS 3.0, Operations Support System Interface Specification, CM-SP-OSSIv3.0-C01-171207,
December 7, 2017, Cable Television Laboratories, Inc.
[i.7] Recommendation ITU-T G.988 (11/2017): "ONU management and control interface (OMCI)
specification".
[i.8] Recommendation ITU-T G.989.3 (10/2015): "40-Gigabit-capable passive optical networks (NG-
PON2): Transmission convergence layer specification".
[i.9] Recommendation ITU-T G.984.3 (01/2014): "Gigabit-capable passive optical networks (G-PON):
Transmission convergence layer specification".
[i.10] Recommendation ITU-T G.987.3 (01/2014): "10-Gigabit-capable passive optical networks (XG-
PON): Transmission convergence (TC) layer specification".
[i.11] Recommendation ITU-T G.9807.1 (06/2016): "10-Gigabit-capable symmetric passive optical
network (XGS-PON)".
[i.12] OpenAPI Specification.
NOTE: Available at https://github.com/OAI/OpenAPI-Specification.
[i.13] Protocol Buffers Language Specification.
NOTE 1: Available at https://developers.google.com/protocol-buffers/.
NOTE 2: Protocol Buffers Version 3 Language Specification is recommended as it is the official release at the time
of publication.
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in ETSI GS MEC 001 [1] apply.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI GS MEC 001 [1] and the following apply:
AC Alternating Current
ACK Acknowledgement
ADSL Asymmetric Digital Subscriber Line
ANI Access Node Interface
API Application Programming Interface
AQM Active Queue Management
ASCII American Standard Code for Information Interchange
BPI Baseline Privacy Interface
ETSI
9 ETSI GS MEC 029 V2.1.1 (2019-07)
CM Cable Modem
CMTS Cable Modem Termination System
DLS Digital Subscriber Line
DOCSIS Data Over Cable Service Interface Specification
EAE Early Authentication and Encryption
FA Fixed Access
FAI Fixed Access Information
FAIS Fixed Access Information Service
FTP File Transfer Protocol
GFAST G.fast (G stands for the ITU-T G series of recommendations)
GPON Gigabit Passive Optical Network
HTTP Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocol Secure
IETF Internet Engineering Task Force
IP Internet Protocol
JSON JavaScript Object Notation
MAC Media Access Control
NGPON Next Generation Passive Optical Network
ONU Optical Network Unit
OSS Operations Support System
PD Powered Device
PoE Power over Ethernet
PON Passive Optical Network
RFC Request for Comments
SID Service Identifier
TLS Transport Layer Security
UGS Unsolicited Grant Service
URI Universal Resource Identifier
UTC Universal Time Coordinated
VDSL Very-high-bit-rate Digital Subscriber Line
WLAN Wireless Local Area Network
xDSL x Digital Subscriber Line (of any type)
XGPON x Generation Passive Optical Network (also known as 10G-PON)
XG-PON x Generation-Passive Optical Network
XGSPON x Generation Symmetric Passive Optical Network
4 Overview
The present document specifies a Fixed Access Information (FAI) API to support the requirements defined for Multi-
access Edge Computing in ETSI GS MEC 002 [2].
Clause 5 introduces how the Fixed Access Information Service (FAIS) supporting G-PON, XG-PON1, NG-PON2,
XGS-PON and DOCSIS 3.1 may be used by the MEC applications and by the MEC platform. It describes information
flows used for each.
The information that can be exchanged over the API is described in clause 6 which provides a detailed description of all
the information elements that are used for each Fixed Access Network and how they are mapped into the REST
operations.
Clause 7 describes the actual API, providing detailed information how information elements from each Fixed Access
Network are mapped into the RESTful API design.
ETSI
10 ETSI GS MEC 029 V2.1.1 (2019-07)
5 Description of the features (informative)
5.1 FAI service introduction
Multi-access Edge Computing allows running the MEC applications at the edge of the network where the environment
is characterized by low latency, proximity to the end users, high bandwidth and exposure to location and up-to-date
information from the underlying access networks. The information on current conditions from the fixed access is shared
via FAIS.
FAIS is a service that provides the fixed access related information to service consumers within a MEC System. The
FAIS is available for the authorized MEC applications and is discovered over the Mp1 reference point [i.2].
The FAI may be used by the MEC applications and the MEC platform to optimize the existing services and to provide
new type of services that are based on up to date information from the fixed access possibly combined with the
information such as Radio Network Information [i.3] or WLAN Information [i.4] from the other access technologies.
The following clauses describe how the service consumers interact with the FAIS over the FAI API to obtain contextual
information from the fixed access network. The relevant sequence diagrams are presented.
5.2 Sequence diagrams
5.2.1 Introduction
The service consumers communicate with FAIS over the FAI API to get contextual information from the fixed access
network. Both the MEC applications and the MEC platform may consume the FAIS; and both the MEC platform and
the MEC applications may be the providers of the FAI.
The FAI API supports both queries and subscriptions (pub/sub mechanism) that are used over the RESTful API or over
alternative transports such as message bus. Alternative transports are not specified in detail in the present document. For
RESTful architectural style, the present document defines the HTTP protocol bindings.
5.2.2 Sending a request for the available FAI
Figure 5.2.2-1 shows a scenario where the service consumer (e.g. a MEC application or a MEC platform) sends a
request to receive the available FAI that are relevant to the requested MEC application instance or the MEC platform.
The response contains information of the available fixed access (e.g. Fibre (PON, XG-PON, NG-PON), Cable
(DOCSIS 3.1), xDSL and Point-to-Point Fibre Ethernet access).

Figure 5.2.2-1: Flow of service consumer requesting the available FAI
A service consumer requesting the available FAI, as illustrated in figure 5.2.2-1, consists of the following steps:
1) Service consumer sends a GET request to the resource representing the available FAI.
2) FAIS responds with "200 OK" with the message body containing the FaInfo.
ETSI
11 ETSI GS MEC 029 V2.1.1 (2019-07)
5.2.3 Sending a request for the device information
Figure 5.2.3-1 shows a scenario where the service consumer (e.g. a MEC application or a MEC platform) sends a
request to receive the information of one or more devices connected to a fixed access network. The response contains
information of the device(s).
Figure 5.2.3-1: Flow of service consumer requesting the device information
A service consumer requesting the device information, as illustrated in figure 5.2.3-1, consists of the following steps:
1) Service consumer sends a GET request to the resource representing the device information.
2) FAIS responds with "200 OK" with the message body containing the DeviceInfo.
5.2.4 Sending a request for cable line information
Figure 5.2.4-1 shows a scenario where the service consumer (e.g. a MEC application or a MEC platform) sends a
request to receive the information of the available cable line of a fixed access network. The response contains
information of the line(s).
Figure 5.2.4-1: Flow of service consumer requesting the cable line information
A service consumer requesting the line information, as illustrated in figure 5.2.4-1, consists of the following steps:
1) Service consumer sends a GET request to the resource representing the line information.
2) FAIS responds with "200 OK" with the message body containing the LineInfo.
5.2.5 Sending a request for optical network information
Figure 5.2.5-1 shows a scenario where the service consumer (e.g. a MEC application or a MEC platform) sends a
request to receive the information of the available information of an optical network (e.g. G-PON, XG-PON, NG-
PON2, XGS-PON). The response contains information of the optical network.
ETSI
12 ETSI GS MEC 029 V2.1.1 (2019-07)

Figure 5.2.5-1: Flow of service consumer requesting the fibre line information
A service consumer requesting the line information, as illustrated in figure 5.2.5-1, consists of the following steps:
1) Service consumer sends a GET request to the resource representing the optical network information.
2) FAIS responds with "200 OK" with the message body containing the PonInfo.
5.2.6 REST based subscribe-notify model
5.2.6.1 Subscribing to event notifications
To receive notifications on selected FAI events, the service consumer creates a subscription to certain specific FAI
event that is available at FAIS. Figure 5.2.6.1-1 shows a scenario where the service consumer uses REST based
procedures to create a subscription for FAI event notifications.

Figure 5.2.6.1-1: Flow of subscribing to the FAI event notifications
Subscribing to the FAI event notifications, as illustrated in figure 5.2.6.1-1, consists of the following steps.
When the service consumer wants to receive notifications about the FAI events, it creates a subscription to the FAI
event notifications:
1) The service consumer sends a POST request with the message body containing the {NotificationSubscription}
data structure to the resource representing FAI subscription. The variable {NotificationSubscription} is
replaced with the data type specified for different FAI event subscriptions, and it defines the subscribed event,
the filtering criteria and the address where the service consumer wishes to receive the FAI event notifications.
2) FAIS sends "201 Created" response with the message body containing the data structure specific to that FAI
event subscription. The data structure contains the address of the resource created and the subscribed FAI
event type. The address of the resource created is also contained in the message header.
ETSI
13 ETSI GS MEC 029 V2.1.1 (2019-07)
5.2.6.2 Receiving notification on expiry of FAI event subscription
FAIS may define an expiry time for the FAI event subscription. In case expiry time is used, the time will be included in
the {NotificationSubscription} data structure that is included in the response message to the subscription. Prior to the
expiry, FAIS will also send a notification to the service consumer that owns the subscription.
Figure 5.2.6.2-1 shows a scenario where the service consumer receives a subscription expiry notification for the existing
subscription.
Figure 5.2.6.2-1: Flow of FAIS sending a notification on expiry of the subscription
Sending a notification on expiry of the subscription, as illustrated in figure 5.2.6.2-1 consists of the following steps. If
FAIS has defined an expiry time for the subscription, FAIS will send a notification prior to the expiry:
1) FAIS sends a POST request to the callback reference address included by the service consumer in the
subscription request. The POST request contains a data structure ExpiryNotification.
2) Service consumer sends a "204 No Content" response.
5.2.6.3 Updating subscription for FAI event notifications
Figure 5.2.6.3-1 shows a scenario where the service consumer needs to update an existing subscription for a FAI event
notification. The subscription update is triggered e.g. by the need to change the existing subscription, or due to the
expiry of the subscription.
Figure 5.2.6.3-1: Flow of service consumer updating subscription for FAI event notifications
ETSI
14 ETSI GS MEC 029 V2.1.1 (2019-07)
Updating subscription for FAI event notifications, as illustrated in figure 5.2.6.3-1, consists of the following steps.
When the service consumer needs to modify an existing subscription for FAI event notifications, it can update the
corresponding subscription as follows:
1) Service consumer updates the subscription resource by sending a PUT request to the resource representing the
FAI event subscription that was created with the modified data structure specific to that FAI event
subscription.
2) FAIS returns "200 OK" with the message body containing the accepted data structure specific to that FAI
event subscription.
5.2.6.4 Unsubscribing from FAI event notifications
When the service consumer does not want to receive notifications anymore after subscribing to FAI events, the service
consumer unsubscribes from the FAI event notifications. Figure 5.2.6.4-1 shows a scenario where the service consumer
uses REST based procedures to delete the subscription for FAI event notifications.

Figure 5.2.6.4-1: Flow of unsubscribing from the FAI event notifications
Unsubscribing from the FAI event notifications, as illustrated in figure 5.2.6.4-1, consists of the following steps:
When the service consumer does not want to receive the notifications anymore, it can unsubscribe from the FAI
notification events by deleting the subscription:
1) Service consumer sends a DELETE request to the resource representing the FAI event subscription that was
created.
2) FAIS sends "204 No content" response.
5.2.7 Receiving FAI event notifications about the ONU alarms
Figure 5.2.7-1 presents the scenario where the FAIS sends FAI event notification on the ONU alarms to the service
consumer.
ETSI
15 ETSI GS MEC 029 V2.1.1 (2019-07)

Figure 5.2.7-1: Flow of receiving FAI event notifications on the ONU alarms
Receiving FAI event notifications on ONU alarms, as illustrated in figure 5.2.7-1, consists of the following steps:
1) FAIS sends a POST request with the message body containing the OnuAlarmNotification data structure to the
callback reference address included by the service consumer in the FAI ONU alarm event subscription.
2) Service consumer sends a "204 No Content" response to the FAIS.
5.2.8 Receiving FAI event notifications about the device information
Figure 5.2.8-1 presents the scenario where the FAIS sends FAI event notification on the abnormal operational status of
the device to the service consumer.

Figure 5.2.8-1: Flow of receiving FAI event notifications on the device information
Receiving FAI event notifications on device information, as illustrated in figure 5.2.8-1, consists of the following steps:
1) FAIS sends a POST request with the message body containing the DevInfoNotification data structure to the
callback reference address included by the service consumer in the FAI device information event subscription.
2) Service consumer sends a "204 No Content" response to the FAIS.
ETSI
16 ETSI GS MEC 029 V2.1.1 (2019-07)
5.2.9 Receiving FAI event notifications about the cable modem
connectivity state
Figure 5.2.9-1 presents the scenario where the FAIS sends FAI event notification on the cable modem connectivity state
to the service consumer.
Figure 5.2.9-1: Flow of receiving FAI event notifications on the cable modem connectivity state
Receiving FAI event notifications on device information, as illustrated in figure 5.2.9-1, consists of the following steps:
1) FAIS sends a POST request with the message body containing the CmConnNotification data structure to the
callback reference address included by the service consumer in the FAI cable modem connectivity state event
subscription.
2) Service consumer sends a "204 No Content" response to the FAIS.
5.2.10 Receiving FAI event notifications about the ANI alarms
Figure 5.2.10-1 presents the scenario where the FAIS sends FAI event notification on the ANI alarms to the service
consumer.
Figure 5.2.10-1: Flow of receiving FAI event notifications on the ANI alarms
Receiving FAI event notifications on ANI alarms, as illustrated in figure 5.2.10-1, consists of the following steps:
1) FAIS sends a POST request with the message body containing the AniAlarmNotification data structure to the
callback reference address included by the service consumer in the FAI ANI alarm event subscription.
2) Service consumer sends a "204 No Content" response to the FAIS.
ETSI
17 ETSI GS MEC 029 V2.1.1 (2019-07)
6 Data model
6.1 Introduction
The following clauses provide the description of the data model.
6.2 Resource data types
6.2.1 Introduction
This clause defines data structures that shall be used in the resource representations.
6.2.2 Type: FaInfo
This type represents the FAI.
The attributes of the FaInfo shall follow the notations provided in table 6.2.2-1.
Table 6.2.2-1: Attributes of the FaInfo
Attribute name Data type Cardinality Description
timeStamp TimeStamp 0.1 Time stamp.
customerPremisesInfo CpInfo 1.N The physical location of a
customer site.
connectivityInfo Structure (inlined) 0.N The per connectivity domain FAI
as defined below.
>lastMileTech Enum 1 An informative field identifying the
last mile access technology used.
The valid values are:
1 = ADSL.
2 = VDSL.
3 = GPON.
4 = XGPON.
5 = NGPON2.
6 = XGSPON.
7 = GFAST.
8 = P2PEthernet.
>interfaceType Enum 1 The physical interface used for the
end customer site:
1  =  100BASE-TX.
2  =  1000BASE-TX.
3  =  1000BASE-LX.
4  =  1000BASELX10.
5  =  1000BASEBX10.
6  =  1000BASE-LH.
7  =  1000Base-ZX.
8  =  ADSL-RJ11.
9  =  VDSL-RJ11.
10 =  GPON.
>dsbw Integer 0.1 The bandwidth (in Mbps) from the
network towards the customer site.
>usbw Integer 0.1 The bandwidth (in Mbps) from the
customer site towards the network.
>latency Integer 0.1 Maximum baseline latency (in ms)
between customer site and service
edge node.
ETSI
18 ETSI GS MEC 029 V2.1.1 (2019-07)
6.2.3 Type: DeviceI
...