I guess I'm matching cell radius by habit, I have no basis to believe
that it affects the frame structure.
....except if it doesn't matter then why is it there?
------ Original Message ------
From: "Nathan Anderson" <[email protected]>
To: "[email protected]" <[email protected]>
Sent: 1/2/2017 5:34:59 PM
Subject: Re: [Telrad] Uplink capacity
I should also clarify that my post was intended to be a question rather
than a statement of fact to be disputed (thus the "right?" at the end
:-)), and I appreciate all of the input.
To clarify, my impression up to this point was that no additional
guards were required for co-channels because 1) they were built into
the spec anyway and 2) the Compacts had unusually good
filtration/rejection at the channel edges, and that keeping co-located
Compacts on neighboring channels configured with the same timing
parameters had nothing to do with it. It sounds like this assumption
was in error, and that this applies down to the SSF as well?
Adam, in your initial reply, in addition to referring to "max range" at
one point when it was clear you meant SSF, you also did say that "if
you have different config, ssf, or cell radius on 3 different
co-located units..." The fact that you listed "cell radius"
immediately after "ssf" is confusing, especially since the "cell
radius" setting changes nothing about the frame structure (again,
"right?"). Can you clarify what your intent was here?
Thanks much,
-- Nathan
From:[email protected] [mailto:[email protected]] On
Behalf Of David Peterson
Sent: Monday, January 02, 2017 2:19 PM
To:[email protected]
Subject: Re: [Telrad] Uplink capacity
I agree with you on that only I would change “weird problems” with
destructive interference rendering your tower mostly unusable.
I really only meant my post as a clarification of LTE transmission
protocols….
David
From:[email protected] [mailto:[email protected]] On
Behalf Of Adam Moffett
Sent: Monday, January 2, 2017 5:13 PM
To:[email protected]
Subject: Re: [Telrad] Uplink capacity
I'm standing by answer. Just sub the words "max range" with "special
sub frames". I knew what I meant.
I'm assuming the hypothetical 5 overlapping sectors would all have GPS
on and matching timing parameters. I do believe that would work, but
the part I disagreed with was having 3 co-located units with mismatched
timing. I haven't tried it (at least not intentionally), but I'm
guessing you would have some kind of weird problems. I'm thinking it
would partially work because you're only self-interfering on a portion
of the frame and part of the channel, but some subtle weirdness would
happen.
------ Original Message ------
From: "David Peterson" <[email protected]>
To: "[email protected]" <[email protected]>
Sent: 1/2/2017 4:58:24 PM
Subject: Re: [Telrad] Uplink capacity
Keep in mind that the cell size parameter is not directly connected to
the TDD split. The subframe configuration does adjust the cell size
maximum but setting the maximum cell setting smaller in the ENB does
not change the TDD split. In all synchronized systems the
transmit/receive cycles must be exactly the same. Any deviation
causes interference enough to disrupt the ability for the system to
function properly. In a recent call I received, a customer had turned
off GPS for testing on a new sector. They were not able to achieve
network entry until we turned off the synchronized system so we could
test the non-synchronized system.
As far as co-channel interference, in a LTE/WiMax type of system each
sub-channel has a co-channel rejection of 25dB. In addition the full
channel has guard sub-channels built into the protocol. So there is
no reason to add additional guard frequencies on the Telrad product.
You should be able to provision 5 10MHz channels all facing the same
direction without self-interference. (Seems like a waste of spectrum
J)
David
From:[email protected] [mailto:[email protected]] On
Behalf Of Adam Moffett
Sent: Monday, January 2, 2017 3:30 PM
To:[email protected]
Subject: Re: [Telrad] Uplink capacity
I'm going to have to (partially) disagree there. On a given channel
size and center frequency you have the peak energy output on that
desired channel, but the unit is emitting energy on frequencies
adjacent to the desired channel. If you have different config, ssf,
or cell radius on 3 different co-located units then some of them are
transmitting during a portion of the others receive cycle. So if the
parameters don't line up and the channels are too close together then
you'll have uplink interference on one or more of them. It would only
be during a portion of the frame, so the effects might be subtle. The
one with the shorter max range would have the longer tx cycle, so I
believe the one(s) with the longer max range would see the symptoms
(whatever those symptoms are).
The statement could be true if you're using very small channels or if
you have a wider band to work with than 3650-3700. If you're using
10mhz channels then you might need to put two un-synced units on
opposite ends of the band to avoid self interference. I'm doubtful
that 3 could fit. On 5mhz or smaller, maybe.
-Adam
I want to use config 1, but we have had terrible luck with it (makes
things randomly worse).
Subframe change has to be system-wide only in cases where a CPE can
potentially hear more than one eNB on the same channel, or two eNBs
on the same channel can hear each other or are otherwise colocated
with each other, right? If you have 3 sectors each on a different
channel on top of a tower in the middle of nowhere, I'd think you
could safely choose a different config on each of them if desired.
Also, is the main subframe config the only thing that has to be
consistent, or does special sub also have to be as well? If we have
eNBs with differing cell-radius set, I would like to set the SSF to
be the optimum for that cell-radius size on an eNB by eNB basis to
eke out the best performance on each one.
-- Nathan
From:[email protected] [mailto:[email protected]] On
Behalf Of Adam Moffett
Sent: Saturday, December 31, 2016 9:31 AM
To:[email protected]
Subject: Re: [Telrad] Uplink capacity
On an eNB with 40 CPE, we've observed that we don't get more than
300-400kbps upload on a single UE....and yeah the eNB flattens out
before I think it should.
We're on a 20mhz channel, Configuration 2, SSF 2, and 2x4. We will
compare with 2x2. We might try Config 1, but since that's a system
wide change it won't be right away.
I think it's understood that you only get 16QAM upload right now, but
I was under the impression that was an issue with the CPE. I'm know
some of you have experimented with 3rd party CPE, and I'm wondering:
Do you get more upload speed with those and does 64QAM uplink works
with them?
-Adam
We are still fighting upload capacity problems on our more loaded
sectors.
To catch y'all up, we are running 15MHz channels and subframe
profile 2.
Some observations I have made:
1. Those eNBs running 6.6 seem to peak out on upload capacity at
around 85% utilization, according to BreezeView. Has anyone else
noticed this? When upload is getting hammered, the KPI graphs
flatline uplink utilization at 85% and it NEVER crosses that line.
eNBs on 6.5 will still approach 100%. Is this just a reporting bug
or what?
2. With the combination of 15MHz channels + subframe profile 2, we
seem lucky if we can ever push a total combined uplink rate of
2Mbit/s from all attached CPEs. Does this sound right to anyone?
This seems very low to me. And as I said in an earlier post, our
retransmits are below 2% and uplink MCS is staying at 20 or higher >
90% of the time. (I am currently observing the same eNB as I
referenced in that earlier post.)
Also, what are current best practices as of 6.6? With the
introduction of weak UE protection, is it advisable to turn that on
and then go back to EqualRate scheduling?
I have set this particular Compact (30 CPEs) to EqualRate on both
down and up, and activated weak UE @ level 2 with the default MCS
indexes for level 2. It's probably too early to tell, but I don't
think this is making a signficant difference.
-- Nathan
From: Nathan Anderson
Sent: Thursday, December 22, 2016 12:31 AM
To:[email protected]
Subject: RE: [Telrad] More CPE8K woes
As a follow-up to the iperf bit, there is an "accept" rule at the
top of the iptables firewall input chain on the EPC for its
*management* IP. Maybe Telrad expects you to run iperf traffic
between ENB and EPC across the management VLAN and not the main EPC
interface/bearing VLAN. You should be able to have iperf explicitly
bind to the management interface on both ends (iperf -B A.B.C.D
where A.B.C.D is the management IP for either the EPC or ENB in
question that you are invoking this on) and then on the client side
specify the other end's management IP for the -c parameter.
However, this only works if you don't have 'switching
vlan-assignment epc-access-if-list' defined on your EPC, as we do.
If you are using that for whatever reason (e.g., site-based EPC
instead of centralized, although there are other scenarios), you
cannot send management traffic directly between the EPC and ENB.
This isn't being blocked by iptables, but is something happening at
a lower level (something to do with how VLANs are being tagged and
forwarded between the various ports and the internal CPU port by the
switch chip). Telrad may have failed to consider this when adding
the iperf feature.
-- Nathan
From:[email protected] [mailto:[email protected]] On
Behalf Of Nathan Anderson
Sent: Thursday, December 22, 2016 12:14 AM
To:[email protected]
Subject: Re: [Telrad] More CPE8K woes
Is it possible to get retransmission rates for uplink? I thought
only downlink stats were available from the eNB (which makes sense,
since the eNB would have no idea how many times each CPE had to
retransmit unless the CPEs were reporting that information back to
it somehow). Are you talking about pulling figures from the CPE
somehow, or getting this information elsewhere?
On the sector I'm looking at, single retransmit blocks in the DL
direction are about 1.4% of total blocks. According to old notes I
have, 1% is supposed to be good. I don't know whether I should
worry about the extra .4%, but I'm also not sure how this relates to
uplink health (if at all).
As far as percentages go for uplink modulation, 87% of all uplink
bits were sent MCS 23, if we include MCS 20 + 23 together that rises
to 91%, and if we include 19 + 20 + 23 together, that accounts for
94%. Are those good numbers? They seem fairly good to me. (I sure
would love to see what individual CPEs are doing for modulation in
either direction at any given time...)
We have also been raising uplink AMBRs as well to help deal with
this. Which seems to help some, and which I think is weird that it
helps. For example, if I have uplink limited to 1.5Mbit/s, a radio
on this sector might be able to average 300-400kbit/s. If I change
that radio to an AMBR profile that has the uplink limit set to
10Mbit/s, then all of a sudden in the same conditions (minutes
later, after changing that UE's profile and kicking it off the EPC)
I see more like 800-1000kbit/s from the same CPE! These numbers are
the same with both iperf TCP (on the radio) or RouterOS
bandwidth-test (router behind the radio), 5 parallel streams in
either case, very repeatable (at that same time of day).
What the...? If roughly 1Mbit/s of capacity is available, and a
given UE is set to 1.5Mbit/s of upload, why can't it achieve that
1Mbit/s unless I raise it to some crazy high number first? Why does
throughput instantly double when I lift that AMBR value?
So it sounds like you are telling me that you are doing a similar
thing and just cranking those AMBR numbers way up on the EPC, but
then you are using something else (RouterOS?) to queue packets up
upstream? And you get better performance this way? I believe it
based on what we have experienced (above), but it seems to me that
this really shouldn't be the case. Shouldn't the EPC be working in
tandem with the eNB to provide the best and most efficient airtime
utilization possible?
I don't think the issue with iperf is with you. I cut my teeth on
iperf2 and even I can't get it to work right on the Compacts and
BreezeWay. From what I can tell, problems appear to be multi-fold.
BreezeWay has a "drop all TCP connections indiscriminately" rule at
the end of its iptables firewall input chain. That's the primary
problem as far as I can tell. Once that is out of the way, or an
exception is added for TCP port 5001 earlier, it works, but the
bundled iperf binary is somewhat buggy. The -r and -d options don't
work right and the device that is playing the iperf server role
fails to connect back to the other in client mode and crashes out
when it is time to run a reverse-direction test. So you have to
individually launch iperf as a server on both ends separately in
order to test both directions. I remember running into a similar
problem with the iperf2 binary packaged with some version of Ubuntu
a while back, and I had to grab the iperf sources, patch them, and
rebuild them before that switch worked right. It appears Compact
and BW both have unpatched 2.0.5 with at least this bug present.
-- Nathan
From:[email protected] [mailto:[email protected]] On
Behalf Of Jeremy Austin
Sent: Wednesday, December 21, 2016 10:22 PM
To:[email protected]
Subject: Re: [Telrad] More CPE8K woes
On Wed, Dec 21, 2016 at 7:44 PM, Nathan Anderson <[email protected]>
wrote:
but this upload capacity thing is what caused me to try pushing 6.6
out to more Compacts, even though I have read reports of
similar-sounding issues from others here who have fully
upgraded...just wanted to make sure I have all bases covered.
We haven't had stability issues per se with 6.6. We've had some
success raising upload AMBR, and shaping upstream.
What kind of retransmission rate are you seeing on the constrained
sectors in the upload direction, in extended stats? We have one in
particular that — despite having a verified clean channel — acts as
if it's experiencing interference. Despite a very high SINR! And
some truly bizarre spectrum analyzer results that aren't
corroborated by other, colocated ENBs.
I'm also not finding it easy running iperf between EPC and ENB, at
Telrad's recommendation. I must be more used to the syntax of
iperf3, because I don't have it correct yet.
--
Jeremy Austin
(907) 895-2311
(907) 803-5422
[email protected]
Heritage NetWorks
Whitestone Power & Communications
Vertical Broadband, LLC
Schedule a meeting: http://doodle.com/jermudgeon
_______________________________________________
Telrad mailing list
[email protected]
http://lists.wispa.org/mailman/listinfo/telrad
_______________________________________________
Telrad mailing list
[email protected]
http://lists.wispa.org/mailman/listinfo/telrad
_______________________________________________
Telrad mailing list
[email protected]
http://lists.wispa.org/mailman/listinfo/telrad
