RE: [Sigtran] SUA v16: Global Titles

["Barry Nagelberg" <[e-mail]>]

Brian,

Thanks. As you can see, it's taken me some time to digest this.

I think I now understand your approach, but I think that you may be
over-simplifying a bit, and I suspect that we must add something to SUA.

Let's follow up on your example below. Let's say that an ITU SCCP-user at
the ASP sends a UNITDATA_REQ primitive to the SUA layer at the ASP with a
global title address parameter that has only a Nature of Address indicator
(GTI = 0001). By definition, the other Global title fields - Translation
type, Numbering plan and Encoding scheme - are absent.

You propose that the SUA at the ASP send a CLDT msg to the SG, with GTI =
0100. But because GTI = 0100 requires that _all_ of the Global title fields
be _present_, the ASP SUA must choose some arbitrary value to populate the
fields that were absent in the UNITDATA_REQ.

Now when the SG SUA layer receives the CLDT msg with GTI = 0100, it thinks
that it has received a fully-populated address, and has no way to know that
the values in the Translation type and Numbering plan fields are, in fact,
arbitrary. As far as it knows, they are real. So it will go ahead and
include these arbitrary values in the UNITDATA_IND that it sends to the SCCP
layer at the SG. The SCCP layer will not be very happy after trying to
decode these arbitrary values.

I think that we must specify in SUA some value that is defined to mean that
"this field has been populated with an arbitrary value and should be
stripped from the address". Zero would be the logical choice, as it is
already defined as "unknown" for Translation type, Numbering plan and Nature
of Address.

