ETSI GS MEC 012 V1.1.1 (2017-07)

Mobile Edge Computing (MEC); Radio Network Information API

DGS/MEC-0012RnisApi

General Information

• Status: Published
• Publication Date: 02-Jul-2017
• Technical Committee: MEC - Multi-access Edge Computing
• Current Stage: 12 - Completion
• Due Date: 19-Jun-2017
• Completion Date: 03-Jul-2017

Standards Content (Sample)

GROUP SPECIFICATION
Mobile Edge Computing (MEC);
Radio Network Information API
Disclaimer
The present document has been produced and approved by the Mobile 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 012 V1.1.1 (2017-07)

Reference
DGS/MEC-0012RnisApi
Keywords
API, MEC, RNIS
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 only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
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 2017.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M logo is protected for the benefit of its Members
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI GS MEC 012 V1.1.1 (2017-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 Definitions and abbreviations . 8
3.1 Definitions . 8
3.2 Abbreviations . 8
4 Overview . 9
5 Description of the service (informative). 9
5.1 RNIS service introduction . 9
5.2 Sequence diagrams . 10
5.2.1 Introduction. 10
5.2.2 Sending a request for RAB information . 10
5.2.3 Sending a request for PLMN information . 11
5.2.4 Sending a request for S1 bearer information . 11
5.2.5 REST based subscribe-notify model . 12
5.2.5.1 Subscribing to RNI event notifications . 12
5.2.5.2 Receiving notification on expiry of RNI event subscription . 12
5.2.5.3 Updating subscription for RNI event notifications . 13
5.2.5.4 Unsubscribing from RNI event notifications . 14
5.2.6 Receiving RNI event notifications about cell changes. 14
5.2.7 Receiving RNI event notifications about Radio Access Bearer establishment . 15
5.2.8 Receiving RNI event notifications about Radio Access Bearer modification . 16
5.2.9 Receiving RNI event notifications about Radio Access Bearer release . 17
5.2.10 Receiving RNI event notifications about UE measurement reports. 18
5.2.11 Receiving RNI event notifications about UE timing advance . 19
5.2.12 Receiving RNI event notifications about carrier aggregation reconfiguration . 19
5.2.13 Receiving RNI event notifications about S1 bearer . 20
6 Data model . 21
6.1 Introduction . 21
6.2 Resource data types . 21
6.2.1 Introduction. 21
6.2.2 Type: PlmnInfo . 21
6.2.3 Type: RabInfo . 21
6.2.4 Type: S1BearerInfo. 22
6.3 Subscription data types . 23
6.3.1 Introduction. 23
6.3.2 Type: CellChangeSubscription . 23
6.3.3 Type: RabEstSubscription . 24
6.3.4 Type: RabModSubscription . 25
6.3.5 Type: RabRelSubscription . 25
6.3.6 Type: MeasRepUeSubscription . 26
6.3.7 Type: MeasTaSubscription . 27
6.3.8 Type: CaReconfSubscription . 27
6.3.9 Type: S1BearerSubscription . 28
6.3.10 Type: SubscriptionLinkList . 28
6.4 Notification data types . 29
6.4.1 Introduction. 29
6.4.2 Type: CellChangeNotification . 29
6.4.3 Type: RabEstNotification . 29
ETSI
4 ETSI GS MEC 012 V1.1.1 (2017-07)
6.4.4 Type: RabModNotification . 30
6.4.5 Type: RabRelNotification . 31
6.4.6 Type: MeasRepUeNotification . 31
6.4.7 Type: MeasTaNotification . 33
6.4.8 Type: CaReConfNotification . 33
6.4.9 Type: ExpiryNotification . 34
6.4.10 Type: S1BearerNotification . 34
6.5 Referenced structured data types . 35
6.5.1 Introduction. 35
6.5.2 Type: LinkType . 35
6.5.3 Type: TimeStamp . 35
6.5.4 Type: AssociateId . 36
6.6 Referenced simple data types and enumerations . 36
7 API definition . 36
7.1 Introduction . 36
7.2 Global definitions and resource structure . 36
7.3 Resource: rab_info . 37
7.3.1 Description . 37
7.3.2 Resource definition . 38
7.3.3 Resource methods . 38
7.3.3.1 GET . 38
7.3.3.2 PUT . 39
7.3.3.3 PATCH . 39
7.3.3.4 POST . 39
7.3.3.5 DELETE . 39
7.4 Resource: plmn_info . 40
7.4.1 Description . 40
7.4.2 Resource definition . 40
7.4.3 Resource methods . 40
7.4.3.1 GET . 40
7.4.3.2 PUT . 41
7.4.3.3 PATCH . 41
7.4.3.4 POST . 41
7.4.3.5 DELETE . 41
7.5 Resource: s1_bearer_info . 42
7.5.1 Description . 42
7.5.2 Resource definition . 42
7.5.3 Resource methods . 42
7.5.3.1 GET . 42
7.5.3.2 PUT . 43
7.5.3.3 PATCH . 43
7.5.3.4 POST . 43
7.5.3.5 DELETE . 43
7.6 Resource: subscriptions . 44
7.6.1 Description . 44
7.6.2 Resource definition . 44
7.6.3 Resource methods . 44
7.6.3.1 GET . 44
7.6.3.2 PUT . 45
7.6.3.3 PATCH . 45
7.6.3.4 POST . 45
7.6.3.5 DELETE . 45
7.7 Resource: subscriptions/{subscriptionType} . 46
7.7.1 Description . 46
7.7.2 Resource definition . 46
7.7.3 Resource methods . 46
7.7.3.1 GET . 46
7.7.3.2 PUT . 47
7.7.3.3 PATCH . 47
7.7.3.4 POST . 47
7.7.3.5 DELETE . 49
ETSI
5 ETSI GS MEC 012 V1.1.1 (2017-07)
7.8 Resource: existing subscription . 49
7.8.1 Description . 49
7.8.2 Resource definition . 49
7.8.3 Resource methods . 49
7.8.3.1 GET . 49
7.8.3.2 PUT . 50
7.8.3.3 PATCH . 52
7.8.3.4 POST . 52
7.8.3.5 DELETE . 52
Annex A (informative): Mapping of permissions for RESTful API and topic based alternative
transport . 54
A.1 Overview . 54
A.2 Mapping of permissions - RESTful and topic based alternative transport . 54
Annex B (informative): Complementary material for API utilisation . 56
History . 57

ETSI
6 ETSI GS MEC 012 V1.1.1 (2017-07)
Intellectual Property Rights
IPRs essential or potentially essential to the present document 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.
Foreword
This Group Specification (GS) has been produced by ETSI Industry Specification Group (ISG) Mobile 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 012 V1.1.1 (2017-07)
1 Scope
The present document focuses on the Radio Network Information mobile edge service. It describes the message flows
and the required information. The present document also specifies the RESTful API with the data model.
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 MEC 001: "Mobile Edge Computing (MEC) Terminology".
[2] IETF RFC 6749: "The OAuth 2.0 Authorization Framework".
NOTE: Available at https://tools.ietf.org/html/rfc6749.
[3] IETF RFC 6750: "The OAuth 2.0 Authorization Framework: Bearer Token Usage".
NOTE: Available at https://tools.ietf.org/html/rfc6750.
[4] IETF RFC 5246: "The Transport Layer Security (TLS) Protocol Version 1.2".
NOTE: Available at https://tools.ietf.org/html/rfc5246.
[5] 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 002: "Mobile Edge Computing (MEC); Technical Requirements".
[i.2] ETSI GS MEC 003: "Mobile Edge Computing (MEC) Framework and reference architecture".
[i.3] ETSI TS 136 413:"LTE; Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1
Application Protocol (S1AP) (3GPP TS 36 413)".
[i.4] ETSI TS 123 401: "LTE; General Packet Radio Service (GPRS) enhancements for Evolved
Universal Terrestrial Radio Access Network (E-UTRAN) access (3GPP TS 23.401)".
ETSI
8 ETSI GS MEC 012 V1.1.1 (2017-07)
[i.5] ETSI TS 136 214: "LTE; Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer;
Measurements (3GPP TS 36 214)".
[i.6] ETSI GS MEC 011: "Mobile Edge Computing (MEC) Mobile Edge Platform Application
Enablement".
[i.7] ETSI TS 136 331:"LTE; Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource
Control (RRC); Protocol specification (3GPP TS 36.331)".
[i.8] ETSI GS MEC 009: "Mobile Edge Computing (MEC) General principles for Mobile Edge Service
APIs".
[i.9] OpenAPI Specification.
NOTE 1: Available at https://github.com/OAI/OpenAPI-Specification.
NOTE 2: OpenAPI Specification version 2.0 is recommended as it is the official release at the time of publication.
[i.10] 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 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in ETSI GS MEC 001 [1] apply.
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI GS MEC 001 [1] and the following apply:
rd
3GPP 3 Generation Partnership Project
API Application Programming Interface
ECGI E-UTRAN Cell Global Identifier
E-RAB E-UTRAN Radio Access Bearer
E-UTRAN Evolved Universal Terrestrial Radio Access Network
GTP GPRS Tunnelling Protocol
GTP-U GPRS Tunneling Protocol-User plane
GW Gateway
HTTP Hypertext Transfer Protocol
HTTPS HTTP over TLS
IE Information Element
IP Internet Protocol
JSON Javascript Object Notation
MCC Mobile Country Code
MMEC MME Code
MNC Mobile Network Code
OAI Open API Initiative
PLMN Public Land Mobile Network
QCI Quality Class Indicator
QoS Quality of Service
RAB Radio Access Bearer
REST Representational State Transfer
RFC Request For Comments
RNI Radio Network Information
RNIS Radio Network Information Service
ETSI
9 ETSI GS MEC 012 V1.1.1 (2017-07)
RSRP Reference Signal Received Power
RSRQ Reference Signal Received Quality
SGW Serving Gateway
TEID Tunnel End Point Identifier
TLS Transport Layer Security
TMSI Temporary Mobile Subscriber Entity
UE User Equipment
URI Uniform Resource Indicator
UTC Coordinated Universal Time
4 Overview
The present document specifies the Radio Network Information API to support the requirements defined for Mobile
Edge Computing in ETSI GS MEC 002 [i.1].
Clause 5 introduces how Radio Network Information Service (RNIS) may be used by the mobile edge applications and
by the mobile edge platform. It describes the information flows used for RNI.
The information that can be exchanged over the RNI API is described in clause 6 which provides detailed description
on all information elements that are used for RNI.
Clause 7 describes the actual RNI API providing detailed information how information elements are mapped into a
RESTful API design.
5 Description of the service (informative)
5.1 RNIS service introduction
Mobile Edge Computing allows running the mobile edge applications at the edge of the network where the environment
is characterized by low latency, proximity, high bandwidth and exposure to location and up-to-date radio network
information. The information on current radio conditions are shared via the mobile edge platform over Radio Network
Information Service.
Radio Network Information Service (RNIS) is a service that provides radio network related information to mobile edge
applications and to mobile edge platforms. The Radio Network Information Service is available for authorized mobile
edge applications and is discovered over the Mp1 reference point [i.2]. The granularity of the radio network information
may be adjusted based on parameters such as information per cell, per User Equipment, per QCI class or it may be
requested over period of time. Typical information that may be provided is listed as follows:
• up-to-date radio network information regarding radio network conditions;
• measurement information related to the user plane based on 3GPP specifications;
• information about UEs connected to the radio node(s) associated with the mobile edge host, their UE context
and the related radio access bearers;
• changes on information related to UEs connected to the radio node(s) associated with the mobile edge host,
their UE context and the related radio access bearers.
The Radio Network Information may be used by the mobile edge applications and platform to optimize the existing
services and to provide new type of services that are based on up to date information on radio conditions. An example
of mobile edge application that uses radio network information to optimize current services is video throughput
guidance. In throughput guidance a radio analytics mobile edge application uses services of Mobile Edge Computing to
provide the backend video server with a near real-time indication on the throughput estimated to be available at the
radio downlink interface in the next time instant. The throughput guidance radio analytics application computes
throughput guidance based on the required radio network information it obtains from a mobile edge service running on
the mobile edge host ETSI GS MEC 002 [i.1].
ETSI
10 ETSI GS MEC 012 V1.1.1 (2017-07)
Radio Network Information may be also used by the mobile edge platform to optimize the mobility procedures required
to support service continuity.
Radio Network Information may cater for a wide range of use cases, where certain mobile edge application requests a
single piece of information using a simple request-response model while other mobile edge applications subscribe to
multiple different notifications regarding information changes. It is reasonable to assume that for simple queries the
RESTful methods are used. However there may be cases where the frequency of updates is so high and the amount of
information is so large that RESTful methods do not scale anymore. In addition, there may be aspects of one-to-many
communications, which cannot be efficiently addressed by RESTful interfaces. For those cases, the Radio Network
Information may be provided over the message broker of the mobile edge platform. The present document does not
specify the actual protocol for a message broker but rather addresses the interoperability aspects by defining stage 2
level definitions to different message types of RNI and by defining the message types in JSON and Protobuf format
together with the present document. A mobile edge application queries information on a message broker via the
transport information query procedure as defined in ETSI GS MEC 011 [i.6]. In addition, the transport information may
be pre-provisioned to the mobile edge application via configuration.
The following clauses describe how the service consumers interact with the Radio Network Information Service over
RNI API to obtain contextual information from the radio access network. The sequence diagrams that are relevant for
Radio Network Information are presented.
5.2 Sequence diagrams
5.2.1 Introduction
The service consumers communicate with the Radio Network Information Service over RNI API to get contextual
information from the radio access network. Both the mobile edge application and mobile edge platform may be service
consumers. Radio Network Information may be provided by both the mobile edge platform and the mobile edge
application.
The Radio Network Information API supports both queries and subscriptions (pub/sub mechanism) that are used over
the RESTful API or over the message broker of the mobile edge platform. A message broker is not specified in detail in
the present document, but the sequence diagrams and message types that are used over a message broker are defined.
For RESTful architectural style, the present document defines the HTTP protocol bindings.
5.2.2 Sending a request for RAB information
Figure 5.2.2-1 shows a scenario where the service consumer (e.g. a mobile edge application or a mobile edge platform)
sends a request to receive a cell level Radio Access Bearer information from the cells that are associated with the
requested mobile edge application instance. The response contains information on users in the cells such as the
identifiers of the cells, the identifiers associated to UEs in the cells and information on their E-RABs, consisting of the
QCI and QoS information.
Figure 5.2.2-1: Flow of service consumer requesting Radio Access Bearer information
A service consumer requesting Radio Access Bearer information, 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 RAB information. The request contains
a mobile edge application instance identifier as an input parameter.
ETSI
11 ETSI GS MEC 012 V1.1.1 (2017-07)
2) RNIS responds with "200 OK" with the message body containing the RabInfo.
5.2.3 Sending a request for PLMN information
Figure 5.2.3-1 shows a scenario where the service consumer (e.g. mobile edge application or mobile edge platform)
sends a query to receive cell level PLMN information related to specific mobile edge application instance. The response
contains information on cells that are associated with the requested instance of a mobile edge application.

