Kitz Forum

Broadband Related => Broadband Technology => Topic started by: Bowdon on March 15, 2017, 02:26:26 PM

Title: SNR Margin & G.fast
Post by: Bowdon on March 15, 2017, 02:26:26 PM
If the target SNR margin is reduced to 3dB would this increase the speed & reach of G.fast?

I'm kinda assuming that when people talk about the distance reach of G.fast that its all based on the SNR margin being 6dB.
Title: Re: SNR Margin & G.fast
Post by: burakkucat on March 15, 2017, 07:20:18 PM
G.Fast (https://en.wikipedia.org/wiki/G.fast) is ITU-T specifications G.9700 (https://www.itu.int/rec/T-REC-G.9700/en) and G.9701 (http://www.itu.int/rec/T-REC-G.9701).

I have not given any consideration to target SNRM, only the duplex method (time division). Perhaps you could research the information given in the above links?  :-\
Title: Re: SNR Margin & G.fast
Post by: Bowdon on March 20, 2017, 06:11:46 PM
That's way over my head :)

I let the cats kitz and wombats to figure that stuff out. I'm just the dopey dog always asking questions  ;D

I was wondering, seen as G.fast has vectoring built in, if I was to sign up for G.fast I wonder if my line would become vectored, so that in itself might make it more stable. I'm not sure about the G.INP and SNR margin as they would come from the cabinet, as far as I know.
Title: Re: SNR Margin & G.fast
Post by: burakkucat on March 20, 2017, 07:14:32 PM
I was wondering, seen as G.fast has vectoring built in, . . .

Vectoring is mandatory for G.Fast.

Quote
. . . if I was to sign up for G.fast I wonder if my line would become vectored, . . .

Vectoring would be applied to the circuit.

Quote
so that in itself might make it more stable.

Can one equate the minimisation of cross-talk with stability?  :-\  That is a good question.

Quote
I'm not sure about the G.INP and SNR margin as they would come from the cabinet, as far as I know.

Let us assume that you are provided with a service which makes use of the G.Fast process. It would be provided from a "side-pod", attached to the PCP through which your circuit is routed. Unlike the case where one migrates from a G.992.5 to a G.993.2 service, which relies upon a low-pass filter in the "fibre" cabinet in stopping the exchange based G.992.5 service in reaching the end-user's CPE, I would expect the G.993.2 service to be explicitly terminated and disconnected from the circuit. All features of the G.Fast circuit's mode of operation would be controlled by the electronics in the PCP "side-pod".
Title: Re: SNR Margin & G.fast
Post by: PhilipD on March 21, 2017, 07:48:33 AM
Hi

I would think the low pass filter is also in the G.Fast pod as you don't want the signal travelling back towards the exchange.  How they connect up will work in the same way as FTTC except G.Fast is just that much closer to the PCP.  Having the pod on the PCP will also reduce distance for many people, at my old address the PCP was a good 20 metres away from the FTTC cabinet, so adding 20 metres of distance, at my new address it's around 10 metres.  With G.Fast being more distance dependent than anything they've hacked across decades old telephone cable before, saving just a few metres of distance will make a considerable difference.  Presumably why they've gone for attaching the POD on the PCP rather than extending the FTTC cabinet, which would be easier as the power and fibre is already there.

Regards

Phil
Title: Re: SNR Margin & G.fast
Post by: burakkucat on March 21, 2017, 06:09:00 PM
Thank you for your thoughts Phil.

There is something else that came to mind, earlier today, whilst I was doing a routine task that did not require any great mental supervisory effort . . .

G.9700/G.9701 (G.Fast) uses time division duplex (TDD) and not frequency division duplex (FDD) like the current (common) xDSL services (G.992.{1|3|5}/G.993.2). To me, usage of TDD suggests that a G.Fast service should be capable of supporting symmetric synchronisation speeds. I.e. Equal DS and US synchronisation speeds.
Title: Re: SNR Margin & G.fast
Post by: lee111s on March 21, 2017, 06:45:38 PM
Thank you for your thoughts Phil.

There is something else that came to mind, earlier today, whilst I was doing a routine task that did not require any great mental supervisory effort . . .

G.9700/G.9701 (G.Fast) uses time division duplex (TDD) and not frequency division duplex (FDD) like the current (common) xDSL services (G.992.{1|3|5}/G.993.2). To me, usage of TDD suggests that a G.Fast service should be capable of supporting symmetric synchronisation speeds. I.e. Equal DS and US synchronisation speeds.

Correct. I believe it is actually mandatory to offer ratios of between 90/10 to 50/50, but 50/50 to 10/90 is discrentionary.
Title: Re: SNR Margin & G.fast
Post by: Weaver on March 21, 2017, 07:00:06 PM
Presumably TDD makes it more spectrum-efficient? But I haven't taken the Fourier transform of the time-sliced combined signals to have a look at what that combining process does to you.
Title: Re: SNR Margin & G.fast
Post by: burakkucat on March 21, 2017, 07:22:23 PM
Presumably TDD makes it more spectrum-efficient?

The way I view it is as two alternating "time-share" simplex transmissions, each of which has the full circuit bandwidth available to use.
Title: Re: SNR Margin & G.fast
Post by: PhilipD on March 22, 2017, 07:59:35 AM
Hi

The way I view it is as two alternating "time-share" simplex transmissions, each of which has the full circuit bandwidth available to use.

G.Fast because of time division multiplexing also adds some latency but shouldn't be noticeable, however the other benefit of time division multiplexing is because it's on/off constantly in each direction, it's much easier to add power saving options, for example, skipping some of the time slots is easy to implement until a transmit buffer is full to burst it across in one go.  G.Fast will have these sorts of power saving features, and if they do enable them then latency is likely to be all over the place.  Not sure if BT have said if they will implement these sorts of power saving options, but gamers will not like it. 

Regards

Phil
Title: Re: SNR Margin & G.fast
Post by: ejs on March 22, 2017, 08:09:27 AM
Or the time slots will be so short it will be completely unnoticeable, but gamers will still probably not like it once they know they are there.
Title: Re: SNR Margin & G.fast
Post by: Chrysalis on March 22, 2017, 08:46:27 AM
I would guess the power saving stuff will be disabled as it carries risk of problems, problems = money expenditure.
Title: Re: SNR Margin & G.fast
Post by: ejs on March 22, 2017, 08:57:04 AM
I thought I'd better skim through the ITU-T G.9701 document, from which I gather a typical time for one "TDD frame", which comprises both downstream and upstream, is 0.75ms.
Title: Re: SNR Margin & G.fast
Post by: burakkucat on March 22, 2017, 09:40:22 PM
I thought I'd better skim through the ITU-T G.9701 document, from which I gather a typical time for one "TDD frame", which comprises both downstream and upstream, is 0.75ms.

Thank you.

Reading either/or/and G.9700/G.9701 was not currently something that I wanted to do.
Title: Re: SNR Margin & G.fast
Post by: niemand on March 23, 2017, 09:00:21 AM
If the target SNR margin is reduced to 3dB would this increase the speed & reach of G.fast?

Yes.

You're welcome.
Title: Re: SNR Margin & G.fast
Post by: WWWombat on March 23, 2017, 03:08:35 PM
Correct. I believe it is actually mandatory to offer ratios of between 90/10 to 50/50, but 50/50 to 10/90 is discrentionary.

I guess it is Mandatory/Discretionary that the vendor offers those ratios to the telco. Not that the telco offers any choice to the end user.

The current use of FDD requires that every user on a cabinet has the same FDD split (ie same bandplan), to avoid near-end crosstalk.
G.Fast will therefore require that every line has the same TDD split, for the same reason.

However, I vaguely recall that the standards were also going to include something that allowed the ratio to be adapted on the fly, based on demand. I have no idea whether that has to take account of the demand from all lines, and adapt all lines simultaneously, or whether they've figured out how to reduce the near-end crosstalk.
Title: Re: SNR Margin & G.fast
Post by: ejs on March 23, 2017, 03:32:33 PM
However, I vaguely recall that the standards were also going to include something that allowed the ratio to be adapted on the fly, based on demand. I have no idea whether that has to take account of the demand from all lines, and adapt all lines simultaneously, or whether they've figured out how to reduce the near-end crosstalk.

I think this will be for single-port DPUs only, not applicable to cabinet pods.
http://www.sckipio.com/sckipio-announces-worlds-first-single-port-g-fast-dpu-dynamic-time-assignment/