Re: [alto] ALTO recharter to support cellular network use cases(Internet mail)

[Li Gang <[e-mail]>]

Hi, Yunfei, please see inline for some of my reply.

 

From: yanniszhang(张云飞) [mailto:[e-mail]] 
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:  <mailto:[e-mail]> Li Gang

Date: 2020-10-29 18:02

To:  <mailto:[e-mail]> chunshxiong(熊春山);  <mailto:[e-mail]> 'Y. Richard Yang';  <mailto:[e-mail]> 'IETF ALTO'

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.

 

Best Regards,

 

Li Gang

China Mobile

 

From: alto [mailto:[e-mail]] 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 <[e-mail]> On Behalf Of Y. Richard Yang
Sent: Wednesday, September 2, 2020 11:56 PM
To: IETF ALTO <[e-mail]>
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.