| Internet-Draft | MoWIE for Network Aware Application | March 2024 |
| Mertus, et al. | Expires 2 September 2024 | [Page] |
With the deployment of 5G networks, cloud-based interactive services such as cloud gaming have gained substantial attention. To ensure users' quality of experience (QoE), a cloud interactive service may require not only high bandwidth (e.g., high-resolution media transmission) but also low delay (e.g., low latency and low lagging). However, the quality perceived by a user of a mobile and wireless device may vary widely as a function of many factors, and unhandled changes can substantially compromise the user's QoE. In this document, we investigate network-aware applications (NAA), which realize cloud-based interactive services with improved QoE, by efficient utilization of a solution named Mobile and Wireless Information Exposure (MoWIE). In particular, this document demonstrates, through realistic evaluations, that mobile network information such as MCS (Modulation and Coding Scheme) can effectively expose the dynamics of the underlying network and can be made available to applications through MoWIE; using such an information, the applications can then adapt key control knobs such as media codec schemes, encapsulation, and application layer processing to minimize QoE distortion. Following evaluations we give a cursory overview of the design space for implementing MoWIE¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 2 September 2024.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
With the deployment of 5G networks [draft-ietf-dmm-5g-uplane-analysis] , an increasing number of remote cloud-based applications are being deployed (e.g., cloud AR/VR/MR). Many conventional interactive, daily business applications are also becoming widely used as cloud applications, with the help of mobile networks and cloud, e.g., cloud video conference. This shift was further accelerated by the COVID-19 pandemic in 2020, when many people had to stay at home and work/study remotely¶
To optimize QoE for end users using mobile networks (a.k.a., cellular networks), many cloud applications utilize information about the mobile network status, e.g., delay, bandwidth, and jitter, to dynamically balance the generated media traffic and the rendering/mixing in the cloud. Currently, such an application assumes the network as a link and continuously uses client or server measurements to detect network characteristics, and then adaptively changes its network-related configuration parameters, possibly impacting QoS handling and logical functions supporting the upper layer application. However, when only application information is utilized, the QoE that an application achieves is limited for several reasons. First, information from the application side (i.e., the 3rd party application server) may have a relatively long delay. When a user enters a location with a bad network connectivity, such as an elevator or an underground garage, the application will not receive such an information immediately. As a result, the buffer of a video application may run out, resulting in a frozen screen and harming users' QoE. The application also does not have information about other users in the cell. Thus, it cannot know how many resources it can get and when this will change. If other users enter the cell and compete for resources, the application layer may misjudge the resources available and request a high bitrate. Then, the delay will increase and QoE will again drop. Information from the network layer such as physical resource block (PRB) information and utilization rate can help applications decide how many resources a user can access in order to inform network quality predictions and further optimize video streaming. The application, however, cannot get this kind of information yet. Because 5G networks deployed by a mobile network operation are normally in a different domain than 3rd-party internet-based applications, the application server can not directly get the network internal status without network exposure. For this reason, there have been continuous efforts in 3GPP to increase network exposure.¶
3GPP mobile networks adhere to standard solutions to get dynamic network indicators for use by applications. In 3GPP, many IP-based QoS mechanisms are used. For example, ECN [RFC3168] has been supported by the 4G radio station (eNB) to provide CE(Congestion Encountered) information to the IMS application to perform Adaptive Bitrate (ABR) [TS26.114] . The application can downgrade the bit rate after receiving the CE indication, but does not know the exact bit rate to be selected. DSCP [RFC2474] is used to identify the QoS class and paging strategy [TS23.501] , but typically the application cannot dynamically change the DSCP to improve bit rate based on network status. Mapping DSCP with 4G QCI or 5G 5QI standards could be a good approach to better realize end-to-end QoS. DASH [MPEGDASH] is an MPEG standard widely used by applications to predict the throughput of the network based on the current throughput and buffering state in order to dynamically select a suitable bitrate for the next segment of video streaming which avoids re-buffering. SAND-DASH [TS26.247] defines the mechanism through which the network/server can provide available throughput to applications; in this case, the better bitrate can be selected by DASH application.¶
There is also some early work on network status exposure to TCP servers which may also indirectly impact application layer optimization but it does not consider 5G networks [Sprecher_mobile] , [flinck_mobile] In 5G cellular networks, network capability exposure has been specified to allow the 5G system (5GS) to expose user device location and network status to 3rd party application servers, modeled as AF (Application Function) [TS23.501] . In such a case, the AF can request the 5GS to establish a dedicated QoS Flow to transport an IP flow with the AF-provided QoS requirements. Via certain measurements, network internal status, including congestion, can be exposed and optimization can be carried out for the cellular network [PBECC] .¶
5G also can provide QNC (QoS Notification Control) to an AF if the GBR(Guaranteed Bitrate) of the established GBR QoS Flow cannot be fulfilled. After receiving the QNC notification the AF can change the bitrate, but the AF has no information on which bitrate to select. So, 5G enhances the QNC by providing a list of AQPs (alternative QoS profiles). With AQP, a 5G network provides a subset of supported AQPs with the QNC, and then the AF selects a bit rate from 5G network supported AQPs. In such a case, the GBR can be fulfilled again if the radio state of the UE is changed. QoS prediction is realized by a network function inside 5GS which collects and analyzes the status and qualities of 5G network entities, and deliver the analytics results to an entity such as application server.¶
However, both network capability exposure and QoS prediction solutions are only designed for 5G access and core networks, which cannot cover the whole end-to-end network. Enabling applications to detect and understand the various lower layers within 5G networks, particularly the internal DN (data network), is an important area for both industrial and academic researchers. This challenge is addressed by MoWIE.¶
MoWIE is a solution that aims to realize real-time provisioning of cellular radio network information by networks to applications, thus helping service providers achieve better policy control and improve user experience. The benefits of the MoWIE concept/solution have been experimentally evaluated in several use cases, detailed in the following section.¶
The fundamental idea of MoWIE is to provide on-demand and periodic network information from the network to applications, enhancing policy control and user experience. This basic conceptualization includes the following key components: the Client Application, the Mobile Network, and the Application Server. Raw data collected from the Mobile Network is processed and exposed to the Application Server. This server can then request network information and use this information to optimize application functions in the Client Application like bit rate, latency, and jitter. Network information provided by MoWIE includes the following:¶
Cell level Information:¶
Number of Downlink PRBs (Physical Resource Blocks) occupied during sampling period¶
Cell load¶
Downlink (DL) MAC data rate per cell¶
DL data rate¶
Channel status (e.g. RSRP (Reference Signal Received Power) and CQI (Channel Quality Indicator))¶
PDCP (Packet Data Convergence Protocol) buffer status¶
UE level information (omitting privacy information):¶
DL Signal to Inference plus Noise Ratio (SINR)¶
Modulation and Coding Scheme (MCS)¶
Number of packets occupied in PDCP buffer¶
Number of DL PDCP Service Data Unit (SDU) packets¶
Number of lost PDCP SDU packets¶
Per-UE DL MAC data rate¶
Per-UE DL data rate¶
Per-UE channel status¶
Per-UE PDCP (Packet Data Convergence Protocol) buffer status¶
The network information listed here can also be found in 3GPP (PRB [TS38.211] , cell load [TS38.300] PDCP for 5G [TS38.323] RSRP, RSRQ, RSSI [TS38.331] , MCS, CQI [TS38.214] , The number of packets occupied in PDCP buffer, the number of DL PDCP SDU packets, the number of PDCP SDU packets lost, the per-UE PDCP buffer status [TS38.323] ), demonstrate the potential benefits of MoWIE for network-application integration over cellular network. Figure 3-1 and Figure 3-2 list the data types corresponding to the cell-level information and UE-level information respectively.¶
+----------------------+--------------------------+
|Cell-level Information| Data type/Range |
+----------------------+--------------------------+
| PRB | Uint16 |
+----------------------+--------------------------+
| CQI | Uint8 |
+----------------------+--------------------------+
| RSRP | Uint8 |
+----------------------+--------------------------+
| RSRQ | Uint8 |
+----------------------+--------------------------+
| Cell load | [0,1] |
+----------------------+--------------------------+
Figure 4-1: Cell level data type
¶
+------------------------------------+---------------+
| UE-level Information |Data type/Range|
+------------------------------------+---------------+
| Downlink SINR | Uint16 |
+------------------------------------+---------------+
| MCS | Uint8 |
+------------------------------------+---------------+
| Downlink PDCP SDU packets | Uint8 |
+------------------------------------+---------------+
| PDCP SDU packets lost | Uint8 |
+------------------------------------+---------------+
| Packets occupied in PDCP buffer | [0,1] |
+------------------------------------+---------------+
| CQI | Uint8 |
+------------------------------------+---------------+
| RSRP | Uint8 |
+------------------------------------+---------------+
| RSRQ | Uint8 |
+------------------------------------+---------------+
Figure 4-2: UE level data type
¶
Cloud gaming, low-delay live shows, and cloud VR are commons NAAs whose QoE can be largely enhanced using MoWIE. These applications require low latency and reliable transmission, interactive features, and high data rates. For instance, cloud gaming demands fast, reliable connections between user devices and cloud servers for motion tracking and visual content delivery, significantly contributing to network traffic. Similarly, low-delay live shows require interactive capabilities with sub-100 ms delays for audience engagement, while cloud VR demands extensive bandwidth and latency as low as 20 ms due to its high data volumes and rendering requirements.¶
Performance requirements across these applications may be characterized by a parameter range. Here we consider 1080p~4K as the resolution range, 60-120 FPS (Frames per second) as the frame rate and H.265 as an example compression algorithm. Given these settings, cloud gaming requires a bandwidth of 20-60 Mbps and latency under 200 ms. For low-delay live shows, 20-50 Mbps bandwidth and latency under 100 ms are needed, while cloud VR demands 100-500 Mbps bandwidth and latency under 50 ms. These values are dependent on the parameter settings and are provided to illustrate the order of magnitude of these parameters for the aforementioned use cases.¶
MoWIE's network information can be used to enhance these applications, particularly in mobile and wireless contexts where existing methods struggle due to indirect or delayed network status measurements. By providing direct, real-time data, MoWIE enables more responsive and effective application adjustments, leading to substantial performance gains and enhanced QoE.¶
Preliminary tests demonstrate significant QoE improvements for NAAs using MoWIE. By integrating real-time network information, applications can optimize performance, leading to enhanced QoE and resource savings.¶
In trials on real mobile networks, RAN information was used to inform TCP sending window adjustment by predicting bandwidth and buffer status per-UE at RTT granularity (100 ms) and piggybacking such information in TCP ACK. This approach has shown throughput boosts of up to 100%.¶
ROI (Region of Interest) detection has been widely studied in recently years as a mechanism to reduce video size and bandwidth consumption by dynamically re-allocating coding schemes for interested and non-interested regions. Current methods utilize application information like application rate and application buffer size as the indicators to roughly adjust the algorithm in interactive video services. However, this information is hard to reflect the real-time network status precisely, making it difficult to balance QoE and bandwidth savings in real-time scenarios, including the standard NAAs outlined above. MoWIE's network information can provide direct, real-time data to improve the performance of ROI methods.¶
Experiments evaluated the following four methods of ROI detection: 1) no ROI detection, 2) rough ROI detection at 10ms delay, 3) accurate ROI detection at 40-70ms delay, and 4) dynamic ROI detection in which bandwidth traces are used to compute transmission delay and inform ROI algorithm adjustments. Network conditions varied from poor (Network 1) to good (Network 2) and fluctuating (Network 3). Our findings show that method 4 provides the best balance between QoE and bandwidth savings, especially in adverse network scenarios.¶
+---+-----------------+-----------------+-----------------+
| | Network 1 | Network 2 | Network 3 |
+---+---+-------------+---+-------------+---+-------------+
| |QoE| BW Saving |QoE| BW Saving |QoE| BW Saving |
+---+---+-------------+---+-------------+---+-------------+
| 1 |3.8| 0% |4.8| 0% |4.3| 0% |
+---+---+-------------+---+-------------+---+-------------+
| 2 |3.8| 5% |4.8| 9% |4.3| 7% |
+---+---+-------------+---+-------------+---+-------------+
| 3 |2.2| 2.1% |4.6| 38% |3.1| 34% |
+---+---+-------------+---+-------------+---+-------------+
| 4 |3.6| 9% |4.7| 33% |4.3| 25% |
+---+---+-------------+---+-------------+---+-------------+
Figure 4-3: QoE and Bandwidth Saving
¶
Many applications such as video live streaming and cloud gaming employ adaptive bitrate (ABR) algorithms to optimize user QoE [MPC] [CS2P]. However, traditional ABR algorithms use fixed control rules based on simplified or inaccurate models of the deployment environment, leading to suboptimal performance across a broad set of network conditions and QoE objectives. More recent ABR algorithms, such as Pensieve [Hongzi], use reinforcement learning to optimize QoE, but still suffer from limitations due to indirect or delayed network status measurements and an incomplete set of network information. MoWIE's network information can be used to enhance ABR algorithms, particularly in challenging network conditions.¶
This experiment applied AI-based rate adaptation utilizing MCS network information from gNBs [TS38.214] in cloud-gaming over Tencent's China Mobile LTE network. MCS information was provided directly to the application. Data was collected over several network conditions: 1) low bandwidth, 2) high user load, 3-5) random user distributions. Lagging rate is defined as the ratio between the number of frames with transmission delay greater than 200ms and the total number of frames.¶
+-------------+--------------------------+
|Test Scenario| Reduction of Lagging Rate|
+-------------+--------------------------+
| 1 | 46% |
+-------------+--------------------------+
| 2 | 21% |
+-------------+--------------------------+
| 3 | 37% |
+-------------+--------------------------+
| 4 | 56% |
+-------------+--------------------------+
| 5 | 32% |
+-------------+--------------------------+
Figure 4-4: Reduction of Lagging Rate
¶
We clearly observe a significant reduction in lagging rates across all scenarios.¶
Thus far we have outlined the information that MoWIE provides. Now we will consider how this information can be exposed to the application. We identify two distinct approaches:¶
On-path signaling: this refers to the process of exposing network information to the application through the same path as the application's data; this is also known as inband communication or simply, path signaling [RFC9419].¶
Off-path signaling: this refers to the process of exposing network information to the application through a separate path.¶
For each of these approach we establish key high-level components and introduce a discussion of the design space. We also list possible security considerations as well as the benefits and drawbacks of each approach.¶
In our discussion of on-path signaling we maintain the following entities from our initial discussion on MoWIE: the Application Server, the Mobile Network, and the Client Application. From the Mobile Network we derive the the gNB which will serve as the on-path entity which exposes network information to the application.¶
The initial structure is as follows:¶
Client Application gNB Application Server
+---+ +--------------+ +----------------+
| |-------------| |---------| |
| | | | | |
| | | | | |
+---+ +--------------+ +----------------+
------------
application connection
¶
We identify the following key components for achieving MoWIE via on-path signaling¶
Collecting and processing network information: the gNB can regularly collect and process the network information included in the MoWIE framework. gNBs are well positioned to collect this information given their central role in the 5G network. They may leverage various aspects of the 5G architecture to collect this information, such as the RAN, the core network, and the UE.¶
Discovering the on-path gNB by the Application Server: this may be done by the gNB advertising itself to the Application Server in several manners. One method is to encapsulate the original payload within a new layer. Another option is to inject additional packets on an UDP option or IP header. These methods are discussed in [SADCDN]. Additional methods of interleaving with the original payload may also be considered.¶
Discovering the on-path gNB by the Application Client: if the gNB is able to associate packets outgoing to the Application Server with incoming packets to the Application Client, similar methods to to those used previously may be applied. Else, this challenge may be addressed through direct communication between the Application Server and the gNB. Complications arise due to the dynamic nature of mobile IPs and the potential for NATs to be present in the path.¶
Communication between the application and the gNB: after discovery, the Application Server or Client can establish a separate QUIC connection with the gNB and request network information, both individually and at regular specified intervals. The gNB will then respond with the requested information, which the Application Server can use to optimize the application's behavior. Alternatively, the gNB may be able able to piggyback network information on packets running through the existing QUIC connection.¶
Performance Isolation: to preserve the integrity of the application function, the original QUIC connection should not be affected by the additional signaling. This may have implications for the gNB's ability to parse and alter hte original payload given the performance impact.¶
Security and privacy: all signaling must utilize as little information as possible to achieve the desired result and all information exposure should be transparent to both the users to adhere to the principles of minimal information exposure and user consent outlined in [RFC9419]. The process should also allow for negotiation of signaling parameters to ensure trust between the Application Server and gNB. The application may leverage QUIC's secure and authenticated transport layer to ensure the integrity and security of the communication.¶
Scalability: the process should be lightweight to assist in scalability. Scalability will ultimately depend on the performance capabilities of gNBs. These additional QUIC connections may strain gNB when under heavy user load.¶
Application control: the process should be under the application's control in accordance with [RFC9419] and align with their networking requirements. We prefer starting with a pull model to ensure information exposure is entirely optional and under the application's control. The application can choose to request only the network information desired, only when it is desired.¶
Robustness: the process should be robust to network changes and failures. The process should also be able to handle the dynamic nature of mobile networks, where clients frequently move and switch gNBs. If the existing direct data path changes, the signaling path should be able to adapt to the new path.¶
Once connection has been established we can visualize the structure as follows:¶
Client Application gNB Application Server
+---+ +--------------+ +----------------+
| |-------------| |---------| |
| |+++++++++++++| |+++++++++| |
| | | | | |
+---+ +--------------+ +----------------+
------------ +++++++++
application connection MoWIE connection
¶
Of key importance in this implementation is the security of the exchanged data. Once authentication between the Application Server and gNB has taken place, any exchanged data must be protected from becoming a vector for possible malicious action. Standard cryptographic techniques should be employed to ensure the confidentiality, integrity, and authenticity of the signaling data. Misuse of this signaling mechanism should be minimized through common security practices such as rate limiting.¶
The initial exposure of the gNB to the Application Server must take place prior to authentication between these two entities. This must be carefully managed to ensure that the gNB is not exposed to any malicious actors.¶
On-path signaling is a powerful tool for enabling real-time network information exchange to enable dynamic NAAs. The primary benefit of an implementation with on-path signaling is that it greatly simplifies the challenge of associating a particular Application Server/Client Application pair with the relevant gNB and as a result, the relevant set of network information.¶
However, on-path signaling also presents several challenges. Any mechanism of initial connection relying on the gNB piggybacking off the existing QUIC connections fights the encryption and integration protection of the original QUIC connection. The gNB would need to be able to parse the original, encrypted payload, and may affect, for example, performance of the original core functionality. The alternative of appending additional packets on an UDP option or IP header would require support from both the Application Server and Client Application which may be difficult to ensure.¶
Another challenge is the increased overhead associated with maintaining additional QUIC channels. As indicated earlier, in high-traffic scenarios this load may strain gNBs and due to the nature of on-path signaling, the gNB is the only entity that can provide the network information. This may create bottlenecks and limit the scalability of the solution.¶
In this discussion on off-path signaling, we continue with the entities previously established: the Application Server, the Mobile Network, and the Client Application. Contrary to the on-path scenario, here we introduce a third-party node, called the Information Server, which stands outside the direct data flow and is tasked with providing network information to the application.¶
The initial structure is as follows:¶
Information Server
+--------------+
| |
| |
| |
+--------------+
Client Application gNB Application Server
+---+ +--------------+ +----------------+
| |-------------| |---------| |
| | | | | |
| | | | | |
+---+ +--------------+ +----------------+
------------
application connection
¶
We identify the following key components for achieving MoWIE via off-path signaling:¶
Collecting and processing network information: the Information Server is tasked with aggregating and processing network information pertinent to the MoWIE framework. This entity may collate data from various sources within the 5G network, leveraging information from the RAN, core network elements, and potentially direct reports from UEs or gNBs.¶
Discovering the relevant Information Server by the Application Server or Client: on both server and client side the application faces the challenge of locating the relevant Information Service for acquiring network information that impacts the application's performance. Application of service discovery protocols or reverse DNS lookups may fail to solve this issue due to the dynamic nature of mobile networks and the potential for NATs to be present in the path.¶
Discovering the network path and relevant cellular nodes for the application: the Information Server must ascertain the network path from the Application Server to the Client, identifying key network nodes like gNBs. This might involve leveraging 5G network's Service Based Architecture to query information from core network functions such as the AMF.¶
Communication between the application and the Information Server: following discovery, a new connection may be established between Information Server and the Application Server of Client for the exchange of network information. QUIC may be used to secure and authenticate this communication. This setup allows for the periodical or on-demand request and retrieval of network data relevant to optimizing application behavior.¶
Security and privacy: just as in the on-path model, all signaling must utilize as little information as possible to achieve the desired result and all information exposure should be transparent to both the users to adhere to the principles of minimal information exposure and user consent. The process should also allow for negotiation of signaling parameters to ensure trust between the application and Information Server. Encryption and authentication should be applied for all communications. In order to facilitate widespread adoption, Information Server must be secure.¶
Scalability: again, the design must ensure that the off-path signaling mechanism does not adversely impact the primary application's functionality. A dynamic association between Information Servers and network regions may be necessary to ensure that the system scales efficiently with the number of users and fluctuating network conditions without overburdening the Information Server.¶
Application control and user consent: similar to the on-path model, off-path signaling should be initiated under the application's control. We again prefer starting with a pull model to ensure information exposure is entirely optional and under the application's control. The application can choose to request only the network information desired, only when it is desired.¶
Robustness: given the dynamic nature of mobile networks, the off-path signaling process must be capable of adapting to changes such as network reconfigurations, user mobility, and varying network conditions. The function of discovering the relevant Information Server and network path must be repeated periodically to ensure the application server is always communicating with the relevant Information Server and receiving the most up-to-date network information.¶
When in use, the off-path model can be visualized as follows:¶
Information Server
+--------------+
- - - | | - - -
/ | | \
/ | | \
/ +--------------+ \
/ \
Client Application gNB Application Server
+---+ +--------------+ +----------------+
| |-------------| |---------| |
| | | | | |
| | | | | |
+---+ +--------------+ +----------------+
------------ - - - - - - - -
application connection MoWIE connection
¶
The introduction of the Information Server brings several security challenges. Even when applying a principle of minimal information exposure, the Information Server must have access to detailed network path information, which implies certain user privacy concerns. It is essential to implement strict retention policies to ensure sensitive data is discarded as soon as it is no longer needed. This concern provides additional emphasis to the need for robust authentication and encryption between the Application Server and the Information Server.¶
Off-path signaling provides several benefits. First, by decoupling the network information delivery from the direct data path, we reduce the potential for bottlenecks and scalability issues associated with on-path signaling. Also, regarding extensibility, off-path signaling allows for the integration of broader network information not available to on-path entities.¶
Although off-path signaling exposes sensitive information to a new, non-essential entity, this security risk is offset by removing the necessity to mess with an existing QUIC connection, which itself introduced a risk to the original data path. We also observe that applying an off-path approach may reduce the possibility that this signaling mechanism will affect the core functionality of the application.¶
Just as gNBs in the on-path approach, the Information Server is a potential bottleneck and point of failure. Robust error handling and failover mechanisms, similar to those required for gNBs, must be designed to ensure resilience. These strategies may be applied if the off-path node becomes unavailable for any reason. Since the off-path node is not responsible for the original data path, the potential for bottlenecks is reduced.¶
One final drawback of this approach is that it explicitly requires the periodic rediscovery of Information Server to accommodate client mobility. In the on-path approach this may be handled implicitly by the gNB. This adds additional overhead and may impact scalability.¶
This document has no actions for IANA.¶
The collection, distribution of MoWIE information should consider the security requirements on information privacy and information integration protection and authentication in both sides. Since the network status is not directly related to any special user, there is currently no any privacy issue. But the information transmitted to the application can pass through a lot of middle box and can be changed by the man in the middle. To protect the network information, an end to end encryption and integration is needed. Also, the network needs to authenticate the information exposure provided to right applications. These security requirements can be implemented by the TLS and other security mechanisms.¶
The authors would like to thank Huang Wei and Mohamed Boucadair for their contribution and technical review comments to the previous versions of this draft.¶