Re: many thanks for ur reply there few more

ali,

ali ovaisi wrote:                               (Wed, 27 Jun 2007 04:59:27)
>
>
> (i totally agree and it should be the case that SS7 messages will be wrap up
> in the M3UA packets to move from IP network and nothing to do with VoIP
> except that SIGTRAN (eg M3UA) over head is added in signaling gateway
> (whether the complete ss7 message is encapsulated or break up into chunks in
> M3UA??????) ) 

The maximum narrow-band SS7 message length is 272 octets.  ISUP messages are
almost never that large (including IAMs which are the largest of ISUP
messages).  SIGTRAN uses IP which has an minimum MTU of 536 (no, its larger,
someone help me here) but is normally larger.  The point is there is never
any reason for SIGTRAN to break an SS7 message into multiple chunks, so you
can assume one DATA Chunk header overhead per SS7 message.

> (I opened ITU-Ts Q.763 but it dont give the exact value (in bytes) of any of
> the ISUP message (as there are optional parameters so how you calculate 35
> or it used to be 45 when u were studying??) and one more thing that there
> are 39 messages to be used in different occasion).

The length of the messages containing mandatory variable parameters or
optional parameters (such as the IAM) are not fixed; however, they are
bounded.  The minimum length of the message is the length of the message
including only mandatory fixed and mandatory variable parameters (of minimum
possible length).  The maximum length of the message is the length of the
message including all mandatory fixed, mandatory variable parameters (of
maximum possible length) and all optional parameters (of maximum possible
length).

Usually, the only messages that will contain variable parameters of any
concern are the IAM and the CPG (possibly the REL/RLC in some protocol
variants).  Whether a particular traffic flow contains a given optional
parameter, and the length of the mandatory variable and optional parameters,
depends upon the precise protocol variant (ITU-T, ETSI, ANSI), the traffic in
question (e.g.  international, national tandem, local tandem, ingress or
egress), and the features used by the call (e.g. ISDN access transport, DISA,
local number portability, malicious call trace, emergency, call forwarding
(redirect), release to voice mail, etc.)  The protocol variant can be
determined by the country within which the messaging occurs; the type of
traffic, from the position within the telephone network;  the features used,
by service penetration levels and usage studies for the particular operator.

The point here is: you cannot calculate it because you have too many unknowns,
you can only estimate it.

> >
> > What you need to do is to take the message format for a typical ISUP call
> > flow IAM, ACM, ANM/CPG, REL, and RLC message and count up the number of
> > bytes for each and then add
>
> (each one separately or individually as IAM will come first and this data
> will pass on to IP via M3UA and after ,say, 10 minutes when call is finished
> then the REL will be generated by ss7 and then go to SG and converted in IP
> via M3UA and go across so if we add 175 altogether in one M3UA header we
> will miss the over head added by M3UA each time isup message is generated )

(IAM + ACM + ANM/CPG + REL + RLC) + (M3UA overhead for the 5 messages).

The M3UA overhead for the 5 messages could be 5 times the overhead for a
single message, or could be less if SCTP is bundling messages from many
calls in to the same packet.

> >
> > in the overhead of the M3UA DATA message
>
> (what after that as I have to know about the rate (and rate is a quantity
> with respect to time and please tell that what effect does the length of
> call will put on isup message and on M3UA message)).

You originally asked the rate of SS7oIP traffic given a rate of VoIP traffic.

So, if you calculate, say, 1600 bits per call, then for a VoIP traffic
rate of 300 calls per second, you will have, expressed in bits per second,
an SS7oIP rate of 1600 x 300 = 480,000 bits per second.  As there are about 5
messages per call, you will have an SS7oIP rate, expressed in messages per
second, of 5 x 300 = 1500 messages per second.

The length of the call does not affect the signalling rate in any significant
way.

> >
> > The IAM is difficult as it can contain many optional parameters that
> > depend upon the specific country of operation, the features associated
> > with the call, and the position in the switching hierarchy.  IAM message
> > use to be about 45 bytes in Canada back when I used to do network
> > engineering, but LNP and other things have probably raised that to about
> > 60 bytes.  The other mesages do no normally carry many optional parameters
> > except the REL.  Note that unsuccessful calls also use almost as many
> > messages
>
> (but there are still isup messages flowing between nodes during ANM and REL
> what about them??).

