| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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 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. |