Re: [STDS-802-16] [802.16p][DEV-RG] - Email Discussion on M2Mdevice iden

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

Although we postponed our decision on the addressing space for the active devices, I believe the group still agrees that 16p shall support “larger number of devices”, no matter these devices are in active mode or idle mode. Regarding to the item 3 in CC-2 minute, I think we definitely need some proposed text in AWD to address the requirements in SRD.

Regarding to the shared-STID scheme, please allow me emphasizing again the benefits: By letting multiple M2M devices share the same STID, we are able to increase the capacity of M2M devices in active mode, while having no impact to the original human devices, and bringing only minor changes to the existing standard. No matter we decide to enlarge the current addressing space or not, employing this scheme always has the benefit to further increase the capacity. Therefore, I would like to ask members if we can agree on the high-level text regarding to the concept, and then develop the detailed procedures in future stages. The following is the high-level text I suggest. Please kindly share your thoughts about it.

-------------------------------------Text Begins----------------------------------

16.2.1 Addressing

Multiple M2M devices are allowed to share the same STID. The sharing scheme is FFS.

In case that a STID is shared by multiple M2M devices, these M2M devices shall be coordinated so that each device can obtain its own unique transport FIDs.

---------------------------------------Text Ends------------------------------------

2011/2/16 Vladimir Yanover <vladimir.yanover@alvarion.com>

I second this request

Thanks

Vladimir

From: Nader Zein [mailto:Nader.Zein@EU.NEC.COM]
Sent: Wednesday, February 16, 2011 2:12 AM

To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] [802.16p][DEV-RG] - Email Discussion on M2Mdevice identification

Guys according to my manually entered event in my calendar, there should be a conference call for M2M DEV starting midnight my local time.

I could not locate the bridge details.

Please send calendar event so we do not confuse time or loose bridge detail for the call.

Kindest regards

Nader

From: Andreas Maeder [mailto:Andreas.Maeder@NECLAB.EU]
Sent: 15 February 2011 15:32
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] [802.16p][DEV-RG] - Email Discussion on M2M device identification

Dear All,

I agree with Eldad’s view here. There are many scenarios of machine-to-machine communication thinkable, some of them are not yet so clear due to emerging technologies in other areas. Let us not restrict the capabilities of 16p just to meet the requirements of one specific scenario which relies on the assumption that some still not completely defined concentrators are deployed.

Best regards,

Andreas

--

Dr. Andreas Mäder

Research Scientist

Network Research Division

Mobile and Wireless Networks

NEC Laboratories Europe

Tel.: +49 6221/4342204

E-Mail: andreas.maeder@neclab.eu

From: Zeira, Eldad [mailto:Eldad.Zeira@INTERDIGITAL.COM]
Sent: Tuesday, February 15, 2011 3:58 PM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] [802.16p][DEV-RG] - Email Discussion on M2M device identification

Dear All,

While there is no doubt that concentrators reduce the number of ranging attempts I’m not sure that the 3GPP contribution you have referenced should be used as an example.

Meter reading exists today (majority of US households) using various technologies. Meter reading is only a small part of the “next generation” of Smart Grid applications which include messaging, through a concentrator, to individual household power consumers (for example electrical car chargers).

I would therefore view the numbers in that contribution as a lower bound.

Eldad

Office   +1 631 622 4134

Mobile +1 631 428 4052

Based in NY area

From: zhengyanxiu [mailto:zhengyanxiu@ITRI.ORG.TW]
Sent: Monday, February 14, 2011 10:11 PM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] [802.16p][DEV-RG] - Email Discussion on M2M device identification

Dear Ramprasad,

You can refer the link provided by Yi-Ting as shown below. Some evaluations for smart grid are shown and Concentrator is used in these exemplary deployment.

<http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_70/Docs/R2-103269.zip>

I guess that concentrator is not preferable but every system has its limitation.

I also surveyed solutions from Grid-net. The solutions include LTE, Ethernet, FTTH, 3G HSPA, 3G EV-DO, 4G WiMAX, ZigBee, HomePlug. If possible, may you give some comments on the contribution? Thanks for your further information.

Best regards,

Zheng Yan-Xiu

From: Ramprasad Golla [mailto:rgolla@grid-net.com]
Sent: Tuesday, February 15, 2011 6:14 AM
To: 鄭延修; STDS-802-16@LISTSERV.IEEE.ORG
Subject: RE: [STDS-802-16] [802.16p][DEV-RG] - Email Discussion on M2M device identification

Hi,