Barry Nagelberg
Adax, Inc.

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[e-mail]]
> Sent: Friday, February 13, 2004 12:56 PM
> To: Barry Nagelberg
> Cc: SIGTRAN Mailing List; John Loughney; Michael Perler
> Subject: Re: [Sigtran] SUA v16: Global Titles
>
>
> Barry,
>
> What I was trying to say was that SUA GTI 0100 global titles can map
> nature of address into Q.713 GTI 0001 if you want to specify NAI from
> SUA.  Normally, the SCCP GTT function at the SG would decide how to map
> SUA GT fields (SCCP-User provided values) into SCCP GT fields.  This
> mapping is not specified in SUA, because it is the business of
> the SS7 node,
> however, as SUA GTI 0100 specifies all fields, it is always
> possible for SUA
> to specify any field of a GT.  If you are looking for a 1:1
> mapping between
> SUA GTI values and SCCP GTI values there is none.  Again,
> selecting an SCCP
> address format is the business of the GTT function at the SG.  This is a
> normal function of SCCP.  So, for example:
>
>                         |
>                         |  N_UNITDATA_REQ
>                         v
>                 +----------------+
>                 |                |
>                 |      SUA       |
>                 |     (ASP)      |
>                 |                |
>                 +----------------+
>                         |
>                         | SUA CLDT
>                         v
>                 +----------------+
>                 |                |
>                 |      SUA       |
>                 |    (SG-AMF)    |
>                 |                |
>                 +----------------+
>                         |
>                         |  N_UNITDATA_REQ
>                         v
>                 +----------------+
>                 |                |
>                 |      SCCP      |
>                 |                |
>                 |  Local GTT     |
>                 |                |
>                 +----------------+
>                         |
>                         |  UDT
>                         v
>
> All that is necessary is for SUA to provide fields to the
> N-UNITDATA-Request
> (and other SCCP primitives accepting a Called Party Address).
>
> The format of the Called Party Address parameter to N-CONNECT-Request and
> N-UNITDATA-Request primitives is not specified (see, for example,
> Q.711/6.2.2.2.1) and is implementation specific.  That is, a particular
> implementation of SCCP will have made some choices there.  As ITU
> and ANSI are
> rather different, an implementation of the SCCP/SCCP-User
> interface meant to
> be generic across multiple protocol variants would not use GTI.  It might
> indicate the presence or absence of each GT element in a GTI indepdendent
> fashion.  I don't know what your specific implementation looks like.
>
> So what I was saying is that if your SUA user wants to specify
> NAI, it should
> formulate an N-UNITDATA-Request containing NAI.  SUA at the ASP
> can place this
> value in the SUA Called Party Address with GTI 0100.  SUA at the
> SG can then
> regenerate an N-UNITDATA-Request an issue that primitive to SCCP
> at the SG.
> The local GTT function at the SG is responsible for deciding GTI
> and Called
> Party Address format based on the N-UNITDATA request according to network
> routing policy (local GTT datafill).  It is that function that
> will utlimately
> determine the Called Party Address in any resulting UDT message.
>
> For complete IP domain operation (IPSP) the fields populated in the
> N-UNITDATA-Request primitive as placed in the CLDT can be indicated in the
> N-UNITDATA-Indication primitive.
>
> --brian
>
>
> Barry Nagelberg wrote:
>                    (Fri, 13 Feb 2004 11:58:49)
> > Brian,
> >
> > I don't understand what you mean by "If you need to specify any
> value, ...".
> > Of course I, and everyone else, must specify a value - GTI is not an
> > optional field in the Global Title parameter.
> >
> > I also don't understand how we are supposed to map the GTI
> values given in
> > ITU Q.713 3.4.2.3.1 into the values specified in SUA section
> 3.10.2.3. These
> > seem to be two disjoint sets.
> >
> > Barry Nagelberg
> >
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:[e-mail]]
> > > Sent: Wednesday, January 28, 2004 2:24 PM
> > > To: Barry Nagelberg
> > > Cc: SIGTRAN Mailing List; Seamus Gilchrist; Michael Perler
> > > Subject: Re: [Sigtran] SUA v16: Global Titles
> > >
> > >
> > > Barry,
> > >
> > > I think you'll find that it more closely resembles ANSI
> T1.112, which does
> > > not have a nature of address indicator.  Also, encoding scheme is
> > > only ever
> > > BCD (odd or even).  GTI in SUA and (for that matter) GTI in ITU
> > > and ANSI do
> > > not match.  The GTI in SUA, like ITU and ANSI indicates the
> fields present
> > > in the messsage.  If you need to specify any value, use SUA
> GTI=0100.  The
> > > SUA GTI does not dictate what is passed to the SS7 network by
> a gateway.
> > > The AMF or GTT result will determine that.
> > >
> > > Did you have a specific application that cannot be met with
> the current
> > > codings?
> > >
> > > --brian
> > >
> > > Barry Nagelberg wrote:
> > >                    (Wed, 28 Jan 2004 13:29:39)
> > > > We have some questions about global titles in SUA.
> > > >
> > > > First, in section 3.10.2.3 of SUA draft 16, the definition for
> > > GTI=0001 does
> > > > not appear to match with ITU-T Q.713 (1996) 3.4.2.3.1.
> > > According to Q.713,
> > > > GTI=0001 means that the global title information only contains
> > > a nature of
> > > > address and the global title address. According to the SUA
> > > draft, GTI=0001
> > > > means that the nature of address is ignored, that the
> > > translation type must
> > > > be 0 (unknown), and that the numbering plan must be 1 (E.164).
> > > What is the
> > > > reason for this difference?
> > > >
> > > > Also, section 3.10.2.3 does not include an encoding scheme
> > > field. The draft
> > > > says "Address signals to be coded as defined in ITU-T Q.713 Section
> > > > 3.4.2.3.1." That section of the ITU specification includes an
> > > example of how
> > > > the digits would be encoded if BCD encoding was used. Does this
> > > mean that
> > > > SUA only supports BCD encoding? If other types of encoding can
> > > be used, how
> > > > is the encoding scheme specified in the global title?
> > > >
> > > > Barry Nagelberg


_______________________________________________
Sigtran mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/sigtran