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
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
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
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
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.
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
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.
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
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.
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
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.