Re: FW: LS on Clarification of M3UA usage in 3GPPnetworks

chenxu,

chenxu wrote:                             (Mon, 25 Feb 2008 11:39:25)
> Hi,Brian F. G. Bidulock,
> 
>    Thank you for your reply!
> 	
> 
> >chenxu wrote:                                     (Fri, 22 Feb 2008 16:39:37)
> >> 
> >> This scenario isn't the same one that we want to discuss.What we want to
> >> discuss is the scenario that one of the user parts of an AS with an RK=DPC
> >> is unavailable,while DPC is still available£¨The ASPs and AS are in
> >> service.£©.
> >
> >Then your scenario is mis-configured for what you wish to achieve.
> 
> Our scenario isn't mis-configured according to RFC4666.

Then your scenario is mis-configured FOR WHAT YOU WISH TO ACHIEVE.

...which appears to be independence of MTP User parts in a mutliple
SG as STP configuration.  Is this not the case?  If indeed it is,
then why do you not choose the RK that will meet that end?

> According to your previous email, 
> >If one defines an AS with an RK at the granularity of a single
> >Signalling Point Code/Service Indicator (DPC/SI) combination,
> >the user part can live and die independent of other user parts
> >for the same signalling point code.  When the ASP signals
> >ASP-INACTIVE for such an RC, the single user part becomes
> >unavailable (and the SG would be expected to mark the user part
> >unavailable if there are no other ASP serving the AS and no
> >other routes to an "Alias" SP serving the same single user
> >part, and potentially send UPU toward the SS7 network and DUPU
> >toward ASPs serving the SPs sending traffic to the user part.)
> 
> In that scenario,an IPSEP needs to  send
>    an ASP Inactive message to the SGP.But this requirement isn't described
> in RFC4666 ASP-inactive procedure.  So the realization of that
> scenario still needs further study or protocol extention.

No,

> Here is the description of the ASP inactive message application in RFC4666/4.3.4.4.
> 
>  ¡°When an ASP wishes to withdraw from receiving traffic within an AS or
>    the ASP wants to initiate the process of deactivation, the ASP sends
>    an ASP Inactive message to the SGP or IPSP. '

Simply put, for an RK of DPC/SI the "traffic within an AS" is the
user part traffic corresponding to the SI value of the routing key
at the point code corresponding to the DPC in the routing key, which
would be an individual user part, which is what you are trying to
accomplish incorrectly by wanting to send DUPU in the wrong direction.
That the RK of DPC/SI corespond to user part traffic is obvious.
Why do you try to state a case contrary to the obvious?

Ok, I will spell it out in the hope that you are sincerely confused
and not just being obtuse.

Say you have two MTP User Parts: ISUP (SI=5) and SCCP (SI=3) at a
signalling point, say DPC=1-2-3.  Your ASP (mislabelled as SPn in
your diagram), has two AS's AS1/RK1/RC1 and AS2/RK2/RC2, where
RK1=1-2-3:3,RC=3 (SCCP) and RK2=1-2-3:5,RC=5 (ISUP).

Under normal operation, both AS are active and processing traffic
between the ASP and an SG.  When the SG receives messages for
1-2-3:3 (SCCP) it delivers them to AS1 at the ASP using RC1; when
the SG receives messages for 1-2-3:5 (ISUP) it deliveres them to AS2
at the ASP using RC2; when the SG receives messages for 1-2-3:4 (TUP)
the SG responds with UPU (unequipped, SI=4).

When, say, SCCP becomes unavailable at the ASP (e.g. some
application process has failed and is restarting), the ASP sends ASP
Inactive to the SG for RC1=3.  The SG thus, knowing that the SCCP
User part is no longer available for 1-2-3, responds to messages
received for 1-2-3:3 (SCCP) with UPU (unavailable,SI=3); however, as
AS2 is still active, the SG will continue to deliver messages for
1-2-3:5 (ISUP) to AS2 at the ASP with RC2=5.

Answer me now: Is this not what you were trying to accomplish?
That is, causing the SG to send UPU (unavailable,SI=n) when some
user part became unavailable at an ASP?

--brian

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