Without reading the document, general concern is that adding concentrators adds to the deployment and operational costs. From a system perspective, when we introduce another node and link in the network, we also need to address the security and key management issues etc.

Is it possible to share the contribution on this thread or provide a pointer?

Thanks,

Ram

From: zhengyanxiu [mailto:zhengyanxiu@ITRI.ORG.TW]
Sent: Friday, February 11, 2011 2:55 AM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] [802.16p][DEV-RG] - Email Discussion on M2M device identification

Dear Yi-Ting,

Thanks for your information. I read the document and find that concentrator would reduce the necessary number of ID for M2M device/concentrator within a cell. I believe concentrator is an important feature highlighted in your contribution submitted to LTE. I make some calculation based on your number, it also implies that up to 5000 M2M device/concentrator necessary to be handled within 2Km range. It’s good news. I guess smart meter does not send message every 5 mins but longer. I could be one day or one month. Even for one day, I guess partition 24hours=1440 mins into 1000 slots for these 5000 M2M device/concentrator is still possible and regulate the traffic. These concentrator does not have to be in connected state and wastes their power. STID could be released earlier if concentrator approach is used for smart meter scenario. I think your concentrator is practical to reduce necessary number of ID.

However, there may be some scenarios without concentrator. We could think about that scenario if current space of STID can not support.

Another point for C-RNTI and LTE. Although it is 16bits long, it will be shared for other purposes and not all 16 bits for C-RNTI. In LTE, there are some over-designs induced system overhead and complexity. We should be careful of LTE’s scenario if such scenario is reasonable.

Best regards,

Zheng Yan-Xiu

From: 林奕廷 (Lin, Yi-Ting) [mailto:eating@NMI.III.ORG.TW]
Sent: Friday, February 11, 2011 5:02 PM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] [802.16p][DEV-RG] - Email Discussion on M2M device identification

Dear Bin,

Thanks for your reply. The referenced proposal was adopted during 3GPP RAN2 #70 without objection. Please note that the C-RNTI(which is similar to STID in 16m) is 16-bit long, it is preferable to keep the capacity of 802.16p standard comparable to that of LTE MTC.

Best Regards,

Yi-Ting

From: Bin Chen

Sent: Friday, February 11, 2011 3:56 PM

To: STDS-802-16@LISTSERV.IEEE.ORG

Subject: Re: [STDS-802-16] [802.16p][DEV-RG] - Email Discussion on M2M device identification

Hi, Yi Ting,

Thanks for your sharing.

I agree with you on the SRD text.

May I ask a question that whether 3GPP standard group adopt your proposal about 30000 devices a cell? How did they think about it?

I think that may be a reference for us.

BR/Bin

From: 林奕廷 (Lin, Yi-Ting) [mailto:eating@NMI.III.ORG.TW]
Sent: 2011年2月11日 0:11
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] [802.16p][DEV-RG] - Email Discussion on M2M device identification

Dear Hyunjeong and all,

Thanks for your question. Yes, I think 16p system should support 30000 M2M devices in connected state.

In SRD 6.2.9, it says "The 802.16p system shall support large numbers of M2M devices in connected state as well as in idle state." Unfortunately, it is not clear how "large" should be. We provide the value of 30000 by our experience. I also agree with you that 1000 devices could be burden for 16m/16e base station, but I don't agree 1000 is "large".

I believe this discussion is to seek consensus on the number of connected devices. If people think 30000 is too large, I appreciate they could provide their suggestions.



Best Regards,

Yi-Ting

From: Hyunjeong Kang

Sent: Friday, February 11, 2011 1:27 PM

To: '林奕廷 (Lin, Yi-Ting)' ; STDS-802-16@LISTSERV.IEEE.ORG

Subject: RE: [STDS-802-16] [802.16p][DEV-RG] - Email Discussion on M2M device identification

Dear Yi-Ting and all,

Yi-Ting,

Thank you for your information.

I have a question based on Yi-Ting’s information.

I understand there are more than 30,000 M2M devices in a cell, but I wonder it is feasible to assume that 30,000 M2M devices are in connected state. Because we are discussing the addressing space to be used in connected state.

Do you think that 30,000 M2M devices stay in communication mode with a base station?

In my thought, it is too burden for a base station to manage more than 1,000 devices in connected state.

Regards,

Hyunjeong

From: 林奕廷 (Lin, Yi-Ting) [mailto:eating@NMI.III.ORG.TW]
Sent: Friday, February 11, 2011 1:38 PM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] [802.16p][DEV-RG] - Email Discussion on M2M device identification

Dear all,

