the most risky about this is about possible bottle neck GboFR can be having. so when you swap to GboIP you will double or triple your current traffic and have great impact over your access network. So you have 2 scenarios 1.- if you don’t have over demand on radio ressources you ‘ll have the same IP traffic that you had on FR.
2.- if you are having oversuscription on your radio access it is needed to evaluate it to estimate the ip traffic you’ll liberate. that’s where fun engineering takes place
Are you saying that “if” the GboFR used to be congested, then -when swapping to GboIP- the extra bandwidth on IP will generate a peak on the radio network ?
That’s a weird way to look at it 🙂 The Gb interface shall never be congested, and I’ve never meet an operator where this interface is congested…
So in reality, GboFR is not a bottlneck. But please correct me if i’m wrong.
The IP datagram uses a bigger header than FR datagram, so the GboIP traffic will use something like 10% more bandwidth than before. Just compare headers to know the exact value, I’m sure such computations can be found online.
IP pool size can be given by the number of packet processing cards on each BSC.
you should choose your ip pool sized to the max of your bsc. Physical media should not be a problem since you should be using GigEth on all your interfaces.
The implementation of Gb interface over IP can be carried out by assigning the NS- VCs as an IP address endpoints either statically or dynamically. It will be terminated via the ethernet connections, between the endpoints. the NS – VCs can be composed of the IP address and the UDP ports.
Author
Posts
Viewing 7 posts - 1 through 7 (of 7 total)
The forum ‘Telecom Design’ is closed to new topics and replies.