Hello Qin, Please check my inline clarification for your questions. Since there is an online 3GPP standard meeting in the last week, my response is some late.
BRs, Chunshan Xiong From: Qin Wu <[email protected]> Sent: Monday, November 16, 2020 9:21 PM To: chunshxiong(熊春山) <[email protected]>; alto <[email protected]> Subject: RE: [alto] ALTO recharter: proposed item - Extends the ALTO Service to provide cellular network Information(Internet mail) Hi, Chunshan: Thanks for proposed item update, the proposal get polished much better. thanks for your good clarification. I have a few follow up questions below. 发件人: alto [mailto:[email protected]] 代表 chunshxiong(熊春山) 发送时间: 2020年11月11日 17:13 收件人: alto <[email protected]<mailto:[email protected]>> 主题: [alto] ALTO recharter: proposed item - Extends the ALTO Service to provide cellular network Information 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. [Qin]: I am wondering how these cellular network information fit into network map, cost map, property map or simply endpoint property, endpoint cost service? [Chunshan] One of key characteristics of cellular network information is the freshness. Unlike the traditional ALTO network information which is much more static for a long time, the cellular network information is changed very quickly , e.g. for millisecond level to second level. In such case, maybe the traditional ALTO network information is not suitable for the cellular network information. Also I see a lot of relevant work which have been proposed by Sabine in the past such as: https://tools.ietf.org/html/draft-randriamasy-alto-cost-context-01 which also deal with cellular network, specify various different context parameter, access technology type, https://tools.ietf.org/id/draft-randriamasy-alto-mobile-core-01.txt which specify 3GPP Cost Map and provide 3GPP User Identification and location https://tools.ietf.org/id/draft-randriamasy-alto-cellular-adresses-03.txt which introduce a new endpoint property https://tools.ietf.org/id draft-bertz-alto-mobilitynets It will be great to put them together to take a look at. [Chunshan] Yes, all these contributions are good start point for the cellular network information, and all these works needs to be consider as a whole output. 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. [Qin]: I am wondering how section 4.15 of ETSI TS 123 502 is related to cellular information retrieval from NEF which specify mobile events and various capabilities https://www.etsi.org/deliver/etsi_ts/123500_123599/123502/15.02.00_60/ts_123502v150200p.pdf Is cellular information additional information to mobile events and various capabilities exposed by NEF? [Chunshan] Yes, the NEF is the egress port to exposure the cellular network information. But the current specification only defines the capability on how to provide the cellular network information to the outside world, but it does not define which cellular network information to be provided. +++ 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 [Qin]: I think all of these are cost metric information which are part of cost map, is there any endpoint property information? E.g, from UE to Cell, or from cell to another cell? [Chunshan] Just said in the previous part, One of key characteristics of cellular network information is the freshness. Unlike the traditional ALTO network information which is much more static for a long time, the cellular network information is changed very quickly ,we can reuse some cost map, but we need to add freshness information to limit the time of usability. Normally, the 5G network does not explicitly provide such endpoint information, but from the ALTO Server can construct such endpoint information, and normally such information can be UE to cellular or UE to the IP Anchor point (i.e. UE to UPF ,since the UPF is the IP anchor point). +++ Solution for Issue 4: - Radio channel status: e.g. SINR, RSRP/RSRQ, CQI, MCS - L2 user plane measurements: e.g. thoughtputthroughput, latency [Qin]: Again, it is not clear whether it is end to end QoS network performance from source to destination or network performance from one edge to another edge? From UE to Cell or from UE to the Edge? [Chunshan] 5G network normally can provide UE to cellular or UE to IP anchor QoS related information. But the ALTO Server can built the UE to UE, UE to Application server QoS Information based on the collected information. i.e. ALTO Server for cellular network information not just collects cellular network information , it needs to perform some further calculation to get more “deeper” information based on multiple source network information. Maybe this is the most challenge for the ALTO Server, which is not standardized in the ALTO WG (in my understanding) - 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. [Qin]: Can you confirmation whether those information contain Radio channel status or L2 user plane measurement information. [Chunshan] Yes, from the IETF draft paper MOWIE https://datatracker.ietf.org/doc/draft-huang-alto-mowie-for-network-aware-app/ , we have used some L2 UP measurement information. But the challenge is 3GPP does not explicitly define how to L2 user plane exposure these information. i.e. if 3GPP does not explicitly defined how to exposure these L2 UP information, some production will not support it. If we need these L2 UP information, we need ask 3GPP to explicitly defined it. 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. [Qin]: Good point. +++ 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. [Qin]: It is not clear to me whether NEF is designed to collect cellular network information? Is cellular network information related to mobile events? [Chunshan] Please to check the previous clarification. NEF can exposure any information if it is standardized in 3GPP. The problem is for any cellular network information, if it is not standardized, the real network node may do not provide such cellular network information. So the key problem, standardization is the important. 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]<mailto:[email protected]>> Sent: Saturday, October 31, 2020 1:49 PM To: ligangyf <[email protected]<mailto:[email protected]>>; chunshxiong(熊春山) <[email protected]<mailto:[email protected]>>; yry <[email protected]<mailto:[email protected]>>; alto <[email protected]<mailto:[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
