Voice channels (FTTH, DOCSIS, VoLTE)

Mon Nov 21 20:18:01 UTC 2016

On 11/21/16 11:13 AM, Jean-Francois Mezei wrote:
> On 2016-11-21 02:53, Mikael Abrahamsson wrote:
>
>> Typically it travels on another "bearer" compared to Internet traffic.
>>
>> http://blog.3g4g.co.uk/2013/08/volte-bearers.html
>>
>> Think of bearers as "tunnels" between the mobile core network and the 
>> device. 
> Many thanks for the pointer. The fact that VoLTE has its own dedicated
> APN explains things.
>
> I am however a bit confused on the "bearer" term.
>
> Say a carrier has spectrum in 700Mhz  bands A and B  each 5mhz in each
> direction, bonded together as a single 10mhz (each way) channel.
>
> The docunment states:
> "R.92 requires the use of a particular set of radio bearers"

the radio bearers described are are the signaling radio bearers. their
existence is independent of of the link/mac layer configuration. The mac
layer layer (e-utra) exists below the l2 bearers.

https://en.wikipedia.org/wiki/E-UTRA
> Does this mean that a bearer is given specific spectrum within a block
> (such as a dedicated colour on a fibre) or that it is just given
> dedicated capacity on the single data channel formed by LTE compressing
> all of the spectrum into one big channel ?
>
> I though I understood the concept when the name "tunnel" had been
> mentioned because I understand that a handset estabishes a "hopping"
> tunnel with local IP which changes as you move from tower to tower, but
> the tunnel itself maintains a permanent IP connection that remains
> unchanged as you move from tower to tower. In such a concept, I could
> understand each tunnel (one to the data APN, one to the IMS/VoLTE APN)
> having bandwidth allocations.
these are URBs they are terminated between the UE and the P-GW
> But when the text brought up "radio bearer", I got confused again sicne
> radio implies breaking the spectrum apart, which would reduce LTE
> compression efficiency.
SRB and URB are the l2 presentation of the tunnels established for user
and signaling traffic.
>
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20161121/dac741ea/attachment.sig>