Re: OT: QOS on Signaling Traffic for Mobile operators, SIGTRAN,

Hi Ahmed,

CEoIP = PWE (psudowire) :) Just different name for same technology.

You would be surprise to hear that CEoIP has no signaling from IP network
point of view.

It's just a RTP stream. TDM traffic gets encapsulated into IP packet and
decapsulated at the other end. So inside that PW one of the timeslot
(SIGTRAN) would be signaling itself.
As an standard practice, just trust all packets coming from BST/HLR and do
not touch them as they may cause additional delay in inspecting and marking
packets.

do not use cRTP
As far as you can find the value of jitter and de-jitter buffer - you should
not have problem with anything. It always depends network to network. You'll
have to do heat-nd-trial method.--> have fun with finding the correct jitter
buffer value. jitter buffer for each e1/ts is different and configureble.
buffer overflow/underflow stats on the interface level will give you an idea
to increase or decrease the jitter buffer value at each end.

other part will be taken care by RFC2198. Check if your Cisco module and IOS
supoprt RFC2198 for reconstruncting the lost packet/ data protection.

As for CESoIP still 1 LLQ is good way to go as it doesn't differenciates
data or signaling. everything goes inside the tunnel/wire :)

HTH
-frog

On Tue, Apr 14, 2009 at 11:06 PM, Ahmed Elhoussiny
<aelhoussiny_at_gmail.com>wrote:

> Hello Guys,
> The Signaling for STPs/Soft switches or SIGTRAN /HLR/
> Prepaid/IN signaling is running over IP.
> Thats the default.
>
> But the TDM /L2 , we have made a C3845 which is cable of time-division
> multiplexing (TDM) interconnections,
> As it has (NM-CEM-4TE1) to enable the CEoIP ( curcuit Emulation over IP )
>
> This C3845 is connected directly to the PE, so from CE-PE that no problem ,
> only this traffic is passing through.
> But inside the Backbone ? , by default cisco Interfaces mark thsi traffic
> as PREC 5 / EF.
> So by default it will take EXP 5 on MPLS and go with teh VOIP
> Queue..........
>
> Will this make a problem, or is this teh best practise for Mobile Operators
> , Does any one have a Best practise guide , or wellknown site for this kind
> of designs ?
>
> Im really thankfull for you both guys for you help in this, so seems to
> me that im going to words 2 LLQs or 1 LLQ holding all Voice &
> signaling.......All im afraid of is teh Signaling traffic (SIGTRAN ) , if
it
> got a Large Packet size , i may suffer of internal jitter in teh queue.
>
> Ahmed Elhoussiny,CCIE # 21988
>
>
>
> On Tue, Apr 14, 2009 at 1:44 PM, Marko Milivojevic
<markom_at_markom.info>wrote:
>
>> Pseudowires as vendors call them are just standardized approach to
>> doing TDMoIP and all of them suffer from the same issue. The point is
>> that IP is inheretly asynchronous, while "GSM" requires synch between
>> BTS's in order to hand over clients between them. When pressed about
>> these issues, every single vendor will reply with the same answer:
>> Yeah, it's an issue, but you can use adaptive sync. When pressed more:
>> Yeah, we know. Use GP$.
>>
>> Unfortunately, working for Vodafone (Iceland), I know this all too well
>> :-)
>>
>> On Tue, Apr 14, 2009 at 09:54, Radioactive Frog <pbhatkoti_at_gmail.com>
>> wrote:
>> > hehe...Good point...
>> > For that there is another technology called "Psudowire", that has better
>> > clock than normal TDMoIP products. This psudowire is specially designed
>> for
>> > ATM/IMA over Ethernet. These product even can keep BTS/BSC sync over a
>> > business grade DSL/(ADSL2+).
>> >
>> > Totally new market.
>> >
>> > Cheers
>> > -frog
>> >
>> >
>> >
>> > On Tue, Apr 14, 2009 at 7:23 PM, Marko Milivojevic <markom_at_markom.info>
>> > wrote:
>> >>
>> >> On Tue, Apr 14, 2009 at 03:26, Radioactive Frog <pbhatkoti_at_gmail.com>
>> >> wrote:
>> >> > TDMoIP is not bad. All it needs is a good QoS and fat pippe :)
>> >>
>> >> It's not bad at all for POTS backhaul and similar applications. For
>> >> mobile backhaul, it's not at all good, as it requires extra ffort to
>> >> support things like cell handover. Especially if your BTS' don't
>> >> support adaptive clock sync.

Blogs and organic groups at http://www.ccie.net
Received on Tue Apr 14 2009 - 23:44:12 ART