Figure 5.2.3-1: Flow of service consumer requesting PLMN information
A service consumer requesting PLMN 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 PLMN information. The request
contains a mobile edge application instance identifier as an input parameter.
2) RNIS responds with "200 OK" with the message body containing the PlmnInfo associated with the requested
mobile edge application instance.
5.2.4 Sending a request for S1 bearer information
With the S1 bearer information acquired from the RNIS, the service consumer (e.g. the mobile edge application or the
mobile edge platform) for example optimizes the relocation of mobile edge applications, or uses the acquired
information for managing the traffic rules for the related application instances. Figure 5.2.4-1 shows a scenario where
the mobile edge application or the mobile edge platform sends a query to receive the S1 bearer information.

Figure 5.2.4-1: Flow of service consumer requesting S1 bearer information
Requesting S1 bearer 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 S1 bearer information.
2) RNIS responds with "200 OK" with the message body containing the S1 bearer information.
ETSI
12 ETSI GS MEC 012 V1.1.1 (2017-07)
5.2.5 REST based subscribe-notify model
5.2.5.1 Subscribing to RNI event notifications
To receive notifications on selected RNI events, the service consumer creates a subscription to certain specific RNI
event that is available at RNIS. Figure 5.2.5.1-1 shows a scenario where the service consumer uses REST based
procedures to create a subscription for RNI event notifications.