Messages other than the IAM are very small in size compared to the size of the
IAM, but their size is easier to determine.

> >
> > All in all the order-of-manitude rule of thumb
>
> (please do tell me where you got this rule of thumb from although I agree
> that typical ISUP messages(for a typical call) are 5 so I can use this as
> the basis of taking 5 messages)

The rule of thumb comes from 20 years of traffic engineering experience.

> >
> > used to be to estimate that a call takes 5 messages and that the average
> > length of the messages is 35 bytes
>
> (is this a rule of thumb as well and if so where you get this as well????)

Again, from experience.  If you take a 45 byte IAM and add length of the other
messages and then divide by 5, you will get about 35.  Just works that way.
Engineering estimation is all about remembering these results.

>
> > (I can't remember whether that included the FSN/BSN and RL, I'm pretty
> > sure it did
>
> (but fsn/bsn are part of every signaling unit and MSU???))

What I mean was whether 45 bytes included the length of the BSN/FSN and RL
whether it was excluded from the size (i.e. the 45 bytes represented the
length of only the ISUP part of the message) or was included (i.e. the 45
bytes represented the entire length of the SS7 message, including the BSN/FSN
and RL, which are not the ISUP part of the message).  But, as I recall, it
was the entire length of the IAM and therefore the 45 bytes was the length of
the entire IAM, including the length of the BSN/FSN and RL.

>
> > so about 175 bytes per call
>
> ( so u are saying that if call is ,let say, for 10 minutes so it has the
> same number of bytes generating as for the one which last for ,say, 20
> minutes).

The same number of signalling bytes, yes.  You were seeking the SS7oIP rate
(signalling only) for a given VoIP traffic rate.

> > 
> > If you need refined numbers you would have to actually capture SS7 or M3UA
> > traffic from a real network and analyze it statistically or using a
> > traffic model.  Modelling of traffic in a telephone network is an entire
> > field of study.
> > >
> > >  M2UA
> > 
> > M2UA carries a little more of the SS7 message in the MAUP data (it
> > includes FSN/BSN whereas M3UA does not
> 
> (are these fsn/bsn form SIGTRAN protocols or the one with the Signaling
> Units of SS7 because SU have fsn/bsn as fixed part of it ???  And above you
> have written that in 35 bytes fsn/bsn are included for isup messages so if
> they do then how come after reaching at M3UA they are detached from it)).

I'm sorry.  M2UA MAUP Protocol Data messages do not include BSN/FSN, nor the
LI for that matter (unless it is TTC protocol variant, in which case it
includes the first octet of the LI).  Therefore, you need to subtract the
length of the BSN/FSN and LI from the length of the SS7 message before adding
the M2UA header.

> >
> > FSN/BSN are 2 bytes for each message.  See section 3 in RFC 3331.
> > 
> > >    M2PA
> > 
> > M2PA does not carry FSN/BSN from the SS7 message, but adds its own in the
> > User Data message whose format is given in section 2.3.1 of RFC 4165.
> > 
> > >    Need your help and guidance
> > >    hope to get reply soon
> > 
> > If you need more guidance, I suggest that you consult with the people at
> > your learning institution that assigned the project to you
> 
> (the project is assigned to me by my institution but those people has told
> me straight that they have very little or no knowledge of this and I took it
> as a challenge moreover the time given to me for this is very short but I am
> still very much confident that I will be able to do this in time)

You will not be able to calculate an accurate answer (too many unknowns): you
can get an order-of-magnitude approximation (the unknowns can be bounded).

> 
> I would like to thank you for your sincere help as this mail helps me a lot
> in making my concepts clearer and also for not telling the answer straight
> away.
>
> Hope you will keep on helping me during this project.
> KR
> ALI

-- 
Brian F. G. Bidulock
[email protected]
http://www.openss7.org/