Kitz Forum
Broadband Related => Broadband Technology => Topic started by: Black Sheep on March 21, 2015, 04:51:24 PM
-
For those who collate stats ...........
VCMM Card change-outs
The VCMM card is a line card that supports traffic in the Huawei 288 DSLAM cabinet.
There are approx 5,000 VCMM cards in the NGA network which have line test functionality not used in Openreach, this impacts our test systems.
The VCMM card change out programme will replace any offending cards – there’s no change to the card functionality, it’s just the redundant function that will be removed.
When is it happening?
We’re changing out 500 cards a week starting in March and aim to get the programme completed in May.
----
edit by admin - topic title
-
Wow, nice heads-up. Thanks ;)
-
That's not promising. From what I've previously read, the VCMM card is needed to support vectoring.
Hopefully the "there’s no change to the card functionality" statement does hold.
48 ports per card, so nearly 250,000 lines affected.
-
Thank you BS :)
That's not promising. From what I've previously read, the VCMM card is needed to support vectoring.
Hopefully the "there’s no change to the card functionality" statement does hold.
48 ports per card, so nearly 250,000 lines affected.
From the Huawei website (http://www.huanetwork.com/huawei-ma5616-price_p3806.html)
Does MA5616 support vectoring?
Yes, but will require CCUE main control board, software will be V800R313C00, power board should be high power DC, also the VDSL2 board should be 48 ports VDSL2 board VCMM.
The MA5616 is the smaller 128 cab, but the VCMMs are also the vectoring cards used in the MA560x dslams, so not sure exactly whats going on :-\
The mention of testing implies something to do with SELT/DELT/MELT (http://www.utel.co.uk/selt-melt-delt.php). I think BT may already been using SELT & DELT for donkey's years as Ive heard the term used in places like the PN reps on their forums. DELT definitely. So that leaves us with the newer MELT (http://www.broadband-forum.org/technical/download/TR-286.pdf)
They do have other line cards such as the VDMM, but that also supports MELT. I see a mention that Huawei also developed another new line card in 2012 for the MAQ5600 but I dont know the model no without any more digging, nor if they are compatible with the MA5603T (http://wenku.baidu.com/view/7ec3c515c281e53a5802ff9e.html)
-
A further note on this.
A post by Andy here (http://community.plus.net/forum/index.php/topic,136287.msg1215176.html#msg1215176).
OR have had issues with MA5616/MA5603T line cards due to something called ELE-M1.
ELE-M1 appears to be [Alternative] Electrical Length Estimation Mode for VDSL. According to TR-252 (https://www.broadband-forum.org/technical/download/TR-252_Issue-2.pdf) this is used to set the parameters for the UPBO & DPBO profiles. [page 18]
-
you trust andy as a source?
-
Found this, below .....
'Modems that do not support (A)ELEM will adversely affect those that do. This is due to the incorrect upstream power back off being applied'.
-
There's a publicly available PDF from Openreach (https://www.openreach.co.uk/orpg/home/products/super-fastfibreaccess/cpeenablement/cpeenablement.do)
"Huawei EMP 2750 CPE Release Notes" at the bottom in the Modem Conformance Test box
which confirms the AELEM fix.
-
Was reading the TR-252 and on page 19/40 it say's something about RFI, could someone expand on this and is this is being used on the 288 cabs.
RFI Profile
RFI notches are necessary when radio services may be disturbed during operation, or to protect DSL Lines from RFI, therefore this parameter should be separated from all other profiles. The RFI profile MUST contain the following parameter:
- RFIBANDS
-
That is what Konrado5 saw when his ISP transferred his circuit to a new DSLAM/MSAN. All users on the new equipment had a profile applied which "notched out" the frequencies of the 160 metre Amateur Radio Band ("Top Band").
-
That is what Konrado5 saw when his ISP transferred his circuit to a new DSLAM/MSAN. All users on the new equipment had a profile applied which "notched out" the frequencies of the 160 metre Amateur Radio Band ("Top Band").
So what your saying is the tones being effected by RFI are notched out/unavailable by the RFI profile, don't think I would like this applied to my line as the RFI comes and go's over a 24 hour period, so notching out the RFI tones/bands 24/7 would impact my attainable sync and thus lower sync rate but the DS SNRM would also become steady :-\
-
Yes, that's correct. Somehow I can't see Beattie Bellman creating a specific RFI profile for your cabinet's DSLAM/MSAN that disables the tones which are "splatted" by Radio China International! :-X
-
Yes, that's correct. Somehow I can't see Beattie Bellman creating a specific RFI profile for your cabinet's DSLAM/MSAN that disables the tones which are "splatted" by Radio China International! :-X
It would be better if Bettie Bellman sent an undercover squad to those transmitter pylons in china that are effecting UK broadband users and plant C4 charges at the base then get to a safe distance and fire in the hole then get the Bellman agents out of there safe and sound. :D
https://www.youtube.com/watch?v=JfIWmVviXhU (https://www.youtube.com/watch?v=JfIWmVviXhU)
-
There's a publicly available PDF from Openreach (https://www.openreach.co.uk/orpg/home/products/super-fastfibreaccess/cpeenablement/cpeenablement.do)
"Huawei EMP 2750 CPE Release Notes" at the bottom in the Modem Conformance Test box
which confirms the AELEM fix.
Somewhat off topic but viewing the documents available via the above link shows a mention of the "Introduction of MA5611 Fibre to the Remote Node DSLAM".
As of yet, I have not been able to find any details of a Huawei MA5611.
-
Thanks guys for finding the additional info, a quick scan suggests that the MA5603T were using VDMF lincards and the MA5616 was using VDSH linecards. Yet BS's post implies VCMM line cards already in the network, so Im a bit confused about a swap out and which way. Have I misunderstood something or are they saying that all cards will now be VCMMs.
Whatever way it appears that they have found an issue that causes significant reduction in upstream rates and loss of syncs on long lines.
---------------------
BTW... That document also references EMP2750 which looks like the ISPs may be able to get better monitoring tools and diagnostics. It would be nice if they would have added the facility for the ISP to reset the DLM in there too, but sadly not. Anyhows......
It seems to imply EMP(R)2750 due for delivery 24th Jan 2015 and references back to the Industry Forums (https://www.openreach.co.uk/orpg/home/products/industryforums/industryforumlanding.do) secure login pages for ISPs, that Andy has been harping on about recently.
I did find a public document (https://www.openreach.co.uk/orpg/home/updates/eipcommunications/downloads/EIP2R2750.pdf)though
GEA -FTTC Brandenburg NGA
Brandenburg NGA is an enhancement to the NGA Test & Diagnostic systems to improve the current method of determining if a GEA - FTTC circuit is experiencing performance problems and if that issue is due to a network or home environment problem.
This will be achieved through advanced diagnosis of network data to improve the location and diagnosis of faults causing poor SFBB performance and making additional test result information available to CPs .
Improvements will be made to the way of determining;
a) The cause of a drop in speed on a circuit.
b) The location and impact of interference problems.
CPs will have more information about the performance of their customer’s circuit which will enable their advisors to have a more valuable and insightful conversation with them about their problem, improved pre-qualification of any fault conditions and undertake better decision making regarding choosing the appropriate T2R products from Openreach.
In order to fully benefit from these changes CPs will need to consume the new information sent by Dialogue Services when a test result is returned.
-
So what your saying is the tones being effected by RFI are notched out/unavailable by the RFI profile, don't think I would like this applied to my line as the RFI comes and go's over a 24 hour period, so notching out the RFI tones/bands 24/7 would impact my attainable sync and thus lower sync rate but the DS SNRM would also become steady :-\
This notching has always been available although BT (nor any other UK ISP bar one) has never used it. BE* were the first ISP that I became aware of using it on their Alcatel ISAMs (MSAN by another name). It was never popular with Be/02 subscribers who were affected by it, because it stopped some users being able to attain full sync speeds. The notch was at the high end of the adsl2+ spectrum so it didn't make any difference though to those on short(er) lines.
Ironically I suggested to Konrado early on that this is what his ISP could be doing, but it was always dismissed. It was only later when he found out from his ISP that they had installed some new DSLAMs... which co-incidentally turned out to be the same Alcatels ISAMs used by Be/O2.
-
Found this, below .....
'Modems that do not support (A)ELEM will adversely affect those that do. This is due to the incorrect upstream power back off being applied'.
Interesting.
I was commenting in a thread over on TBB, where a user had some latency problems after G.INP activation. This was a line that was sync'ed at 80/20, with G.INP enabled, but had attainable of 95/45 - a notably high upstream attainable speed.
When compared against my line (currently 107/35 attainable with G.INP), I could see his line had slightly higher attenuation, but was otherwise configured identically for all G.INP settings; it looked like this was NOT the cause of the issue. However, the power values on the upstream were huge in comparison - my upstream power was -8dBm, his was +8dBm.
I remember commenting that it looked like the UPBO wasn't working right, and that perhaps this was having some knock-on impact to latency (but I haven't a clue why that would be).
-
latency problems after G.INP activation. This was a line that was sync'ed at 80/20, with G.INP enabled, but had attainable of 95/45 - a notably high upstream attainable speed.
/snip/
this was having some knock-on impact to latency (but I haven't a clue why that would be).
I cant think why either, but you know how sometimes when a line is interleaved it can do weird things to the max attainable. One of the symptoms of the latest g.inp issues is it looks like the line is interleaved but its not showing up anywhere - link (https://aastatus.net/2115)
-
Upon first glance it looks as if interleaving has been enabled, but a line test shows that this is not the case.
I've been wondering what they mean by this. Service tests do indeed show profile changes but that is presumably DLM data. I wonder if the cabs are applying interleaving without direct instruction from DLM, thus the +15ms is indeed caused by interleaving (as I recall, I was interleaved and INP'd) but this current state is not reflected on the service test.
Or it could be something else entirely...
-
Further to this, I just stumbled across a BT doc (https://www.openreach.co.uk/orpg/home/products/super-fastfibreaccess/downloads/HuaweiEMP2750CPEReleaseNotes.pdf) in relation to this when looking for something else.
EMP2750 CPE Affecting Release Notes - Fixes
ELEM not correctly implemented on VDMF(MA5603T) and VDSH(MA5616) line cards.
DSLAMS report different PSDs when AELEM is activated. Fix corrects this issue
Fix for issue where when AELEM is turned on, the achievable upstream rate drops very
significantly drops on long lines even when there is no bridgetap on the line on all Huawei
DSLAM Linecards.
Note in there the mention of ANFP compliance of Vectoring and also confirmation of the introduction of the MA5611 for Fibre to the Node
Still no MA5611. But did find a MA5611S (http://huawei.com/en/products/fixed-access/fttx/mxu/ma5611s/index.htm) which seems to fit