| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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] 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 本信件可能包含工研院機密資訊，非指定之收件者，請勿使用或揭露本信件內容，並請銷毀此信件。 |