| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Peter, Thanks for the nice summary on encryption and authentication. The other aspect from CPRI that we can carry over is the synchronization and Master-Slave relationship between BBU and RRH. The RRH should sync up its transmit packets with id based on packet ids received from BBU. This way the round trip delay and packet jitter becomes
measurable at the BBU as part of protocol. Thanks, Sriram. From: AshwoodsmithPeter [mailto:Peter.AshwoodSmith@xxxxxxxxxx]
Yes, don’t want to re-invent any wheels. I’d suggest that the structure aware could possibly encrypt the control channels but that FEC is handled by whatever
PHY layer the Ethernet frame traverses and as Marek suggests authentication uses .1X so likely we don’t have much to do there. Peter From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]
That could be done easily by (for example) referencing 802.1X or something in these lines … how to map such a mechanism into an Ethernet link is well known and
requires zero effort Marek From: Devi, Sriram [mailto:sriram.devi@xxxxxxxxx]
Although encryption can be handled at higher layers, some reference to authentication and security may have to be included to secure the
BBU to RRH links from attacks. Sriram. From:
stds-1904-3-tf@xxxxxxxx [mailto:stds-1904-3-tf@xxxxxxxx]
On Behalf Of AshwoodsmithPeter Exactly, and to the best of my knowledge there is no FEC mechanisms that can recover from the loss of a string of 1000’s of bits that would happen with an Ethernet
frame loss. Ethernet has a CRC for error detection and then the underlying PHI will have various kinds of FEC depending on the speed/media etc. So FEC is not only redundant in this context it won’t help. IMHO, the only way you could survive frame loss with
CPRI over Ethernet in anything like the time required would be with 1+1 spared connection and even that is really hard (say 8ns to switch to the other connection and it has to be running with exactly the same delay as the primary). On the security issue, I think there is an argument to make for securing the control channel, but the I/Q data is about to be converted to Analog (I*sin(carrier)
– Q*cos(carrier) or something like that) and broadcast, so it’s kind of easy to snoop the I/Q off the air no matter what E2E security were put in place to wrap around it. Peter From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]
CPRI as far as I understand runs natively over some PHY, whereas here we will run over Ethernet, so it is not the same as OTN or CPRI itself. If we were to make apples-to-apples comparison, it would have to be some sort of L3+ protocol
operating over Ethernet, where FEC is not added. Ethernet as the transport layer provides it already on per-link basis Marek On 3 June 2015 at 11:54, Richard Maiden <rmaiden@xxxxxxxxxx> wrote: Thanks Sunny and others,
For I/Q data, for security concern, it is similar like the over the air radio signal, you can always
sniff the radio signal, so I think the I/Q transmission doesn’t need encryption. For error correction, what packet loss rate we are targeting. For radio data, due to the wireless channel issue, if it is not packet loss, some I/Q data error won’t
have much impact, if the error rate is very low, likely no need FEC. -Sunny From:
stds-1904-3-tf@xxxxxxxx [mailto:stds-1904-3-tf@xxxxxxxx]
On Behalf Of AshwoodsmithPeter Guys, sorry I can’t make Beijing. 1-
I don’t think we should be adding any additional error correction above and beyond what is already done by Ethernet, besides a frame loss is impossible to recover from, only solution
there is just to perhaps replay last frame or something along those lines? 2-
I don’t think end to end encryption is practical here. Peter From:stds-1904-3-tf@xxxxxxxx
[mailto:stds-1904-3-tf@xxxxxxxx]
On Behalf Of Marek Hajduczenia Richard, FEC is fine, but (a) it eats into the link budget, (b) there has to be agreement as to what FEC is being used (ton of options are out there), and (c) lots of Ethernet PHYs already
include FEC of their own, at which case adding it at encapsulation process kind of makes no sense. FEC is closely tied with the specific link type, data rate, PHY technology, etc. and doing FEC E2E makes little sense, since Ethernet transport will guarantee
delivery at 10^-12 BER. As far as E2E encryption is concerned, there are already plenty of mechanisms in place that allow end points to authenticate and encrypt traffic. Do we need to come up with a new
one or just allow these mechanism to just work? Marek On 2 June 2015 at 10:06, Richard Maiden <rmaiden@xxxxxxxxxx> wrote: Jouni et al, Folks,
|