Re: Upper boundary of Adaptation Layers

Stanislav,

No, the N-STATE Request does not necessarily originate at the Subsystem
(SCCP-User).  This is particularly true of TCAP, which separates these
management functions from the user functions.

Also not that N-STATE Request does not have sufficient information for
SCCP to do its job.  It must be determined whether an out of service
subsystem is a transient or permanent condition.  Furthermore, a
separate interface than that used to transfer data on a connection
(CONS) must be used to signal that a connection-oriented subsystem is
out of service, and again, it must be signalled whether it is a
transient or permanent condition.  Although TCAP can bind to multiple
NSAPs for the same subsystem, and each can receive N-STATE indication,
N-STATE request must is sent by a separate management function.

Nevertheless, your SCCP-User at the ASP can issue N-STATE Request to SUA
at the ASP to its heart's content.  SUA will translate this to ASP
Active/Inactive.  At the SG, the SG is responsible for determining the
availability of the subsystem (from AS availablility) and issuing local
N-STATE Requests as necessary.  At the SG, N-STATE Request does not come
from the user, it is generated by the NIF to present a single management
view of the subsystem to the SS7 network and other SCCP users.

--brian

Stanislav Ivanovich wrote:                      (Mon, 09 Jan 2006 14:53:55)
> 
>    Brian,
> 
> 
> 
>    You    actually    confirm    my   point   ->   attaching/deattaching,
>    activation/deactivation...  all  of  these activities are performed by
>    non-SCCP functionality, i.e. it is not SCCP that attaches or activates
>    an  SCCP  subsystem but user that attaches to the service or activates
>    itself  for  the  traffic  exchanged with the service! Users attach to
>    service not vice versa!
> 
> 
> 
>    You cannot also find in SCCP specifications that SCCP service attaches
>    local users...
> 
> 
> 
> 
> 
>    Anyway, our dispute was that according to you N-STATE_request is not a
>    primitive  between SCCP and SCCP-user but between SCCP and SCCP-LM. As
>    I  showed  this  is  not  the  case but instead as I pointed it is the
>    primitive between SCCP and SCCP-user application!
> 
> 
> 
>    By  the  way,  are  you  saying that N-STATE_request from an SCCP-user
>    application   should   not   generate   ASP_INACTIVE on  the  external
>    interface??? Do  you remember our last week's discussion about this ->
>    your    point   was   that   ASP is   not   allowed   to   send   DUNA
>    reflecting N-STATE_request   but   instead  that  is  to  be  done  by
>    ASP_ACTIVE/INACTIVE? Look at
>    [1]http://www1.ietf.org/mail-archive/web/sigtran/current/msg05667.html
> 
> 
> 
> 
> 
>    best regards/ Stanislav Ivanovich


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