Hello all,
I and Li Gang(China Mobile) reconstruct the WG item proposal for “Extends the
ALTO Service to provide cellular network Information” based on the previous
email and discussion during the weekly meetings.
Welcome your comments.
BRs,
Chunshan Xiong
**** Context：Extends the ALTO Service to provide cellular network Information
- Currently ALTO Information Services does not support cellular net.
1. Problem description
+++ Issue 1: Whether it is feasible to obtain the cellular information?
+++ Issue 2: How does ALTO server obtain cellular information from 5G NEF?
+++ Issue 3：What cellular information is from ALTO server to ALTO client?
+++ Issue 4：What cellular information is exposed from 5G network to ALTO server?
2. Potential solutions and considerations
+++ Solution for Issue 1
- It is feasible to obtain the cellular information from NEF
- Reuse the CAPIF defined in 3GPP
- Leverage the release-17 Edge computing Enhance to provide cellular
network information wih low-latency.
+++ Solution for Issue 2:
- For OB solution, it is proposed that the ALTO server reuses current
standard to obtain the cellular information via NEF northbound interface.
- For IB, it is proposed to investigate the potential solution and
leverage the existing standardization outputs.
+++ Solution for Issue 3:
- Measurement information: bandwidth, latency, jitter
- Predicted information: available bandwidth for next a few seconds
+++ Solution for Issue 4:
- Radio channel status: e.g. SINR, RSRP/RSRQ, CQI, MCS
- L2 user plane measurements: e.g. thoughtputthroughput, latency
- In addition, different levels can also be considered, i.e. flow, UE,
slice, serving cell and neighboring cell. For those information defined but not
exposed from 5G network, we can send LS to 3GPP to ask for such information
exposure.
3. Remaining issues to be addressed
+++ Security/sensitivity of info
- It is not sensitive for OB solution and
- for future study for IB.
- For OB+IB solution defined in 3GPP EC in Rel-17, it is treated as
OB solution for IETF ALTO.
+++ Given 3GPP/layer 2 SDO are defining this interface/service, why do we need
ALTO to do it as well? Why Internet standard, and 3GPP standards are not enough?
- 3GPP NEF provides low layer information, which is hard for application
usage directly.
- ALTO server can aggregate such original cellular information, and have
capability and possibility to process that information and provide it to
applications (ALTO client) with more easy to use via a single interface.
+++ Is the info really useful?
- The results from IETF MOWIE draft paper can prove the benefit of
utilizing such cellular information. -
+++ Are the providers willing to provide the info?
- It depends on business model. On one hand, operators can increase
revenue by charging from OTT vendors. On the other hand, it is helpful to
improve user QoE and increase user loyalty.
+++ Is the info from a single device or a set of devices, where the devices
involved can span multiple autonomous domains, multiple wireless links may get
involved? What does mean for this context?
- For local breakout scenario, the NEF and radio network are within the
same operator, no problem to get information.
- For home domain routed scenario, the NEF and radio network belongs to
different operators, but since the home routed traffic, there is a roaming
agreement for multiple domains and NEF can provide some celluar network
information.
4. Who will work on it?
- China Mobile, Tencent and Welcome more.
5. Rough Planning and outputs
- Mar 2021 Problem Description on support cellular network
- Nov 2021 Extend ALTO Information Service with Cellular
network information and its information freshness
- 2022 Best Practice to provide deployment guideline
for network information exposure
From: yanniszhang(张云飞) <[email protected]>
Sent: Saturday, October 31, 2020 1:49 PM
To: ligangyf <[email protected]>; chunshxiong(熊春山)
<[email protected]>; yry <[email protected]>; alto <[email protected]>
Subject: Re: RE: [alto] ALTO recharter to support cellular network use
cases(Internet mail)
Hi Ligang,
Please see inline for the reply.
BR
Yunfei
________________________________
yanniszhang(张云飞)
From: Li Gang<mailto:[email protected]>
Date: 2020-10-30 16:58
To: yanniszhang(张云飞)<mailto:[email protected]>;
chunshxiong(熊春山)<mailto:[email protected]>;
'yry'<mailto:[email protected]>; 'alto'<mailto:[email protected]>
Subject: RE: Re: [alto] ALTO recharter to support cellular network use
cases(Internet mail)
Hi, Yunfei, please see inline for some of my reply.
From: yanniszhang(张云飞) [mailto:[email protected]]
Sent: Thursday, October 29, 2020 9:50 PM
To: ligangyf; chunshxiong(熊春山); yry; alto
Subject: Re: Re: [alto] ALTO recharter to support cellular network use
cases(Internet mail)
Hi Ligang,
Please see inline for the reply. Thanks.
BR
Yunfei
________________________________
yanniszhang(张云飞)
From: Li Gang<mailto:[email protected]>
Date: 2020-10-29 18:02
To: chunshxiong(熊春山)<mailto:[email protected]>; 'Y. Richard
Yang'<mailto:[email protected]>; 'IETF ALTO'<mailto:[email protected]>
Subject: Re: [alto] ALTO recharter to support cellular network use
cases(Internet mail)
Dear ALTOers,
Thank Chuanshan for your triggering discussion on cellular network information
exposure via ALTO. Here are some of my thoughts.
1) It is beneficial to investigate cellular information exposure to
improve especially cloud interactive applications. I think the following
categories of cellular information can be considered, for example, radio
channel status, L2 user plane measurements. In addition, different levels can
also be considered, i.e. UE, slice, serving cell and neighboring cell. There
are a number of specifications in 3GPP to define the specific meaning of each
parameter and we don’t have to spend too much effort to define each of them.
[Yunfei] Agree. We don't need to define them while we need to summarize these
parameters (group) that matters for ALTO.
2) NEF, indeed, is a good interface for ALTO server to obtain cellular
information. And for ALTO WG we don’t have to dive too much in how those
information is conveyed within 3GPP network. In addition, the NEF deployment is
quite flexible and can collocate with UPF and MEC, which enable low latency
transmission.
[Yunfei] Not very sure if current NEF can support very quick interaction bw
network and application, even it's located in MEC. It doesn't work when the
frequency of the parameters NEF exposes is quite low even if its transmission
latency is low. Can you elabrate the degree BCP NEF can support? We may need to
extend the requirement of NEF in 3GPP if necessary.
[LiGang] I agree that we need to evaluate if the current flow&depolyment can
satisfy the performance requirement of frequent cellular info exposure.
Actually there is no direct interface between UPF and NEF, and the flow has to
go through RAN->UPF->SMF->NEF, which is quite lengthy. Some extension may be
needed in 3GPP. Or even more drastically, in-band related solution might be
considered.
[Yunfei] Excatly I agree your comments on NEF in 3GPP.
Best Regards,
Li Gang
China Mobile
From: alto [mailto:[email protected]] On Behalf Of chunshxiong(熊春山)
Sent: Wednesday, October 28, 2020 5:43 PM
To: Y. Richard Yang; IETF ALTO
Subject: [alto] ALTO recharter to support cellular network use cases
Hello All,
Now 3G/4G/5G becomes the infrastructure of a country. Business, education and
entertainment are using the cellular network to provide seamless access.
To help the applications (e.g. in the cloud) to provide good QoE to the end
user, the application in the cloud needs to get the cellular network
information, e.g. the available bitrate , the current latency in the cellular
network, to adaptively change its bitrate or the video resolution.
Here, based on the above assumption, I identify the following new directions
for ALTO re-charter:
1) propose to include cellular network information to be provided to the
ALTO Server, then the ALTO server can further to provide the cellular network
information to the ALTO client.
2) Define the cellular Network information with validity time .
Because the dynamic characteristics of the radio link, the information provided
by the cellular network is almost always fresh and changing. So it is proposed
that the freshness of the cellular network information provided is associated
with a validity time, before the validity time expires, the cellular network
information is fresh and can be trusted used, after validity time expires, the
cellular network information is outdated and cannot be trusted used.
One question is which network function sets the validity time for the cellular
network information ? In my understanding, it is the 3G/4G/5G network nodes who
provides such cellular network information will set the validity time.
3) Define how the cellular network information is provided to the ALTO
server
In 4G , SCEF-based network information exposure architecture is defined.
In 5G, NEF-based network information exposure architecture is defined.
These SCEF and NEF based network information exposure architecture can provide
some information to the 3rd party via the Restful based API. The information
provided by these two interface are normally events (e.g. UE’s connect
available, or UE enters a defined area) which happens at current time. These
real time events are very helpful some applications but it is still very
limited for a lot of cloud-based applications.
Also 3GPP has defined CAPIF to help application to discovery and use the API
provided by the 3GPP 3/4/5G.
So it is proposed that the ALTO Server still uses the open NEF-based
interface to get cellular network information.
4) Define how the ALTO Server get the fresh cellular network information
The NEF provided real-time events are valid on from the time of the exposure
to 3rd party because the event normally is a status, if the status is changed,
a new event is provided. In such case, the event is valid always.
But the bitrate of radio link and the current latency in the 5G system are
provided with detailed a value and not a status, in such case, a validity time
is needed to define how long such value is usable as defined in 1).
In the 5G, the NET gets the network information from other network functions
via the control plane. But these fresh cellular network information are changed
frequently, this will introduce too much control plane signaling in the 5G. A
reliable and efficient way for the NEF to get such fresh network information is
needed in the 5G system.
3GPP 5G release-17 has defined a SID on EC enhancement to support cellular
network information to the EC application server with low-latency. Now, 3GPP
has agreed (but still does not make final decision) that the network
information collection and exposure via combined IB and OB mechanism ( e.g. IB
information signaling from radio network to the UPF via the user plane GTP-U
header (this technology has been defined in release 16) and the UPF forwards
such network information to the local NEF via a new control plane interface (
assumed to be defined in 3GPP release-17 Edge computing to support low latency
information exposure). It is assumed that there is an interface between local
NEF and central NEF, in such case, the local NEF also can request (non latency
sensitive) network information from the central NEF.
Based on such Release-17 EC low-latency information exposure technologies, the
NEF can get fresh cellular network information from the user plane and from the
radio station and provides these fresh cellular network information to the ALTO
Server.
5) Define which fresh cellular network information to be defined in the
ALTO Server
This is very important question for us, at the start point, I think the bit
rate and communication latency are needed, new information can be defined.
And we also need to identify whether such cellular network information can be
provided by the 5G network, If we need these network information, we can send
LS to 3GPP to ask for exposure such information.
The above 5 bullets are the summary of my thinking on how to provide fresh
cellular network information to the ALTO Server.
Thanks very much to a lot people (e.g. Richard, Sabine, Li Gang, Kai, …) on
the discussion during the weekly conference call.
Welcome your comments.
BRs,
Chunshan Xiong
Tencent
From: alto <[email protected]<mailto:[email protected]>> On Behalf Of
Y. Richard Yang
Sent: Wednesday, September 2, 2020 11:56 PM
To: IETF ALTO <[email protected]<mailto:[email protected]>>
Subject: [alto] Short summary of recharter discussions on 3 items(Internet mail)
Dear ALTOers,
This is a brief update on the last two meetings. One focus was the rechartering
items, and please see below for the discussion of three items. Please consider
them definitely as *work in progress*, and the goal of posting them early is to
better engage.
====
- Extension of ALTO to support cellular network use cases. The working group
will extend ALTO information services to expose to mobile clients/applications
about cellular network information, including general base station network
information (e.g., spectrum allocation status) and network information on the
links between the UE and the network (e.g., CSI). The extension should clearly
address security issues including authentication, authorization, and
confidentiality about UE and network information.
- Extension of ALTO to support east-west settings. The current ALTO framework
receives network information from a single server, but the network devices
(resources) traversed by a flow can consist of a sequence of network devices
divided into segments, whose information can be managed by a sequence of ALTO
servers. The working group will extend the ALTO framework to introduce
capabilities to identify the full path (i.e., who provides the segment
information), query the segments (e..g, identify segments of a path), and
aggregate the information (e.g., standardize single aggregation in some
settings, and more flexible aggregation such as non-dominant aggregation of
high dimension using route algebra). The working group should consider
realistic complexities such as some segments may not be identifiable, some
segments may not have ALTO servers providing information, some segments may not
provide the desired information, and dynamicity. The design should consider
security issues such as access control policies, authorization (e.g., an ALTO
server provides information for a network that the server has no authorization).
- Best practice documentation and extension of ALTO for operation automation.
Operating an ALTO server can be complex, and the automation of the operations
of the ALTO services can be highly valuable. The operations of an ALTO server
includes decisions on the set of information resources (e.g., what metrics, how
they are divided into multiple entries) exposed in the information resource
directory (IRD), population (maybe proactive and reactive) of the content of
the services (e.g., pull the backend, or trigger just-in-time measurements),
and aggregation/processing of the collected information to give clients the
proper response. The working group will investigate the best practices in ALTO
operations automation, including interop/interfaces/protocols with routing
systems and measurement tools.
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