Thanks for Chiwoo's analyses. We agree that, with current 16m feedback channel design, the maximum number of devices would be 12032.

We would like to share our experiences on smart meters in Taipei. Please refer to the file <http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_70/Docs/R2-103269.zip> for reference. For a cell of 1 km radius, the number of smart meters could be more than 30000. In practice it is not likely all smart meters attach to the network at the same time. But, considering various M2M applications would run simultaneously in a cell, we think the value of 30000 is reasonable to be the baseline number of supported devices.

Best Regards,

Yi-Ting

From: Lim Chiwoo

Sent: Friday, February 11, 2011 10:08 AM

To: STDS-802-16@LISTSERV.IEEE.ORG

Subject: Re: [STDS-802-16] [802.16p][DEV-RG] - Email Discussion on M2M device identification

Dear 16p members,

As Kaushik pointed, we couldn’t agree on how many devices we need to support or how many devices we can currently support.

According to addressing issue, it’s required to determine this first.

I want to show my calculations about current feedback capacities of 16m and 16e.

I think that the size of STID doesn’t need to largely exceed the capacity of feedback channel because operation is not guaranteed if there is no relevant feedback.

The results show that the number of supportable user based on feedback channel are 7168/12032/200 in cases of 16m(10MHz)/16m(20MHz)/16e(10MHz), respectively.

I think that we can consider these results when we determine the number of devices to be supported in M2M.

Please let me know your opinion.

Please see following calculations.

Basic conditions

-       DL:UL = 5:3

-       One feedback channel makes 6 HARQ feedback channels.

-       Maximum number of LRUs for feedback channel : 16 (4 bits indication)

-       Maximum number of HARQ feedback channel is 30/60 for 10/20MHz, respectively.

-       Let’s consider maximum HARQ feedback channel.

-       The report period of fast feedback channel is up to 128 frames (=640ms, 3 bits indication)

-

<10MHz case, 16m>

There is a restriction of number of feedback channel. The MAX number is 27. (per one subframe)

5 feedback channels are used for HARQ feedback channels. (per one DL subframe (one HARQ feedback region))

There are 81 (= 27 * 3) feedback channels per one frame.

25 (=5*5) feedback channels are used for HARQ feedback channel.

That is, there are 56 fast feedback channels in a frame.

When we consider the report period as 8/32/128 frames, the number of supportable user are 448/1792/7168.

<20MHz case, 16m>

There are 48 feedback channels. (per one subframe)

10 feedback channels are used for HARQ feedback channels. (per one DL subframe (one HARQ feedback region))

There are 144 (= 48 * 3) feedback channels per one frame.

50 (=10*5) feedback channels are used for HARQ feedback channel.

That is, there are 94 fast feedback channels in a frame.

When we consider the report period as 8/32/128 frames, the number of supportable user are 752/3008/12032.

<10MHz case, 16e>

In 16e, the report period of CQICH channel is up to 8 frames (= 40ms, 2bits indication)

There are 35 subchannels per one frame in 10MHz.

6 subchannel shall be used as ranging channel.

Therefore, if we assume 25 subchannels for CQICH and 4 subchannels for ACK/NAK, the number of supportable user is just 200.

BR,

Chiwoo

From: Kaushik Josiam [mailto:kjosiam@STA.SAMSUNG.COM]
Sent: Thursday, February 10, 2011 5:28 AM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: [STDS-802-16] [802.16p][DEV-RG] - Email Discussion on M2M device identification

Dear 16p members

In the DEV RG conference call today, we wanted to hear the member’s view on how many devices we need to support in 802.16p systems. We can increase the addressing space to support a large number of users, but in the conference call, we couldn’t agree on how many devices we need to support or how many devices we can currently support.

Related to this issue, do we need to define a new M2M specific IDs for M2M devices?

If you have any thoughts or proposals on the issue, please share them as a reply to this thread.

We thank you for your cooperation.

Regards

Kaushik & Ming-Hung

DEV RG Chairs

本信件可能包含工研院機密資訊，非指定之收件者，請勿使用或揭露本信件內容，並請銷毀此信件。
This email may contain confidential information. Please do not use or disclose it in any way and delete it if you are not the intended recipient.

本信件可能包含工研院機密資訊，非指定之收件者，請勿使用或揭露本信件內容，並請銷毀此信件。
This email may contain confidential information. Please do not use or disclose it in any way and delete it if you are not the intended recipient.

Click here to report this email as spam.

************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses(190).
************************************************************************************

************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses(42).
************************************************************************************

************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses(42).
************************************************************************************