| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
I think the use of feedback should
correspond to the application. In some cases it is sufficient
that most devices will receive the message successfully. While it is
true that any desired reliability can be achieved with sufficient repetition, the
number of repetitions cannot be known to the network without cell mapping, etc.
The lack of such information will force many more transmissions than necessary.
The number of such transmissions depends on the desired reliability which for
some m2m applications (e.g. Smart Grid) is expected to be very high. An example for such application in
Smart Grid is sending of price point information to residences which then use
it to change their consumption profiles according to owners’ preferences. In other cases it is important
that all devices receive the message (e.g. in command and control of electrical
distribution). For these it is important that the success is known to the BS. Sorry for using Smart Grid examples,
this is the m2m application with which I’m most familiar. I suspect that other applications
will have similar. Eldad Office +1 631 622 4134 Mobile +1 631 428 4052 Based in NY area From: Kaushik Josiam
[mailto:kjosiam@STA.SAMSUNG.COM] This is exactly the kind of discussion we need. Thank you all
for your thoughts. There are different architectures to support the kind of M2M growth
that people are talking about. We don’t need to make everything cellular
centric and in particular layer-1/layer-2 centric. If we are to increase the size, then I agree with Chiwoo’s point
that we are limited by what we can currently support in terms of the feedback
channel. We cannot look at addressing in isolation since the
support for maintaining the connection and data transfer come from what the ABS
knows about the connected M2M device. Regards Kaushik From: Bin Chen [mailto:binchen@HUAWEI.COM] Thanks. I agree
with Yi-Ting on this. Regarding Chiwoo’s calculation M2M number according to
feedback capability, I think there is a concern. Even if
the feedback capability limit the max feedback MSs to 10 thousand, I think it
is limit the number of MSs feedbacking simultaneously, but not connecting MSs. It is
not necessary that all the connecting MSs feedback at the same time. BR/Bin From: 林奕廷 (Lin, Yi-Ting)
[mailto:eating@NMI.III.ORG.TW] Dear
all, Thanks
for Yan-Xiu and Brian's comments on the number of smart meters/concentrators, I
am fine with that. Please note that the point is the number of M2M devices, not
only smart meters, in a cell. Although smart meter is one of the most
promised applications in M2M, I believe 16p is not targeted to smart meter
application only. 16p acknowledges 9 categories of applications in
the technical report <802.16p-10/0005>. We have to think about the
scenario where a mixture of these applications run simultaneously.
Optimization
is preferable, and over-design is what we should prevent as far as
possible, but the line is rather rough. M2M market is expected to growth
explosively in the next 10 years. Hardware capacity might be improved as
well. My concern is, if 16p's capacity is far lower than its
competitors, 16p will fall behind others at the very beginning.
Best
Regards, Yi-Ting From: zhengyanxiu Sent: Friday, February 11, 2011 6:55 PM 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] 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 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] 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 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] 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 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] 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 本信件可能包含工研院機密資訊，非指定之收件者，請勿使用或揭露本信件內容，並請銷毀此信件。 |