Subject: Re: BICC in M3UA

From: Greg Sidebottom <[email-masked]>
Date: Mon, 1 Oct 2001 11:51:11 -0400

Hi Javier,

Thanks for the info - see below ...

----- Original Message -----
From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Friday, September 28, 2001 5:53 AM
Subject: RE: BICC in M3UA

>
> Hi Greg,
>
> As you probably know, STC for SCTP transport (Q.2150.3) has not been
approved yet. The main reason for that is the slow speed in getting the new
SCTP out. If the new SCTP RFC does not come out, there is no valid reference
for the ITU to standardize STC for SCTP.

[Greg] Yet M3UA runs over the same old SCTP RFC - seems the same reference
issue to me  2;^)

> Therefore, the option that 3GPP thinks about right now is transporting
BICC over STC over M3UA. STC is no more that an interface adaptor. It adapts
the particular transport layer interface to a generic one to be used by
BICC. This allows BICC being transport independent. The problem with the
CICs still remains, since STC is not thought to manage a 32 to 16 bits
conversion.
>
> The references you are asking for:
>
> ITU-T Recommendation Q.2150.0 "Generic Transport Service"
> ITU-T Recommendation Q.2150.1 "STC Signaling Transport Converter on MTP3
and MTPb"
> ITU-T Recommendation Q.1901 "Bearer Independent Call Control Protocol"
>
> Greg, I don't know if it is a good option to extend the ISUP CIC. You can
have nodes where both can coexist (ISUP and BICC) because different nodes
they have to communicate with, only support BICC or ISUP. e.g., a gateway.
In that case you may need to differenciate what are you registrating for and
to registrate with different RKs for each user part...
> Cheers // Javier.

[Greg]   So you will know from the SI (BICC or ISUP) how to interpret the
CIC Ranges - I don't see a problem yet.  One further question for the
BICC/ISUP experts out there - can we assume that  if SI=BICC then the CIC is
32-bits and if SI=ISUP then the CIC is 16-bits?  If so, then an SI in the
REG REQ RK is sufficient to make this work with a common Circuit Range List
parameter.

Thanks,

   Greg

>
>
> > -----Original Message-----
> > From: Greg Sidebottom [mailto:[email-masked]]
> > Sent: Friday, September 28, 2001 9:54 AM
> > To: sigtran
> > Subject: Re: BICC in M3UA
> >
> >
> > Hi Javier,
> >
> > Given that M3UA is a future possibility for BICC "transport"
> > I can support
> > this in principle.  Note though that the ITU Signalling
> > Transport Converter
> > on
> > SCTP (Q.2150.3 or .1?) would be a better choice in some cases.
> >
> > Comments below ...
> >
> > ----- Original Message -----
> > From: "Javier Pastor-Balbas (ECE)"
> > <[email-masked]>
> > To: "sigtran" <[email-masked]>
> > Cc: "'Greg Sidebottom'" <[email-masked]>
> > Sent: Friday, September 21, 2001 8:40 AM
> > Subject: BICC in M3UA
> >
> >
> > > Hi,
> > >
> > > We have been looking at the format of the routing key these
> > last days and
> > we have detected a possible hole that I try to describe below.
> > >
> > > Taken into account that:
> > >  - one of the future uses of M3UA is gonna be the UMTS
> > network which is
> > being standardized by 3GPP and
> > >  - one of the main protocols to be transported over M3UA is
> > gonna be BICC,
> > >
> > > Then, I think we need to adapt M3UA to be used by BICC. As
> > you probably
> > know, BICC is the evolution of ISUP but making the latter
> > independent of the
> > transport layer. As ISUP it uses the CIC concept (now called
> > "Call Instance
> > Code"). The difference with the current CIC is that it needs 32 bits.
> > >
> >
> > [Greg] If this is agreed (I haven't seen any objections) I
> > wonder if I can
> > get someone familiar with the BICC work to give me an ITU
> > reference for the
> > BICC protocol (Q.??) and the STC for MTP3 (Q.2150.x?).  I am
> > out of the ITU
> > loop these days   2:^(
> >
> >
> > > Therefore, I propose to add a new parameter in the Routing
> > Key for this
> > purpose. This would happen in the definition of Routing Key (Section
> > 3.6.1)The new parameter (optional) will be called BICC_CIC
> > (Call Instant
> > Code) and will be 32 bits long. I would assign Tag == 0x0210
> > which is the
> > next to the ISUP CIC tag value.
> > >
> >
> > [Greg] Perhaps we should leave it independent of the
> > application that uses
> > it and just call it Extended CIC?  Perhaps in the future
> > applications other
> > than BICC may want to use it.  Maybe we can even get away with being
> > ambiguous about what the CIC acronym stands for.    Tag
> > 0x0210 is already
> > assigned but that is not a big deal.
> >
> > >
> > >
> > > The Call Intance Range format would be as follows:
> > >
> > >     0                   1                   2                   3
> > >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |           Tag = 0x0210        |              Length           |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |    Mask = 0   |          Origination Point Code #1            |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |                    Lower CIC Value #1                         |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |                    Upper CIC Value #1                         |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |    Mask = 0   |          Origination Point Code #2            |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |                    Lower CIC Value #2                         |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |                    Upper CIC Value #2                         |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    /                              ...                              /
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |    Mask = 0   |          Origination Point Code #n            |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |                    Lower CIC Value #n                         |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |                    Upper CIC Value #n                         |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >
> > >
> > >
> > > This adaptation to the 3rd Generation protocol would also
> > impact in the
> > rest of the text where it is said "ISUP CICs". This former
> > view would be
> > widen to include the BICC protocol as well.
> >
> > [Greg] I was thinking that another option would be to just
> > extend CIC value
> > to 32-bits as above in general?  The current 16-bit CICs
> > would fit in with
> > leading "0"'s.  A little more overhead but do-able.   You are
> > right that we
> > would anyway have to clean up some of the "ISUP CIC" text to
> > generalize.
> >
> > Cheers,
> >
> >    Greg Sidebottom
> >
> >
> >
> >
> >
> > ---
> > You are currently subscribed to sigtran as:
> > [email-masked]
> > To unsubscribe send a blank email to
> > [email-masked]
> >
>
>
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to
[email-masked]

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Mon, 01 Oct 2001 18:28:55 +0200

> Sent: Monday, October 01, 2001 5:51 PM
> To: sigtran

I think it's not so easy for the ITU guys  ;-)

> REG REQ RK is sufficient to make this work with a common 

Yes, you are right. I think it was Friday afternoon when I wrote that  :-O. I think SI for ISUP is 5 and for BICC is 8. Anyway, they are different enough to make a selection based on them  .-).

Cheers // Javier.

> > > >     0                   1                   2           
>         3
> > > >    |           Tag = 0x0210        |              
> Length           |
> > > >    |                    Lower CIC Value #1              
>            |
> > > >    |                    Upper CIC Value #1              
>            |
> > > >    |                    Lower CIC Value #2              
>            |
> > > >    |                    Upper CIC Value #2              
>            |
> > > >    /                              ...                   
>            /
> > > >    |                    Lower CIC Value #n              
>            |
> > > >    |                    Upper CIC Value #n              
>            |

---