ETSI GS MEC 012 V2.1.1 (2019-12)
Multi-access Edge Computing (MEC); Radio Network Information API
Multi-access Edge Computing (MEC); Radio Network Information API
RGS/MEC-0012v211RnisApi
General Information
Standards Content (Sample)
GROUP SPECIFICATION
Multi-access Edge Computing (MEC);
Radio Network 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 012 V2.1.1 (2019-12)
Reference
RGS/MEC-0012v211RnisApi
Keywords
API, MEC, RNIS
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
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 012 V2.1.1 (2019-12)
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 . 9
4 Overview . 9
5 Description of the service (informative). 10
5.1 RNIS service introduction . 10
5.2 Sequence diagrams . 11
5.2.1 Introduction. 11
5.2.2 Sending a request for RAB information . 11
5.2.3 Sending a request for PLMN information . 11
5.2.4 Sending a request for S1 bearer information . 12
5.2.4a Sending a request for Layer 2 measurements information . 12
5.2.5 REST based subscribe-notify model . 13
5.2.5.1 Subscribing to RNI event notifications . 13
5.2.5.2 Receiving notification on expiry of RNI event subscription . 13
5.2.5.3 Updating subscription for RNI event notifications . 14
5.2.5.4 Unsubscribing from RNI event notifications . 15
5.2.6 Receiving RNI event notifications about cell changes. 15
5.2.7 Receiving RNI event notifications about Radio Access Bearer establishment . 16
5.2.8 Receiving RNI event notifications about Radio Access Bearer modification . 17
5.2.9 Receiving RNI event notifications about Radio Access Bearer release . 18
5.2.10 Receiving RNI event notifications about UE measurement reports. 19
5.2.11 Receiving RNI event notifications about UE timing advance . 20
5.2.12 Receiving RNI event notifications about carrier aggregation reconfiguration . 20
5.2.13 Receiving RNI event notifications about S1 bearer . 21
5.2.14 Receiving RNI event notifications about 5G UE measurement reports . 22
6 Data model . 23
6.1 Introduction . 23
6.2 Resource data types . 23
6.2.1 Introduction. 23
6.2.2 Type: PlmnInfo . 23
6.2.3 Type: RabInfo . 24
6.2.4 Type: S1BearerInfo. 24
6.2.4a Type: L2Meas . 25
6.3 Subscription data types . 27
6.3.1 Introduction. 27
6.3.2 Type: CellChangeSubscription . 27
6.3.3 Type: RabEstSubscription . 28
6.3.4 Type: RabModSubscription . 28
6.3.5 Type: RabRelSubscription . 29
6.3.6 Type: MeasRepUeSubscription . 29
6.3.7 Type: MeasTaSubscription . 30
6.3.8 Type: CaReconfSubscription . 30
6.3.9 Type: S1BearerSubscription . 31
6.3.10 Type: SubscriptionLinkList . 31
ETSI
4 ETSI GS MEC 012 V2.1.1 (2019-12)
6.3.11 Type: NrMeasRepUeSubscription . 32
6.4 Notification data types . 32
6.4.1 Introduction. 32
6.4.2 Type: CellChangeNotification . 32
6.4.3 Type: RabEstNotification . 33
6.4.4 Type: RabModNotification . 33
6.4.5 Type: RabRelNotification . 34
6.4.6 Type: MeasRepUeNotification . 34
6.4.7 Type: MeasTaNotification . 36
6.4.8 Type: CaReConfNotification . 36
6.4.9 Type: ExpiryNotification . 37
6.4.10 Type: S1BearerNotification . 37
6.4.11 Type: NrMeasRepUeNotification . 38
6.5 Referenced structured data types . 39
6.5.1 Introduction. 39
6.5.2 Type: LinkType . 40
6.5.3 Type: TimeStamp . 40
6.5.4 Type: AssociateId . 40
6.5.5 Type: Plmn. 40
6.5.6 Type: Ecgi . 40
6.5.7 Type: NRcgi. 41
6.5.8 Type: RsIndexResults . 41
6.5.9 Type: ResultsPerSsbIndexList . 41
6.5.10 Type: ResultsPerCsiRsIndexList . 41
6.5.11 Type: MeasQuantityResultsNr. 42
6.6 Referenced simple data types and enumerations . 42
6.6.1 Introduction. 42
6.6.2 Simple data types . 42
6.6.3 Enumeration: Trigger . 42
6.6.4 Enumeration: TriggerNr . 43
7 API definition . 43
7.1 Introduction . 43
7.2 Global definitions and resource structure . 44
7.3 Resource: rab_info . 45
7.3.1 Description . 45
7.3.2 Resource definition . 45
7.3.3 Resource methods . 45
7.3.3.1 GET . 45
7.3.3.2 PUT . 47
7.3.3.3 PATCH . 47
7.3.3.4 POST . 47
7.3.3.5 DELETE . 47
7.4 Resource: plmn_info . 48
7.4.1 Description . 48
7.4.2 Resource definition . 48
7.4.3 Resource methods . 48
7.4.3.1 GET . 48
7.4.3.2 PUT . 49
7.4.3.3 PATCH . 49
7.4.3.4 POST . 49
7.4.3.5 DELETE . 49
7.5 Resource: s1_bearer_info . 50
7.5.1 Description . 50
7.5.2 Resource definition . 50
7.5.3 Resource methods . 50
7.5.3.1 GET . 50
7.5.3.2 PUT . 51
7.5.3.3 PATCH . 51
7.5.3.4 POST . 51
7.5.3.5 DELETE . 51
7.5a Resource: layer2_meas . 52
ETSI
5 ETSI GS MEC 012 V2.1.1 (2019-12)
7.5a.1 Description . 52
7.5a.2 Resource definition . 52
7.5a.3 Resource methods . 52
7.5a.3.1 GET . 52
7.5a.3.2 PUT . 54
7.5a.3.3 PATCH . 54
7.5a.3.4 POST . 54
7.5a.3.5 DELETE . 54
7.6 Resource: subscriptions . 55
7.6.1 Description . 55
7.6.2 Resource definition . 55
7.6.3 Resource methods . 55
7.6.3.1 GET . 55
7.6.3.2 PUT . 56
7.6.3.3 PATCH . 56
7.6.3.4 POST . 56
7.6.3.5 DELETE . 58
7.7 Void . 58
7.8 Resource: existing subscription . 58
7.8.1 Description . 58
7.8.2 Resource definition . 58
7.8.3 Resource methods . 59
7.8.3.1 GET . 59
7.8.3.2 PUT . 60
7.8.3.3 PATCH . 61
7.8.3.4 POST . 62
7.8.3.5 DELETE . 62
Annex A (informative): Mapping of permissions for RESTful API and topic based alternative
transport . 63
A.1 Overview . 63
A.2 Mapping of permissions - RESTful and topic based alternative transport . 63
Annex B (informative): Complementary material for API utilisation . 65
History . 66
ETSI
6 ETSI GS MEC 012 V2.1.1 (2019-12)
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 012 V2.1.1 (2019-12)
1 Scope
The present document focuses on the Radio Network Information MEC 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: "Multi-access 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: "Multi-access Edge Computing (MEC); Phase 2: Use Cases and
Requirements".
[i.2] ETSI GS MEC 003: "Multi-access 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)".
ETSI
8 ETSI GS MEC 012 V2.1.1 (2019-12)
[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)".
[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: "Multi-access Edge Computing (MEC) MEC 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: "Multi-access Edge Computing (MEC) General principles for MEC Service
APIs".
[i.9] OpenAPI Specification.
NOTE: Available at https://github.com/OAI/OpenAPI-Specification.
[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.
[i.11] ETSI TS 136 314: " Evolved Universal Terrestrial Radio Access (E-UTRA); Layer 2 -
Measurements (3GPP TS 36.314)".
[i.12] ETSI TS 136 423: " Evolved Universal Terrestrial Radio Access (E-UTRA); X2 application
protocol (X2AP) (3GPP TS 36.423)".
[i.13] ETSI TS 138 331: "5G; NR; Radio Resource Control (RRC); Protocol specification (3GPP
TS 38.331)".
[i.14] ETSI TS 138 133: "5G; NR; Requirements for support of radio resource management (3GPP
TS 38.133)".
[i.15] ETSI TS 138 101 (all parts): "5G; NR; User Equipment (UE) radio transmission and reception;
(3GPP TS 38.101)".
[i.16] ETSI TS 136 133: "Evolved Universal Terrestrial Radio Access (E-UTRA); Requirements for
support of radio resource management (3GPP TS 36.133)".
[i.17] ETSI TS 138 423: "5G; NG-RAN; Xn Application Protocol (XnAP) (3GPP TS 38.423)".
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.
ETSI
9 ETSI GS MEC 012 V2.1.1 (2019-12)
3.3 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
DL DownLink
ECGI E-UTRAN Cell Global Identifier
E-RAB E-UTRAN Radio Access Bearer
E-UTRAN Evolved Universal Terrestrial Radio Access Network
GBR Guaranteed Bit Rate
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
PRB Physical Resource Block
RAB Radio Access Bearer
REST REpresentational State Transfer
RFC Request For Comments
RNI Radio Network Information
RNIS Radio Network Information Service
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
UL Uplink
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
Multi-access Edge Computing in ETSI GS MEC 002 [i.1].
Clause 5 introduces how Radio Network Information Service (RNIS) may be used by the MEC applications and by the
MEC 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.
ETSI
10 ETSI GS MEC 012 V2.1.1 (2019-12)
5 Description of the service (informative)
5.1 RNIS 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, high bandwidth and exposure to location and up-to-date radio network
information. The information on current radio conditions are shared via the MEC platform over Radio Network
Information Service.
Radio Network Information Service (RNIS) is a service that provides radio network related information to MEC
applications and to MEC platforms. The Radio Network Information Service is available for authorized MEC
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 MEC 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 MEC host, their UE
context and the related radio access bearers.
The Radio Network Information may be used by the MEC applications and MEC 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 MEC application that uses radio network information to optimize current services is video throughput guidance.
Throughput guidance radio analytics MEC application uses services of Multi-access 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 MEC application computes throughput
guidance based on the required radio network information it obtains from a MEC service running on the MEC host
ETSI GS MEC 002 [i.1].
Radio Network Information may be also used by the MEC 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 MEC application requests a single
piece of information using a simple request-response model while other MEC 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 MEC 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 MEC 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 MEC 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.
ETSI
11 ETSI GS MEC 012 V2.1.1 (2019-12)
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 MEC application and MEC platform may be service consumers.
Radio Network Information may be provided by both the MEC platform and the MEC 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 MEC 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 MEC application or a MEC platform) sends a
request to receive a cell level Radio Access Bearer information from the cells that are associated with the requested
MEC 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 MEC application instance identifier as an input parameter.
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. MEC application or MEC platform) sends a query to
receive cell level PLMN information related to specific MEC application instance(s). The response contains information
on cells that are associated with the requested MEC application instance(s).
Figure 5.2.3-1: Flow of service consumer requesting PLMN information
ETSI
12 ETSI GS MEC 012 V2.1.1 (2019-12)
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 MEC application instance identifier(s) as an input parameter.
2) RNIS responds with "200 OK" with the message body containing the list of PlmnInfo associated with the
requested MEC application instance(s).
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 MEC application or the MEC
platform) for example optimizes the relocation of MEC 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 MEC application or the
MEC 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.
5.2.4a Sending a request for Layer 2 measurements information
Figure 5.2.4a-1 shows a scenario where the service consumer (e.g. a MEC application or a MEC platform) sends a
request to receive the Layer 2 measurements information from one or more eNBs that are associated with the requested
MEC application instance. The response contains information of the Layer 2 measurements performed by the eNBs
and/or the UEs as specified in ETSI TS 136 314 [i.11].
Figure 5.2.4a-1: Flow of service consumer requesting Layer 2 measurements information
A service consumer requesting Layer 2 measurements information, as illustrated in figure 5.2.4a-1, consists of the
following steps:
1) Service consumer sends a GET request to the resource representing the Layer 2 measurements information.
2) RNIS responds with "200 OK" with the message body containing the Layer 2 measurement information.
ETSI
13 ETSI GS MEC 012 V2.1.1 (2019-12)
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 RNI subscription. 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 in 6.3.11 , and it defines the subscribed event, the filtering criteria and the address where the service
consumer wishes to
...








Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...