Umeda-san,
Please, see below.
-Glen
From: Daisuke Umeda [mailto:umeda@xxxxxxxxx]
Sent: Thursday, May 10, 2018 5:14 PM
To: Glen Kramer <glen.kramer@xxxxxxxxxxxx>; STDS-802-3-NGEPON@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_NGEPON] Call for agenda - 802.3ca (100G-EPON) consensus building meeting
Dear Glen-san,
Thank you for the proposal. Let me confirm.
I think the Discovery GATE should carry just two additional parameters:
1) ONU_RSSI_Min
2) ONU_RSSI_Max
I think there's two methods A) and B) to use ONU_RSSI_Min/Max. Which do you assume?
A) We still use ONU RSSI Indication and ONU_RSSI_Min/Max are used just for the announcement of th0-th3.
B) We use ONU_RSSI_Min/Max instead of ONU RSSI Indication. We don't need ONU RSSI Indication Bits any more.
[GK: ] Method B. No ONU_RSSI_Indication. Only two 16-bit values (ONU_RSSI_Min and ONU_RSSI_Max) are sent in Discovery GATE.
In case of A), ONU checks RSSI Indication Bits and judges which th0-2 ONU_RSSI_Min/Max are. After ONU receives th0-2, ONU judges its RSSI Indication class and responds to matched DISCOVERY GATE message (RSSI Indication = RSSI class). For example,
1-a) When ONU RSSI Indication = 100,
th0 = ONU_RSSI_Max
1-b) When ONU_RSSI Indication = 101,
th0 = ONU_RSSI_Min
th1 = ONU_RSSI_Max
1-c) When ONU_RSSI Indication = 110,
th1 = ONU_RSSI_Min
th2 = ONU_RSSI_Max
1-d) When ONU_RSSI Indication = 111,
th2 = ONU_RSSI_Min
In case of B), ONU compares its RSSI and ONU_RSSI_Min/Max enough fast and responds to matched DISCOVERY GATE message (ONU_RSSI_Min <= RSSI < ONU_RSSI_Max).
[GK: ] Yes. ONU should read/measure its own RSSI even before it receives the Discovery GATE. When GATE is received, the ONU only make a simple comparison to decide to respond or not
If (ONU_RSSI_Min <= ONU_RSSI_measured < ONU_RSSI_Max)
Generate REGISTER_REQ
Else
// skip the discovery attemp
By the way, I intend to switch SOA gain by 1bit or 2bit hardware pin, then I define 1 or 3 thresholds.
[GK: ] If you have 1 threshold, the OLT sends these two types of GATEs:
Discovery GATE for High SOA Gain:
ONU_RSSI_Min = 0
_ONU_RSSI_Max_ = TH1 + ONU_Tx_typ – OLT_Tx_typ
Discovery GATE for Low SOA Gain:
_ONU_RSSI_Min_ = TH1 + ONU_Tx_typ – OLT_Tx_typ
_ONU_RSSI_Max_ = 0xFFFF (or some smaller, fixed margin)
If there are 3 thresholds, there are 4 types of GATEes:
Class 1:
ONU_RSSI_Min = 0
_ONU_RSSI_Max_ = TH1 + …
Class 2:
ONU_RSSI_Min = TH1 + …
_ONU_RSSI_Max_ = TH2 + …
Class 3:
ONU_RSSI_Min = TH2 + …
_ONU_RSSI_Max_ = TH3 + …
Class 4:
ONU_RSSI_Min = TH3 + …
_ONU_RSSI_Max_ = 0xFFFF
Regards,
Daisuke
On 2018/05/11 6:17, Glen Kramer wrote:
Umeda-san,
Thank you for staying up very late (or getting up very early) to present the slides on the call today. As I mentioned on the call, I think in the current proposal the OLT sends to the ONU too many unnecessary parameters.
OLT sends to the ONU
3x THn, OLT_Tx, and ONU_Tx25G, and the ONU is supposed to calculate its own thresholds as thn = THn + OLT_Tx - ONU_Tx25G.
Another concern is that a discovery GATE is always for a single SOA class (or single range), but in the current proposal it carries information about all the power classes all the time. It is not necessary and makes the protocol look cluttered and confusing.
I think the Discovery GATE should carry just two additional parameters:
1) ONU_RSSI_Min
2) ONU_RSSI_Max
Different GATE MPCPDUs would specify different ONU_RSSI_Min and ONU_RSSI_Max, based on acceptable SOA range for each discovery attempt.
An ONU will participate in a discovery attempt if its own RSSI is within the range
ONU_RSSI_Min <= ONU_RSSI_measured < ONU_RSSI_Max
The OLT has all the information to calculate the ONU_RSSI_Min and ONU_RSSI_Max values for the Discovery GATE.
Assume that for every SOA level setting, the OLT knows OLT_RSSI_Min and OLT_RSSI_Max that are acceptable for this SOA level (you called these parameters THx)
OLT_RSSI = ONU_TSSI – UL
If ODN loss is not measured directly, it is estimated from the downstream loss as
UL = DL = OLT_TSSI – ONU_RSSI
So, from above we get OLT_RSSI = ONU_TSSI – OLT_TSSI + ONU_RSSI
Solving for ONU_RSSI, we get
_ONU_RSSI_ = OLT_RSSI + ONU_TSSI – OLT_TSSI
As you suggested in your presentation, instead of OLT_TSSI and ONU_TSSI, we can use typical transmit power levels
_ONU_RSSI_ = OLT_RSSI + ONU_Tx_typ – OLT_Tx_typ
If OLT intends to do the discovery for SOA gain class X, it knows its Rx power range for this gain level:
OLT_RSSI_Min_x and OLT_RSSI_Max_x
Then, in the GATE message it announces these values:
_ONU_RSSI_Min_x_ = OLT_RSSI_Min_x + ONU_Tx_typ – OLT_Tx_typ
_ONU_RSSI_Max_x_ = OLT_RSSI_Max_x + ONU_Tx_typ – OLT_Tx_typ
Even if UL and DL are different and the difference is known, still the OLT can add the correction factor to the same calculation.
Thank you,
-Glen
From: Daisuke Umeda [mailto:umeda@xxxxxxxxx]
Sent: Wednesday, May 09, 2018 10:53 PM
To: STDS-802-3-NGEPON@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_NGEPON] Call for agenda - 802.3ca (100G-EPON) consensus building meeting
Dear all:
I upload my updated materials. As there's file size limitation, I upload them separately.
Regards,
Daisuke
On 2018/05/10 14:42, Daisuke Umeda wrote:Dear Dekun-san,
Thank you for your comment. I added the unit. Also, I added the equation of "thx_10G = THx * OLT_Tx / ONU_Tx10G" on slide 10 and 11 to avoid confusion.
About umeda_3ca_2, conventional APD is III-V, not III-IV.
I updated both of them.
Regards,
Daisuke
On 2018/05/10 11:50, Liudekun wrote:Dear Umeda:
I just have one comments on Umeda_3ca_1
In page 10, all the power are announced with the linear unit “mW”; In page 6, the “example” of power are in unit “dBm”.
The current threshold calculation formulas must be based on logarithm unit “dBm”, otherwise, the “+” and “-“ operators should be “*” and “/”, respectively .
Such as thx_10G = THx * OLT_Tx / ONU_Tx10G, if all the unit are in “mW”.
I think here needs a clear statement on unit to avoid confusing.
Best regards
Dekun Liu
____________________________________________________
Advanced Access Technologies Dept. 网络研究接入技术部
Huawei Technologies Co., Ltd. 华为技术有限公司
Email: liudekun@xxxxxxxxxx武汉东湖高新技术开发区九峰三路207号A2栋邮编：430074
Huawei Technologies Co., Ltd.A2 Block, 207 Jiufeng Third Road, East Lake High-Tech Development Zone, Wuhan, China
From: Daisuke Umeda [mailto:umeda@xxxxxxxxx]
Sent: Thursday, May 10, 2018 5:31 AM
To: STDS-802-3-NGEPON@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_NGEPON] Call for agenda - 802.3ca (100G-EPON) consensus building meeting
Dear Curtis-san,
I'd like to present the attached contributions this Thursday meeting.
Regards,
DaisukeDear Colleagues,
We have an 802.3ca consensus-building meeting this Thursday, May 10, 11:30 am MST. Please let me know by 5:00 pm MST Wednesday if you have any contributions for this meeting.
Curtis
--Daisuke UmedaSumitomo Electric Industries, Ltd.1-1-3, Shimaya, Konohana-ku, Osaka 554-0024, JapanTo unsubscribe from the STDS-802-3-NGEPON list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGEPON&A=1
--Daisuke UmedaSumitomo Electric Industries, Ltd.1-1-3, Shimaya, Konohana-ku, Osaka 554-0024, Japan
--Daisuke UmedaSumitomo Electric Industries, Ltd.1-1-3, Shimaya, Konohana-ku, Osaka 554-0024, JapanTo unsubscribe from the STDS-802-3-NGEPON list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGEPON&A=1
--
Daisuke Umeda
Sumitomo Electric Industries, Ltd.
1-1-3, Shimaya, Konohana-ku, Osaka 554-0024, Japan
To unsubscribe from the STDS-802-3-NGEPON list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGEPON&A=1