Subject: BICC in M3UA

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Fri, 21 Sep 2001 14:40:03 +0200

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.

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.

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.

Cheers // Javier.

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

---

From: Greg Sidebottom <[email-masked]>
Date: Fri, 28 Sep 2001 03:54:04 -0400

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.
> 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.

> 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

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Fri, 28 Sep 2001 11:53:15 +0200

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.

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.

> -----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,
> 
> >  - one of the future uses of M3UA is gonna be the UMTS 
> network which is
> being standardized by 3GPP and
> You are currently subscribed to sigtran as: 
> [email-masked]
> To unsubscribe send a blank email to 
> [email-masked]
> 

---

---

From: "Alf Heidermark (UAB)" <[email-masked]>
Date: Fri, 28 Sep 2001 14:45:56 +0200

Greg

As you perhaps know the BICC signalling requirement document TRQ 2150 shows a numbewr of signalling transports for BICC one of them consists of BICC+stc(mtp)+M3UA. The TRQ was approved in May this year.
Alf

-----Original Message-----
From: Javier Pastor-Balbas (ECE)
[mailto:[email-masked]]
Sent: den 28 september 2001 11:53
To: sigtran
Subject: RE: BICC in M3UA

Hi Greg, 

Cheers // Javier.

> [email-masked]

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

---

---

From: Lyndon Ong <[email-masked]>
Date: Fri, 28 Sep 2001 10:50:20 -0700 (PDT)

Folks,

FYI I have pinged our A-Ds on the SCTP error check
resolution status.  Last report was that the TSV
WG had settled on a 32-bit CRC but were still 
working on which CRC polynomial.  Will provide
updated status when available.

Cheers,

L. Ong
--- "Alf Heidermark (UAB)"
<[email-masked]> wrote:
> Greg
> 
> As you perhaps know the BICC signalling requirement
> document TRQ 2150 shows a numbewr of signalling
> transports for BICC one of them consists of
> BICC+stc(mtp)+M3UA. The TRQ was approved in May this
> year.
> Alf
>  
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 
> > 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
> > > We have been looking at the format of the
> routing key these 
> > last days 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
> > [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
> > 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
> > [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
> > ambiguous about what the CIC acronym stands for.  
>  Tag 
> > 0x0210 is already
> > >     0                   1                   2   
>                3
> > >    |           Tag = 0x0210        |            
>  Length           |
> > >    |                    Lower CIC Value #1      
>                   |
> > >    |                    Upper CIC Value #1      
>                   |
> > >    |                    Lower CIC Value #2      
>                   |
> > >    |                    Upper CIC Value #2      
>                   |
> > >    /                              ...           
>                   /
> > >    |    Mask = 0   |          Origination Point
=== message truncated ===

__________________________________________________
Do You Yahoo!?
Listen to your Yahoo! Mail messages from any phone.
http://phone.yahoo.com

---