Figure 5.2.5.1-1: Flow of subscribing to the RNI event notifications
Subscribing to the RNI event notifications, as illustrated in figure 5.2.5.1-1, consists of the following steps.
When the service consumer wants to receive notifications about the RNI events, it creates a subscription to the RNI
event notifications:
1) The service consumer sends a POST request with the message body containing the {NotificationSubscription}
data structure to the resource representing the RNI subscription type of interest. The variable
{subscriptionType} is replaced with the subscription type specified for different RNI event subscriptions as
specified in clause 7.7.2. The variable {NotificationSubscription} is replaced with the data type specified for
different RNI event subscriptions as specified in clauses 6.3.2 through 6.3.9 , and it defines the subscribed
event, the filtering criteria and the address where the service consumer wishes to receive the RNI event
notifications.
2) RNIS sends "201 Created" response with the message body containing the data structure specific to that RNI
event subscription. The data structure contains the address of the resource created and the subscribed RNI
event type.
5.2.5.2 Receiving notification on expiry of RNI event subscription
RNIS may define an expiry time for the RNI 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 the
expiry, RNIS will also send a notification to the service consumer that owns the subscription.
Figure 5.2.5.2-1 shows a scenario where the service consumer receives a subscription expiry notification for the existing
subscription.
ETSI
13 ETSI GS MEC 012 V1.1.1 (2017-07)

