Subject: RE: SUA ver05 query

From: [email-masked]
Date: Mon, 5 Mar 2001 08:05:42 +0200

Hi Nitin,

> Is the SUA version 06 draft is in pipeline? if so, by what 
> time it'll be out,

I sent it out on Friday - hopefully it will be announced soon.

> Also, do we have any plans for SUA Bake-off event in the 
> near future or so?

This has to be seen.  Unfortunately, I've been overloaded with
other work, so my implementation of SUA has not progressed.
However, if someone wants to volunteer to hold an SUA 
bakeoff, please let me know.

cheers,
John

---

From: "Sidebottom, Greg [BCNR:7M01:EXCH]" <[email-masked]>
Date: Thu, 22 Mar 2001 02:46:28 -0500

Hi Nitin,

I didn't see a response to this so I'll take a stab ...

 -----Original Message-----
From: 	Tomar, Nitin [mailto:[email-masked]] 
Sent:	Wednesday, February 28, 2001 3:35 PM
To:	[email-masked]
Subject:	SUA ver05 query

> I'm having couple of queries on SUA ver05 draft,
> 
> 1.The section 5.1.2.1 shows ASP initiating a DAUD. Is this correct?

[Greg] Not for this case.

> When can a SUA layer at SG or ASP will send a SCMG (SST) message?
> 
> to my understanding, once SG sends a SCMG(SSP) to ASP, the ASP will
> initiate 
> periodically the SCMG(SST) towards the SG and *NOT* the DAUD,
> the SUA at SG in turn indicate the SCCP at SG to send the SST toward the
> SS7 node 
> initiating SSP.
> Also in the ASP to SG direction whenever a SCMG(SSP) is sent for a Sub
> System on
> ASP the SG shall initiate the SCMG(SST) message toward the ASP initiating
> SCMG(SSP).
> 

[Greg] Hmmm, Section 5.1.2.1 has some serious errors in it.  

1) The heading is "SEP failover" but the subsequent text is not about SEP
failover but rather about reception of an SCCP Subsystem Prohibited (SSP)
message.

2) The text talks about incoming SSPs being translated to a DUNA (but this
is not shown in the diagram).  This is incorrect anyway as SSPs are consumed
by the SCCP (SCMG) layer of the SG, whose job it is to keep the state of
remote SS7 subsystems.  The right indication to a concerned ASP is for the
SG to send the equivalent of the N-STATE indication primitive.  A DUNA would
be appropriate if the SCCP wants to inform the ASP of the unavailability of
a remote point code (i.e., the equivalent of the N-PCSTATE indication).

3) The indications of subsystem availability from the SG to a concerned ASP
is not an SCMG message as there is no SCCP peer at the ASP.  I think we
should change the name of these SUA messages so we do not confuse them with
the SCCP SSP and SSA messages.

4) Based on this indication the ASP must not generate a periodic DAUD *nor*
SCMG (SST) to the SG.  The SG will know when the subsystem becomes available
again and will send an indication at that time.   This is because it is the
SG SCMG that starts the SST procedures to the SS7 network (it is not
triggered by the SG reception of a DAUD or SCMG(SST).

So 5.1.2.1 should be:

        ASP-a1            ASP-a2                SG                  SEP
      (Primary)           (Backup)
                                                 <--------SSP--------+
         <-----------------SCMG(SSP)*------------+(start SST procedure per
Q.714
                                                 +
                                                 +      (Timer)
              * - New Name?                      +
                                                 +--------SST-------->
                                                 +

When the subsystem returns:

        ASP-a1            ASP-a2                SG                  SEP
      (Primary)           (Backup)
                                                 <--------SSA--------+
         <-----------------SCMG(SSA)*------------+(stop SST procedure per
Q.714
                                                 +
                                                 +     
              * - New Name?                      +

A further point: If the ASP wants to audit the status of a subsystem in the
SS7 network it can send an SCMG (SST) - please give this a new name! - to
the SG and it will respond based on the SG SCMG knowledge.  No SST is
generated into the SS7 network - this would actually be contrary to the SCCP
spec which does not specify an autonomous SST.  SSTs are only generated in
response to received SSPs.  There is a further complication here that we
have not yet considered - the SCCP SCMG at the SG does not maintain the
status of all subsystems in the SS7 network, only a small subset of remote
subsystems that it needs to keep track of.  So it is possible for an ASP to
enquire of the status of a remote subsystem and the SG simply does not know
- we need to add the capability to respond with "unknown status".  The same
point can be made for DAUD with respect to destination PC availability.

Anyway, if people agree with me then we need to reflect all this in the
procedures, not just in the message flow diagrams.

> 
> 2. Referring to one of the old threads of discussion on SCMG messages, Is
> 
> the DUPU message is not going to be used in SUA at all?
> 
> - Nitin
>   Trillium Digital Sys Inc., an Intel Company,
>   Los Angeles, CA.

[Greg] Good question - I don't remember the old thread but I'd say that
remoter User Part Unavailability is treated in the SCCP as equivalent to
Signalling Point Prohibited.  If the SG SCCP is informed of a remote User
Part Unavailability = SCCP, then you get a local broadcast to the SCCP Users
of "user-out-of-service" and "signalling point inaccessible" per Q.714
Sections 5.3.6.2 and 5.3.6.4.  So the SUA should treat this like any other
N-STATE indication and N-PC-STATE indications - a special DUPU message is
not required.

Regards,

   Greg

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