Re: [802.3_NGEPON] Call for agenda - 802.3ca (100G-EPON) consensus build

Thread Links	Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

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,
Daisuke

Dear 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 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
-- 
Daisuke Umeda
Sumitomo Electric Industries, Ltd.
1-1-3, Shimaya, Konohana-ku, Osaka 554-0024, Japan
-- 
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

--

Daisuke Umeda

Sumitomo Electric Industries, Ltd.

1-1-3, Shimaya, Konohana-ku, Osaka 554-0024, Japan