Figure 5.2.5.2-1: Flow of RNIS sending a notification on expiry of the subscription
Sending a notification on expiry of the subscription, as illustrated in figure 5.2.5.2-1 consists of the following steps. If
RNIS has defined an expiry time for the subscription, RNIS will send a notification prior the expiry:
1) RNIS 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.5.3 Updating subscription for RNI event notifications
Figure 5.2.5.3-1 shows a scenario where the service consumer needs to update an existing subscription for a RNI 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.5.3-1: Flow of service consumer updating subscription for RNI event notifications
Updating subscription for RNI event notifications, as illustrated in figure 5.2.5.3-1, consists of the following steps.
When the service consumer needs to modify an existing subscription for RNI 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 containing all
the subscriptions of the specific subscription type with the modified data structure specific to that RNI event
subscription.
2) RNIS returns "200 OK" with the message body containing the accepted data structure specific to that RNI
event subscription.
ETSI
14 ETSI GS MEC 012 V1.1.1 (2017-07)
5.2.5.4 Unsubscribing from RNI event notifications
When the service consumer does not want to receive notifications anymore after subscribing to RNI events, the service
consumer unsubscribes from the RNI event notifications. Figure 5.2.5.4-1 shows a scenario where the service consumer
uses REST based procedures to delete the subscription for RNI event notifications.

Figure 5.2.5.4-1: Flow of unsubscribing from the RNI event notifications
Unsubscribing from the RNI event notifications, as illustrated in figure 5.2.5.4-1, consists of the following steps:
When the service consumer does not want to receive the notifications anymore, it can unsubscribe from the RNI
notification events by deleting the subscription:
1) Service consumer sends a DELETE request to the resource representing the RNI event subscription that was
created.
2) RNIS sends "204 No content" response.
5.2.6 Receiving RNI event notifications about cell changes
Figure 5.2.6-1 presents the scenario where the RNIS sends RNI event notification on cell changes to the service
consumer. The notification contains the identifiers related to the UE and both the source and target cells.
ETSI
15 ETSI GS MEC 012 V1.1.1 (2017-07)

Figure 5.2.6-1: Flow of receiving RNI event notifications on cell changes
Receiving RNI event notifications on cell changes, as illustrated in figure 5.2.6-1, consists of the following steps:
1) RNIS sends a POST request with the message body containing the CellChangeNotification data structure to
the callback reference address included by the service consumer in the RNI cell change event subscription.
2) Service consumer sends a "204 No Content" response to the RNIS.
5.2.7 Receiving RNI event notifications about Radio Access Bearer
establishment
Figure 5.2.7-1 presents the scenario where the RNIS sends RNI event notification on RAB establishment to the service
consumer.
ETSI
16 ETSI GS MEC 012 V1.1.1 (2017-07)

Figure 5.2.7-1: Flow of receiving RNI event notifications on RAB establishment
Re
...