home *** CD-ROM | disk | FTP | other *** search
/ Internet Standards / CD2.mdf / ccitt / 1992 / q / q714.asc < prev    next >
Text File  |  1991-12-31  |  131KB  |  2,202 lines
  1.          Recommendation Q.714
  2.                     SIGNALLING CONNECTION CONTROL PART PROCEDURES
  3.          1      Introduction
  4.          1.1    General characteristics of signalling connection control procedures
  5.          1.1.1  Purpose
  6.                This Recommendation describes the procedures performed  by  the  Signalling
  7.          Connection Control Part (SCCP)  of  Signalling  System  No.  7  to  provide  both
  8.          connection-oriented and connectionless  network  services,  and  SCCP  management
  9.          services as defined in Recommendation Q.711. These procedures  make  use  of  the
  10.          messages  and  information  elements  defined  in  Recommendation  Q.712,   whose
  11.          formatting and coding aspects are specified in Recommendation Q.713.
  12.          1.1.2  Protocol classes
  13.                The protocol used by the SCCP to provide  network  services  is  subdivided
  14.          into four protocol classes, defined as follows:
  15.                -   Class 0: Basic connectionless class
  16.                -   Class 1: Sequenced (MTP) connectionless class
  17.                -   Class 2: Basic connection-oriented class
  18.                -   Class 3: Flow control connection-oriented class
  19.                The connectionless protocol classes provide  those  capabilities  that  are
  20.          necessary  to  transfer  one  Network  Service  Data  Unit  (NSDU),  (i.e.,   one
  21.          user-to-user information block) in the user data field of a Unitdata message. The
  22.          maximum length of a NSDU is  restricted  to  X  octets1),  since  segmenting  and
  23.          reassembly are not provided by protocol classes 0 and 1.
  24.                The  connection-oriented  protocol  classes  (protocol  classes  2  and  3)
  25.          provide segmenting and reassembly capabilities. If a Network Service Data Unit is
  26.          longer than 255 octets, it is split into multiple  segments  at  the  originating
  27.          node, prior to transfer in the "data" field of Data  messages.  Each  segment  is
  28.          less than or  equal  to  255  octets.  At  the  destination  node,  the  NSDU  is
  29.          reassembled.
  30.          1.1.2.1   Protocol class 0
  31.                Network Service Data Units passed by higher layers to the SCCP in the  node
  32.          of origin are delivered by the SCCP to higher layers  in  the  destination  node.
  33.          They are  transported  independently  of  each  other.  Therefore,  they  may  be
  34.          delivered out-of-sequence. Thus,  this  protocol  class  corresponds  to  a  pure
  35.          connectionless network service.
  36.          1.1.2.2   Protocol class 1
  37.                In protocol class 1, the  features  of  class  0  are  complemented  by  an
  38.          additional  feature  (i.e.,  sequence  control  parameter  associated  with   the
  39.          N-UNITDATA request primitive) which allows the higher layer to  indicate  to  the
  40.          SCCP that a  given  stream  of  NSDUs  have  to  be  delivered  in-sequence.  The
  41.          Signalling Link Selection (SLS) field is chosen by SCCP based on the value of the
  42.          sequence control parameter. The SLS chosen for a stream of NSDUs  with  the  same
  43.          sequence control parameter will be identical.  The  SCCP  will  then  encode  the
  44.          Signalling Link Selection (SLS) field in the routing label of  messages  relating
  45.          to such NSDUs, so that their sequence is, under normal conditions, maintained  by
  46.          the signalling network as defined  in  Recommendation  Q.704.  Thus,  this  class
  47.          corresponds to an enhanced connectionless service, where an additional sequencing
  48.          feature is included.
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61.  
  62.  
  63.                1) Due to the ongoing studies on the SCCP called and calling party address, the maximum of
  64.            this value needs further study. It is also noted that the transfer of up to 255  octets
  65.            of user data is allowed when the SCCP called and calling party address do  not  include
  66.            global title.
  67.  
  68.  
  69.  
  70.                                                         Fascicle VI.7 - Rec. Q.714   PAGE1
  71.  
  72.                1.1.2.3   Protocol class 2
  73.                In protocol class 2, bidirectional transfer of NSDUs between  the  user  of
  74.          the SCCP in the node of origin and the user of the SCCP in the  destination  node
  75.          is performed by setting up a temporary  or  permanent  signalling  connection.  A
  76.          number of signalling connections may be  multiplexed  onto  the  same  signalling
  77.          relation, as defined in Recommendation Q.704; such a multiplexing is performed by
  78.          using a pair of reference numbers, referred  to  as  "local  reference  numbers".
  79.          Messages belonging to a given signalling connection will contain the  same  value
  80.          of the SLS field to ensure sequencing as  described  in  S  1.1.2.2.  Thus,  this
  81.          protocol class corresponds to a simple connection-oriented network service, where
  82.          SCCP flow control and missequence detection are not provided.
  83.          1.1.2.4   Protocol class 3
  84.                In protocol class 3, the features of protocol class 2 are  complemented  by
  85.          the inclusion of flow control, with its associated capability of  expedited  data
  86.          transfer. Moreover, an additional capability of  detection  of  message  loss  or
  87.          mis-sequencing is included; in such a circumstance, the signalling connection  is
  88.          reset and a corresponding notification is given by the SCCP to the higher layers.
  89.          1.1.3  Signalling connections
  90.                In  all  connection-oriented  protocol  classes,  a  signalling  connection
  91.          between the nodes of origin and destination may consist of:
  92.                -   a single connection section, or
  93.                -   a number of  connection  sections  in  tandem,  which  may  belong  to
  94.                   different interconnected signalling networks.
  95.                In  the  former  case,  the  originating  and  destination  nodes  of   the
  96.          signalling connection coincide with the originating and destination  nodes  of  a
  97.          connection section. During the connection establishment phase, SCCP  routing  and
  98.          relaying functions, as described in S 2 of this Recommendation, may  be  required
  99.          at one or more intermediate  nodes.  Once  the  signalling  connection  has  been
  100.          established, though, SCCP functions are not required at intermediate nodes.
  101.                In the latter case, at any intermediate node where a  message  is  received
  102.          from a connection section and has to be sent on another connection  section,  the
  103.          SCCP routing and relaying functions are involved during connection establishment.
  104.          In addition, SCCP functions  are  required  at  intermediate  nodes  during  Data
  105.          Transfer  and  Connection  Release  to  provide  the  association  of  connection
  106.          sections.
  107.          1.1.4  Compatibility and handling of unrecognized information
  108.          1.1.4.1   Rules for forward compatibility
  109.                All implementations must recognize all  messages  in  each  protocol  class
  110.          offered, as indicated in Table 1/Q.713.
  111.                General rules for forward compatibility  are  specified  in  Recommendation
  112.          Q.700.
  113.          1.1.4.2   Handling of unrecognized messages or parameters
  114.                Any message with unrecognized message type value should be  discarded.  Any
  115.          unrecognized parameter within a message should be ignored.  Notification  to  the
  116.          originator of the message in these two cases is for further study.
  117.          1.2    Overview of procedures for connection-oriented services
  118.          1.2.1  Connection establishment
  119.                When the SCCP functions  at  the  node  of  origin  receive  a  request  to
  120.          establish a signalling connection, the "called  party  address"  is  analyzed  to
  121.          identify the node towards which a signalling connection  should  be  established.
  122.          The SCCP forwards a Connection Request (CR) message  to  that  signalling  point,
  123.          using the MTP functions.
  124.  
  125.  
  126.  
  127.  
  128.  
  129.  
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136.  
  137.  
  138.  
  139.  
  140.  
  141.          PAGE96  Fascicle VI.7 - Rec. Q.714
  142.  
  143.                The SCCP in the node  receiving  the  CR  message  via  the  MTP  functions
  144.          examines the "called party address" and one of the following actions takes  place
  145.          at the node:
  146.                a)  If the "called party address" contained in the CR message  corresponds
  147.                   to a user located in  that  signalling  point  and  if  the  signalling
  148.                   connection may be established  (i,e.,  establishment  of  a  signalling
  149.                   connection is agreed to by the  SCCP  and  local  user),  a  Connection
  150.                   Confirm (CC) message is returned.
  151.                b)  If the "called party address" does not correspond to  a  user  at  the
  152.                   signalling point, then information available in the message and at  the
  153.                   node are examined to determine whether an association of two connection
  154.                   sections is required at that node.
  155.                   -   If an  association  is  required,  then  the  SCCP  establishes  an
  156.                       (incoming) signalling connection section. Establishment of  another
  157.                       (outgoing) connection section is initiated by sending a CR  message
  158.                       towards the next node and  this  connection  section  is  logically
  159.                       linked to the incoming connection section.
  160.                   -   If coupling of the connection section is not required in this node,
  161.                       no incoming or outgoing connection section  is  established.  A  CR
  162.                       message is forwarded towards the next  destination  using  the  MTP
  163.                       routing function.
  164.                If the SCCP receives a CR message and either the  SCCP  or  the  SCCP  user
  165.          does not wish to establish the  connection,  then  a  Connection  Refused  (CREF)
  166.          message is transferred on the incoming connection section.
  167.                On receipt of a CC message, the SCCP completes the set-up of  a  connection
  168.          section. Furthermore, if coupling of two adjacent connection sections is  needed,
  169.          a further CC message is forwarded to the preceding node.
  170.                If no coupling of adjacent connection sections was needed during set-up  in
  171.          the forward direction, the CC message can be sent directly to the node of  origin
  172.          even if a number of intermediate SCCP nodes was passed in the forward  direction.
  173.          The OPC of the node of origin is transmitted within the "calling  party  address"
  174.          Field.
  175.                When the CR and CC messages have been exchanged between  all  the  involved
  176.          nodes as above described, and the corresponding indications have  been  given  to
  177.          the higher layer functions in the nodes  of  origin  and  destination,  then  the
  178.          signalling connection is established and transmission of messages may commence.
  179.          1.2.2  Data transfer
  180.                Transfer of each NSDU is performed by one or more  Data  (DT)  messages;  a
  181.          more-data indication is used if the NSDU is to be split among more  than  one  DT
  182.          message. If protocol class 3 is used, then SCCP flow  control  is  utilized  over
  183.          each connection section of the signalling connection.  If,  in  such  a  protocol
  184.          class, abnormal conditions are detected, then the appropriate actions  are  taken
  185.          on the signalling connection (e.g., reset). Moreover in such  a  protocol  class,
  186.          expedited data may be sent using one Expedited Data  message  that  bypasses  the
  187.          flow control procedures applying to Data messages.
  188.                A limited amount  of  data  may  also  be  transferred  in  the  Connection
  189.          Request, Connection Refused and Connection Released messages.
  190.          1.2.3  Connection release
  191.                When the signalling connection is  terminated,  a  release  sequence  takes
  192.          place by means of two messages called Released and Release  Complete  (RLC).  The
  193.          RLC message is normally sent in reaction to the receipt of a RLSD message.
  194.          1.3    Overview of procedures for connectionless services
  195.          1.3.1  General
  196.                When the SCCP functions at the node of origin receive from an SCCP user  an
  197.          NSDU to be transferred by the protocol class 0 or 1 connectionless  service,  the
  198.          "called party address" and other relevant parameters, if required,  are  analyzed
  199.          to identify the node towards which the message should be sent. The NSDU  is  then
  200.          included as the "data" parameter in a  Unitdata  (UDT)  message,  which  is  sent
  201.          towards the node using the MTP functions. Upon receipt of the  UDT  message,  the
  202.          SCCP functions at that node perform the routing analysis as described in S  2  of
  203.          this Recommendation and, if the destination of the UDT message is a  local  user,
  204.          deliver the NSDU to the local  higher  layer  functions.  If  the  "called  party
  205.          address" is not at that node, then the UDT message is forwarded to the next node.
  206.          This process continues until the NSDU has reached the "called party address".
  207.  
  208.  
  209.  
  210.  
  211.  
  212.                                                         Fascicle VI.7 - Rec. Q.714   PAGE1
  213.  
  214.                1.4    Structure of the SCCP and contents of specification
  215.                The basic structure of the SCCP appears in Figure 1/Q.714. It  consists  of
  216.          four functional blocks as follows:
  217.                a)  SCCP connection-oriented  control:  its  purpose  is  to  control  the
  218.                   establishment and release of signalling connections and to provide  for
  219.                   data transfer on signalling connections.
  220.                b)  SCCP connectionless  control:  its  purpose  is  to  provide  for  the
  221.                   connectionless transfer of data units.
  222.                c)  SCCP management: its purpose is to provide capabilities, in addition to 
  223.                   the Signalling Route Management and flow control functions of the  MTP,
  224.                   to handle the congestion or failure of either  the  SCCP  user  or  the
  225.                   signalling route to the SCCP user.
  226.                d)  SCCP routing: upon receipt of a message from the MTP or from functions
  227.                   a) or b) above, SCCP routing provides the necessary  routing  functions
  228.                   to either forward the message to the MTP  for  transfer,  or  pass  the
  229.                   message to functions a) or b) above.  A  message  whose  "called  party
  230.                   address" is a local user is passed to  functions  a  or  b,  while  one
  231.                   destined for a remote user is forwarded to the MTP for  transfer  to  a
  232.                   distant SCCP user.
  233.                Section 2 of  this  specification  describes  the  addressing  and  routing
  234.          functions performed by the SCCP. Section  3  specifies  the  procedures  for  the
  235.          connection-oriented services (protocol classes  2-3).  Section  4  specifies  the
  236.          procedures for the connectionless services (protocol classes 0 and 1). Section  5
  237.          specifies the SCCP management procedures.
  238.          2      Addressing and routing
  239.          2.1    SCCP addressing
  240.                The "called and calling party addresses" contain the information  necessary
  241.          for the SCCP to determine an originating and destination node. In the case of the
  242.          connection-oriented procedures, the addresses are the originating and destination
  243.          points of the signalling connection, while in  the  case  of  the  connectionless
  244.          procedures, the addresses are the  originating  and  destination  points  of  the
  245.          message.
  246.                When  transferring  connection-oriented  or  connectionless  messages,  two
  247.          basic categories of addresses are distinguished by SCCP routing:
  248.                1)  Global Title - A global title is an address, such  as  dialled-digits,
  249.                   which does not explicitly contain information that would allow  routing
  250.                   in the signalling network, that is the translation function of the SCCP
  251.                   is  required.  This  translation  function  could  be  performed  on  a
  252.                   distributed basis or on a centralized basis. The  last  case,  where  a
  253.                   request for translation is sent to a  centralized  data  base,  may  be
  254.                   accomplished, for example, with  transaction  capabilities  (TC).  This
  255.                   matter is for further study.
  256.                   In case of an E.164-based global  title  with  the  nature  of  address
  257.                   indicator included, the sending sequence of address information will be
  258.                   the country code, followed by the national (significant) number. Within
  259.                   the destination signalling network, the address information may be  the
  260.                   subscriber number or the national (significant) number,  by  choice  of
  261.                   the  value  of  nature  of  address  indicator,  as  required  by   the
  262.                   administration concerned.
  263.                2)  DPC + SSN - A Destination Point Code and Subsystem Number allows direct 
  264.                   routing by the SCCP and MTP, that is, the translation function  of  the
  265.                   SCCP is not required.
  266.          2.2    SCCP routing principles
  267.                The  SCCP  routing  control  (SCRC)  receives  messages  from  the  Message
  268.          Transfer Part for routing and discrimination, after they have  been  received  by
  269.          the MTP from another node in the signalling network. SCRC also receives  internal
  270.          messages from SCCP connection-oriented control (SCOC) and connectionless  control
  271.          (SCLC) and performs any necessary routing functions (e.g.,  address  translation)
  272.          before passing them to the MTP for transport in the signalling network or back to
  273.          the SCCP connection-oriented or connectionless control.
  274.                                         Figure 1/Q.714 - T1113290-88
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282.  
  283.          PAGE96  Fascicle VI.7 - Rec. Q.714
  284.  
  285.                2.2.1  Receipt of SCCP message transferred by the MTP
  286.                A message transferred by the MTP that requires  routing  will  include  the
  287.          "called party address" parameter giving  information  for  routing  the  message.
  288.          These messages currently include the Connection Request message and all types  of
  289.          connectionless messages. Other messages are passed to connection-oriented control
  290.          for processing.
  291.                If the "called party address" parameter is used for routing,  it  can  take
  292.          the following information:
  293.                1)  Subsystem Number (SSN) only - This indicates that the receiving SCCP is 
  294.                   the termination point of the message. The SSN is used to determine  the
  295.                   local subsystem.
  296.                2)  Global Title (GT) only - This indicates that translation is  required.
  297.                   Translation of the Global Title results in a new destination point code
  298.                   (DPC) for routing the message, and possibly a new SSN or GT or both  in
  299.                   the "called party address".
  300.                3)  SSN + GT - In this case, the address indicator information is used  to
  301.                   determine whether the SSN or the GT should  be  used  for  routing  and
  302.                   processing via items 1) or 2) above, respectively.
  303.          2.2.2  Messages  from  connection-oriented  or  connectionless  control  to  SCCP
  304.                routing control
  305.                Addressing information, indicating  the  destination  of  the  message,  is
  306.          included  with  every  internal  message  received  from  connection-oriented  or
  307.          connectionless control. For connectionless messages, this addressing  information
  308.          is obtained from the "called address" parameter associated  with  the  N-UNITDATA
  309.          REQUEST primitive. For Connection-Request messages received by SCCP routing,  the
  310.          addressing information is obtained from the "Called address" parameter associated
  311.          with the N-CONNECT REQUEST primitive. For connection-oriented messages other than
  312.          a Connection Request message, the addressing information (i.e., the DPC) is  that
  313.          associated with the connection section. The addressing information can  take  the
  314.          following forms:
  315.                1)  DPC
  316.                2)  DPC + (SSN or GT or both)
  317.                3)  GT
  318.                4)  GT + SSN
  319.                The  first  form  applies  to  connection-oriented  messages   except   the
  320.          Connection Request message. The last three forms apply to connectionless messages
  321.          and to the Connection Request message.
  322.          2.2.2.1   DPC present
  323.                If the DPC is present in  the  addressing  information,  then  the  DPC  is
  324.          passed to the MTP using the MTP-TRANSFER request primitive and:
  325.                1)  if no other addressing information  is  available,  no  "called  party
  326.                   address" is provided in the message;
  327.                2)  if a SSN or GT or both are available, this information is used in  the
  328.                   "called party address" with an indication of which is to  be  used  for
  329.                   routing.
  330.                If the DPC is the node itself,  then  the  information  is  passed  to  the
  331.          specified internal subsystem.
  332.          2.2.2.2   Translation required
  333.                If the DPC is not present, then a  global  title  translation  is  required
  334.          before the message can be sent out. Translation results in a DPC and  possibly  a
  335.          new SSN or new GT or both. If the GT and/or SSN resulting  from  a  global  title
  336.          translation is different from the GT and/or SSN which was previously included  in
  337.          the called party address, the newly produced GT and/or SSN replaces the  existing
  338.          one. The routing procedures then continue as per S 2.2.2.1
  339.          2.3    SCCP routing
  340.                The SCCP routing functions  are  based  on  information  contained  in  the
  341.          "called party address".
  342.  
  343.  
  344.  
  345.  
  346.  
  347.  
  348.  
  349.  
  350.  
  351.  
  352.  
  353.  
  354.                                                         Fascicle VI.7 - Rec. Q.714   PAGE1
  355.  
  356.                2.3.1  Receipt of SCCP message transferred by the MTP
  357.                One of the following actions is taken by SCCP routing  upon  receipt  of  a
  358.          message from the Message Transfer Part. The message is received by the SCCP  when
  359.          the MTP invokes a MTP-TRANSFER INDICATION.
  360.                1)  If the message is a connection-oriented message other than a Connection 
  361.                   Request  (CR)  message,  then  SCCP  routing  passes  the  message   to
  362.                   connection-oriented control.
  363.                2)  If the routing indicator  in  the  "called  party  address"  does  not
  364.                   indicate route on global title, then SCCP routing checks the status  of
  365.                   the subsystem.
  366.                   a)  If the subsystem is available, the message is passed, based on  the
  367.                       message   type,   to   either   connection-oriented   control    or
  368.                       connectionless control.
  369.                   b)  If the system is unavailable and:
  370.                       -   the message is a connectionless message, then the message return 
  371.                          procedure is initiated;
  372.                       -   the message is a connection-oriented message  (a  CR  message),
  373.                          then the connection refusal procedure is initiated.
  374.                      In  addition,  if  the  subsystem  is  failed,  SCCP  management  is
  375.                       notified that a message was received for a failed subsystem.
  376.                3)  If the routing indicator in the "called party address" indicates route
  377.                   on global title, a translation of the global title must be performed.
  378.                   a)  If the translation of the global title exists, and both the DPC and
  379.                       SSN are determined, then:
  380.                       i)  if the DPC is the node itself, then the procedures in 2)  above
  381.                          are followed;
  382.                       ii) if the DPC is  not  the  node  itself,  the  DPC  and  SSN  are
  383.                          available, and the message is a connectionless message, then the
  384.                          MTP-TRANSFER REQUEST primitive is invoked;
  385.                       iii) if the DPC is not  the  node  itself,  the  DPC  and  SSN  are
  386.                          available, and the message  is  a  connection-oriented  message,
  387.                          then:
  388.                          - if an association of  connection  sections  is  required,  the
  389.                            message is passed to connection-oriented control;
  390.                          - if no association of  connection  sections  is  required,  the
  391.                            MTP-TRANSFER REQUEST primitive is invoked;
  392.                       iv) if the DPC is not the node itself, and the DPC and/or  SSN  are
  393.                          not available and
  394.                          - the message is a  connectionless  message,  then  the  message
  395.                            return procedure is initiated;
  396.                          - the message is a connection-oriented message (a  CR  message),
  397.                            then the connection refusal procedure is initiated.
  398.                   b)  If the translation of the global title exists and only a DPC or DPC
  399.                       + new GT is determined, then:
  400.                       i)  if the DPC is available, and the message  is  a  connectionless
  401.                          message, then the MTP-TRANSFER REQUEST primitive is invoked;
  402.                       ii)  if  the   DPC   is   available,   and   the   message   is   a
  403.                          connection-oriented message, then:
  404.                          - if an association of the connection sections is required, then
  405.                            the message is passed to connection-oriented control;
  406.                          - if no association of the connection section is required,  then
  407.                            the MTP-TRANSFER REQUEST primitive is invoked.
  408.                       iii) if the DPC is not available and
  409.                          - the message is a  connectionless  message,  then  the  message
  410.                            return procedure is initiated;
  411.                          - the message is a connection-oriented message (a  CR  message),
  412.                            then the connection refusal procedure is initiated.
  413.                   c)  If the translation of the global title does not exist, and
  414.                       -   the message is a connectionless message, then the message return 
  415.                          procedure is initiated;
  416.                       -   the message is a connection-oriented message  (a  CR  message),
  417.                          then the connection refusal procedure is initiated.
  418.  
  419.  
  420.  
  421.  
  422.  
  423.  
  424.  
  425.          PAGE96  Fascicle VI.7 - Rec. Q.714
  426.  
  427.                2.3.2  Messages from connectionless or connection-oriented control to SCCP
  428.                routing control
  429.                One of the following actions is taken by SCCP routing  upon  receipt  of  a
  430.          message from connectionless control or connection-oriented control.
  431.                1)  If the message is a Connection Request message at an intermediate node
  432.                   (where connection sections are being associated), and:
  433.                   a)  the DPC is available, then the MTP-TRANSFER  REQUEST  primitive  is
  434.                       invoked;
  435.                   b)  the DPC is not available, then the connection refusal procedure  is
  436.                       initiated.
  437.                2)  If the message is a connection-oriented message other than a Connection 
  438.                   Request message, and:
  439.                   a)  the DPC is available, then the MTP-TRANSFER  REQUEST  primitive  is
  440.                       invoked;
  441.                   b)  the DPC is not available, then the connection release procedure  is
  442.                       initiated.
  443.                3)  If the "Called address" in the primitive associated with a  Connection
  444.                   Request or connectionless message includes a DPC, and:
  445.                   a)  the DPC and  SSN  are  available,  then  the  MTP-TRANSFER  REQUEST
  446.                       primitive is invoked;
  447.                   b)  the DPC and/or SSN are not available, then:
  448.                       -   for connectionless messages, the message  return  procedure  is
  449.                          initiated;
  450.                       -   for connection-oriented messages (CR messages), the  connection
  451.                          refusal procedure is initiated.
  452.                   c)  the DPC is the node itself, then the  procedures  in  S  2.3.1,  2)
  453.                       above are followed.2)
  454.                4)  If the "Called address" in the primitive associated with a  Connection
  455.                   Request or connectionless message  does  not  include  a  DPC,  then  a
  456.                   translation of the global title must be performed.
  457.                   a)  If the translation of the global title exists, and both the DPC and
  458.                       SSN are determined, then:
  459.                       i)  if the DPC is the node itself, then the procedures in S  2.3.1,
  460.                          2), above are followed.
  461.                       ii) if the DPC is not the node itself and DPC and SSN are available, 
  462.                          then the MTP-TRANSFER REQUEST primitive is invoked;
  463.                       iii) if the DPC is not the node itself, and the DPC and/or SSN  are
  464.                          not available and:
  465.                          - the message is a  connectionless  message,  then  the  message
  466.                          return procedure is initiated;
  467.                          - the message is a connection-oriented message (a  CR  message),
  468.                            then the connection refusal procedure is initiated.
  469.                   b)  If the translation of the global title exists and only a DPC or DPC
  470.                       + new GT is determined, then
  471.                       i)  if the DPC is available, then the MTP-TRANSFER REQUEST primitive 
  472.                          is invoked;
  473.                       ii) if the DPC is not available and:
  474.                          - the message is a  connectionless  message,  then  the  message
  475.                            return procedure is initiated;
  476.                          - the message is a connection-oriented message (a  CR  message),
  477.                            then the connection refusal procedure is initiated.
  478.                   c)  If the translation of the global title does not exist, and:
  479.                       -   the message is a connectionless message, then the message return 
  480.                          procedure is initiated;
  481.                       -   the message is a connection-oriented message  (a  CR  message),
  482.                          then the connection refusal procedure is initiated.
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.          2) The function of routing between local subsystems is implementation dependent.
  493.  
  494.  
  495.  
  496.                                                         Fascicle VI.7 - Rec. Q.714   PAGE1
  497.  
  498.                2.4    Routing failures
  499.                The SCCP recognizes a  number  of  reasons  for  failure  in  SCCP  routing
  500.          control. Examples of these reasons are:
  501.                1)  translation does not exist for addresses of this nature;
  502.                2)  translation does not exist for this specific address;
  503.                3)  network/subsystem failure;
  504.                4)  network/subsystem congestion, and
  505.                5)  unequipped user.
  506.                The precise classification  of  the  causes  by  which  such  failures  are
  507.          recognized is for further study.
  508.                When  SCCP  routing  is  unable  to  transfer  a   message   due   to   the
  509.          unavailability of a Point Code or Subsystem, one of above reasons is indicated in
  510.          the Connection Refused message, the Connection Released message or  the  Unitdata
  511.          Service message.
  512.          3      Connection-oriented procedures
  513.          3.1    Connection establishment
  514.          3.1.1  General
  515.                The connection establishment procedures consist of the  functions  required
  516.          to  establish  a  temporary  signalling  connection  between  two  users  of  the
  517.          Signalling Connection Control Part.
  518.                The connection establishment procedures are initiated by  a  SCCP  user  by
  519.          invoking the N-CONNECT request primitive.
  520.                The ISDN-UP may initiate an SCCP connection in the same way  as  any  other
  521.          user, but may also request the SCCP to  initiate  a  connection  and  return  the
  522.          information to the ISDN-UP for transmission in a call set-up message.
  523.                The signalling connections between two users of the  Signalling  Connection
  524.          Control Part, which are referred to by the "Called/Calling address" parameters in
  525.          the N-CONNECT REQUEST primitive, may be realized by the establishment of  one  or
  526.          more connection sections. The SCCP user is not aware of how the SCCP provides the
  527.          signalling connection (e.g. by one or more than one connection sections).
  528.                The realization of a signalling connection between two SCCP users then  can
  529.          be described by the following components:
  530.                1)  one or more connection sections;
  531.                2)  an originating node, where the "Calling address" is located;
  532.                3)  zero or more intermediate nodes, where, for this signalling connection, 
  533.                   there is no distribution to a SCCP user; and
  534.                4)  a destination node, where the "Called address" is located.
  535.                The Connection Request message and the Connection Confirm message are  used
  536.          to set up connection sections.
  537.          3.1.2  Local reference numbers
  538.                During  connection  establishment  both  a  source  and  destination  local
  539.          reference number are assigned independently to a connection section.
  540.                Source and destination local reference numbers are assigned  at  connection
  541.          section set-up for a permanent connection section.
  542.                Once the destination reference number is known, it  is  a  mandatory  field
  543.          for all messages transferred on that connection section.
  544.                Each node will select the local reference that will be used by  the  remote
  545.          node as the destination local reference number field on a connection section  for
  546.          data transfer.
  547.                The local reference numbers remain unavailable for use on other  connection
  548.          sections until the connection section is released and the reference  numbers  are
  549.          removed from their frozen state. See also S 3.3.2.
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562.  
  563.  
  564.  
  565.  
  566.  
  567.          PAGE96  Fascicle VI.7 - Rec. Q.714
  568.  
  569.                3.1.3  Negotiation procedures
  570.          3.1.3.1   Protocol class negotiation
  571.                During connection establishment it is possible to  negotiate  the  protocol
  572.          class of a signalling connection between two SCCP users.
  573.                The N-CONNECT REQUEST primitive  contains  a  parameter,  the  "Quality  of
  574.          service parameter set", with the preferred quality of  service  proposed  by  the
  575.          SCCP user for the signalling connection.
  576.                The SCCP at the originating, intermediate and destination nodes  may  alter
  577.          the protocol class on a signalling connection so  that  the  quality  of  service
  578.          assigned to the signalling connection is less restrictive (e.g., a protocol class
  579.          2 connection may be provided if a  protocol  class  3  connection  is  proposed).
  580.          Information concerning the present proposed protocol class  within  the  SCCP  is
  581.          carried in the Connection Request message and the assigned protocol class appears
  582.          in the Connection Confirm message.
  583.                At the destination node the SCCP user is notified of the proposed  protocol
  584.          class using the N-CONNECT INDICATION primitive.
  585.                The protocol class of a signalling connection may also be  altered  by  the
  586.          Called SCCP user in the same manner (i.e. less  restrictive)  when  invoking  the
  587.          N-CONNECT RESPONSE primitive.
  588.                The Calling SCCP user is informed of the quality  of  service  selected  on
  589.          the signalling connection using the N-CONNECT CONFIRMATION primitive.
  590.          3.1.3.2   Flow control credit negotiation
  591.                During connection establishment it is  possible  to  negotiate  the  window
  592.          size to be used on a signalling connection for the purpose of flow control.  This
  593.          window size remains fixed for the life of the signalling connection.  The  credit
  594.          field in the CONNECTION REQUEST  and  CONNECTION  CONFIRM  messages  is  used  to
  595.          indicate the window size.
  596.                The N-CONNECT REQUEST primitive  contains  a  parameter,  the  "Quality  of
  597.          service parameter set" with the preferred quality of service proposed by the SCCP
  598.          user for the signalling connection.
  599.                The SCCP at the originating, intermediate and destination nodes  may  alter
  600.          the window size on a  signalling  connection  so  that  the  quality  of  service
  601.          assigned to the signalling connection is less restrictive (e.g., a smaller window
  602.          size may be provided). Information concerning the present  proposed  window  size
  603.          within the SCCP is carried in the Connection Request  message  and  the  assigned
  604.          window size appears in the Connection Confirm message.
  605.                At the destination node the SCCP user is notified of  the  proposed  window
  606.          size using the N-CONNECT indication primitive.
  607.                The window size of a signalling connection  may  also  be  altered  by  the
  608.          Called SCCP user in the same manner (i.e. less  restrictive)  when  invoking  the
  609.          N-CONNECT RESPONSE primitive.
  610.                The Calling SCCP user is informed of the quality  of  service  selected  on
  611.          the signalling connection using the N-CONNECT confirm primitive.
  612.          3.1.4  Actions at the origination node
  613.          3.1.4.1   Initial actions
  614.                The N-CONNECT REQUEST  primitive  is  invoked  by  the  SCCP  user  at  the
  615.          originating node to request the establishment of a signalling connection  to  the
  616.          "Called address" contained in the primitive. The node determines if resources are
  617.          available.
  618.                If resources are not available, then the connection  refusal  procedure  is
  619.          initiated.
  620.                If resources are available, then the following actions take  place  at  the
  621.          originating node:
  622.                1)  A source local reference number and an SLS code are  assigned  to  the
  623.                   connection section.
  624.                2)  The "Called address" is associated with the connection section.
  625.                3)  The proposed protocol class is determined for the connection section.
  626.  
  627.  
  628.  
  629.  
  630.  
  631.  
  632.  
  633.  
  634.  
  635.  
  636.  
  637.  
  638.                                                         Fascicle VI.7 - Rec. Q.714   PAGE1
  639.  
  640.                4)  If the protocol class provides for flow control, then an initial credit 
  641.                   is indicated in the Connection Request message.
  642.                5)  The Connection Request message is then forwarded to the  SCCP  routing
  643.                   function for transfer.
  644.                6)  A timer T(conn est) is started.
  645.                The ISDN-UP may request the SCCP to set up  a  SCCP  signalling  connection
  646.          and return the information normally carried in a Connection  request  message  to
  647.          the ISDN-UP for transmission in a call set-up message.
  648.                When the ISDN-UP notifies the SCCP of the need for  the  connection,  using
  649.          the REQUEST Type 1 interface  element,  the  SCCP  determines  if  resources  are
  650.          available.
  651.                If resources are not available, then the connection  refusal  procedure  is
  652.          initiated. If resources are available, then the following actions take  place  at
  653.          the origination node:
  654.                1)  A source local reference number and an SLS code  is  assigned  to  the
  655.                   connection section.
  656.                2)  An indication that the call request is from the ISDN-UP is  associated
  657.                   with the connection section.
  658.                3)  The proposed protocol class is determined for the connection section.
  659.                4)  If the protocol class provides for flow control, then an initial credit 
  660.                   is indicated.
  661.                5)  The information that would normally be included in a Connection Request 
  662.                   message is passed to the ISDN-UP for transfer using the REPLY interface
  663.                   element.
  664.                6)  A timer T(conn est) is started.
  665.          3.1.4.2   Subsequent actions
  666.                When an  originating  node  receives  a  Connection  Confirm  message,  the
  667.          following actions are performed:
  668.                1)  The protocol  class  and  initial  credit  for  flow  control  of  the
  669.                   connection section are updated if necessary.
  670.                2)  The SCCP user is informed  of  the  successful  establishment  of  the
  671.                   signalling connection using the N-CONNECT CONFIRMATION primitive.
  672.                3)  The received local reference number is associated with the  connection
  673.                   section.
  674.                4)  The timer T(conn est) is stopped.
  675.                5)  The inactivity control timers, T(ias) and T(iar), are started.
  676.                When the SCCP user at an origination node invokes the N-DISCONNECT  REQUEST
  677.          primitive, no action is taken prior to receipt  of  a  Connection  Confirm  or  a
  678.          Connection Refused message or expiration of the connection establishment timer.
  679.                When an  originating  node  receives  a  Connection  Refused  message,  the
  680.          connection refusal procedure is completed at the origination node (see S 3.2.3).
  681.                When the connection establishment timer at the  origination  node  expires,
  682.          the N-DISCONNECT INDICATION primitive is invoked, the resources  associated  with
  683.          the connection section are released, and the local reference number is frozen.
  684.          3.1.5  Actions at an intermediate node
  685.          3.1.5.1   Initial actions
  686.                When a Connection Request message is  received  at  a  node  and  the  SCCP
  687.          routing and discrimination function determines that the "called party address" is
  688.          not a local SCCP user  and  that  a  coupling  is  required  at  this  node,  the
  689.          intermediate  node  determines  if  resources  are  available  to  establish  the
  690.          connection section.
  691.                If resources are not available at the node,  then  the  connection  refusal
  692.          procedure is initiated.
  693.  
  694.  
  695.  
  696.  
  697.  
  698.  
  699.  
  700.  
  701.  
  702.  
  703.  
  704.  
  705.  
  706.  
  707.  
  708.  
  709.          PAGE96  Fascicle VI.7 - Rec. Q.714
  710.  
  711.                If resources are available at the node,  then  the  following  actions  are
  712.          performed:
  713.                1)  A local reference number and an SLS code are assigned to the  incoming
  714.                   connection section. (Note  -  As  an  implementation  option,  a  local
  715.                   reference number may be assigned later upon reception of  a  Connection
  716.                   Confirm message.)
  717.                2)  A connection section is set up to the remote node determined  by  SCCP
  718.                   Routing:
  719.                   -   A local reference number and  an  SLS  code  are  assigned  to  the
  720.                       outgoing connection section.
  721.                   -   The protocol class is proposed.
  722.                   -   An initial credit for flow control is assigned, if appropriate.
  723.                   -   The Connection Request message is forwarded  to  the  SCCP  Routing
  724.                       with the same addressing  information  as  found  in  the  incoming
  725.                       Connection Request message.
  726.                   -   The timer T(conn est) is started.
  727.                3)  An association is made between the incoming  and  outgoing  connection
  728.                   sections.
  729.                The ISDN-UP informs the SCCP that a connection request  has  been  received
  730.          using the REQUEST Type 2 interface element. The ISDN-UP  passes  the  information
  731.          contained in the ISDN-UP set-up message to the SCCP and indicates that a coupling
  732.          is required at this node. The SCCP at the intermediate node  then  determines  if
  733.          resources are available to establish the connection section.
  734.                If resources are not available at the node,  then  the  connection  refusal
  735.          procedure is initiated.
  736.                If resources are available at the node,  then  the  following  actions  are
  737.          performed:
  738.                1)  A local reference number and an SLS code are assigned to the  incoming
  739.                   connection section.
  740.                2)  A local reference number and an SLS code is assigned  to  an  outgoing
  741.                   connection section.
  742.                3)  A protocol class is proposed.
  743.                4)  An initial credit for flow control is assigned if appropriate.
  744.                5)  An association is made between the incoming  and  outgoing  connection
  745.                   sections.
  746.                6)  The information that would normally be included in a conection request
  747.                   message is passed to the ISDN-UP for transfer in  the  REPLY  interface
  748.                   element.
  749.                7)  The timer T(conn est) is started.
  750.          3.1.5.2   Subsequent actions
  751.                When an intermediate  node  receives  a  Connection  Confirm  message,  the
  752.          following actions are performed:
  753.                1)  The source local reference number in the Connection Confirm message is
  754.                   associated with the outgoing connection section.
  755.                2)  The protocol class and credit for the connection section are  assigned
  756.                   and identical  to  those  found  in  the  received  Connection  Confirm
  757.                   message.
  758.                3)  A Connection Confirm message is transferred, using  the  SCCP  routing
  759.                   function, to the originating node of the associated connection section.
  760.                   The protocol class and credit are identical to those indicated  in  the
  761.                   received Connection Confirm message.
  762.                4)  The timer T(conn est) is stopped.
  763.                5)  The inactivity control timers, T(ias) and T(iar), are started.
  764.                When an intermediate  node  receives  a  Connection  Refused  message,  the
  765.          connection refusal procedure is completed at that node (see S 3.2.2).
  766.                When the connection establishment timer expires at  an  intermediate  node,
  767.          the following actions are performed:
  768.                1)  The resources associated with the connection are released.
  769.                2)  The local reference number is frozen (see S 3.3.2).
  770.                3)  If the connection section was established using  a  REQUEST  interface
  771.                   element, then the N-DISCONNECT INDICATION primitive is invoked.
  772.                4)  The connection  refusal  procedure  is  initiated  on  the  associated
  773.                   connection section (see S 3.2.1).
  774.  
  775.  
  776.  
  777.  
  778.  
  779.  
  780.                                                         Fascicle VI.7 - Rec. Q.714   PAGE1
  781.  
  782.                3.1.6  Actions at destination node
  783.          3.1.6.1   Initial actions
  784.                When a Connection Request message is received  at  a  node,  and  the  SCCP
  785.          routing and discrimination function determines that the "called party address" is
  786.          a local user, the destination node  determines  if  resources  are  available  to
  787.          establish the connection section.
  788.                If resources are not available at the node,  then  the  connection  refusal
  789.          procedure is initiated.
  790.                If the resources are available at the node, then the following actions  are
  791.          performed:
  792.                1)  The protocol class is determined for the connection section. (Note - As 
  793.                   an implementation option, a local reference number may also be assigned
  794.                   for the connection section.)
  795.                2)  An initial credit for flow control is assigned if appropriate.
  796.                3)  The node informs the SCCP user of a request to establish a  connection
  797.                   using the N-CONNECT INDICATION primitive.
  798.                When the ISDN-UP informs the  SCCP  that  a  connection  request  has  been
  799.          received using the REQUEST Type 2  interface  element,  the  ISDN-UP  passes  the
  800.          information contained in the ISDN-UP set-up message to the SCCP, and informs  the
  801.          SCCP that the information is for a local user. The SCCP at the  destination  node
  802.          determines if resources are available to establish the connection section.
  803.                If resources are not available at the node,  then  the  connection  refusal
  804.          procedure is initiated.
  805.                If resources are available at the node,  then  the  following  actions  are
  806.          performed:
  807.                1)  The protocol class is determined for the connection section.
  808.                2)  An initial credit for flow control is assigned if appropriate.
  809.                3)  The node informs the ISDN-UP of the request to establish a  connection
  810.                   using the N-CONNECT INDICATION primitive.
  811.          3.1.6.2   Subsequent actions
  812.                When a N-CONNECT RESPONSE primitive is  invoked  by  the  SCCP  user  at  a
  813.          destination node, the following actions are performed:
  814.                1)  A local reference number and an SLS code are assigned to the  incoming
  815.                   connection section.
  816.                2)  The protocol class and credit are updated for the connection section if 
  817.                   necessary.
  818.                3)  A Connection Confirm message is transferred, using  the  SCCP  routing
  819.                   function, to the originating node of the connection section.
  820.                4)  The inactivity control timers, T(ias) and T(iar), are started.
  821.          3.2    Connection refusal
  822.                The purpose of the connection refusal  procedure  is  to  indicate  to  the
  823.          Calling SCCP user function that the attempt to set  up  a  signalling  connection
  824.          section was unsuccessful.
  825.          3.2.1  Actions at node initiating connection refusal
  826.                The connection refusal procedure is initiated by either the  SCCP  user  or
  827.          the SCCP itself:
  828.                1)  The SCCP user at the destination node
  829.                   a)   uses  the  N-DISCONNECT  REQUEST   (originator   indicates   "user
  830.                       initiated") after the SCCP  has  invoked  an  N-CONNECT  indication
  831.                       primitive. This is the case when the SCCP at the  destination  node
  832.                       has received the connection request directly from a preceding SCCP.
  833.                   b)  uses the refusal indicator in the REQUEST Type 2 interface  element
  834.                       when the SCCP user has received the connection request embedded  in
  835.                       a user part message.
  836.  
  837.  
  838.  
  839.  
  840.  
  841.  
  842.  
  843.  
  844.  
  845.  
  846.  
  847.  
  848.  
  849.  
  850.  
  851.          PAGE96  Fascicle VI.7 - Rec. Q.714
  852.  
  853.                   2)  The SCCP initiates connection refusal3) (originator indicates "network 
  854.                   initiated") due to:
  855.                   a)  limited resources at an originating,  intermediate  or  destination
  856.                       node, or
  857.                   b)  expiration of the connection establishment timer at an  originating
  858.                       or intermediate node.
  859.                Initiation of the connection refusal procedure by either the  SCCP  or  the
  860.          user results in the transfer of a Connection Refused message  on  the  connection
  861.          section.  The  refusal  cause  contains  the  value  of  the  originator  in  the
  862.          primitives; if the refusal procedure has been  initiated  by  using  the  refusal
  863.          indicator in the REQUEST Type 2 interface element,  the  refusal  cause  contains
  864.          "SCCP user originated".
  865.                At the originating node, a connection  refusal  is  initiated  by  invoking
  866.          N-DISCONNECT INDICATION primitive.
  867.                If the connection refusal procedure is initiated at  an  intermediate  node
  868.          due to lack of resources, then a Connection Refused message is transferred on the
  869.          incoming connection section.
  870.                If the connection refusal procedure is initiated at  an  intermediate  node
  871.          due to expiration of the connection  establishment  timer,  then  the  connection
  872.          release procedure is initiated on that connection section (see S 3.3.4.1)  and  a
  873.          Connection Refused message is transferred on the associated connection section.
  874.                In either  of  the  two  above  cases  at  an  intermediate  node,  if  the
  875.          connection set-up was initiated using a REQUEST interface element, then the  SCCP
  876.          user is informed by invoking the N-DISCONNECT INDICATION primitive.
  877.          3.2.2  Actions at intermediate node not initiating connection refusal
  878.                When a Connection Refused message is received on a connection section,  the
  879.          following actions are performed:
  880.                1)  The resources associated with the connection section are released  and
  881.                   the timer T(conn est) is stopped3).
  882.                2)  If the connection was established using a REQUEST  interface  element,
  883.                   then the SCCP user is informed by invoking the N-DISCONNECT  INDICATION
  884.                   primitive.
  885.                3)   A  Connection  Refused  message  is  transferred  on  the  associated
  886.                   connection section.
  887.                4)  The resources associated with the associated  connection  section  are
  888.                   released.
  889.          3.2.3  Actions at the origination node not initiating connection refusal
  890.                When a Connection Refused message is received on a connection section,  the
  891.          following actions are performed:
  892.                1)  The resources associated with the connection section are released  and
  893.                   the timer T(conn est) is stopped3).
  894.                2)  The SCCP user is informed  by  invoking  the  N-DISCONNECT  INDICATION
  895.                   primitive.
  896.          3.3    Connection release
  897.          3.3.1  General
  898.                The connection release procedures consist  of  the  functions  required  to
  899.          release a temporary signalling connection between two  users  of  the  Signalling
  900.          Connection Control Part. Two messages  are  required  to  initiate  and  complete
  901.          connection release: Released and Release Complete.
  902.                The release may be performed:
  903.                a)  by either or  both  of  the  SCCP  users  to  release  an  established
  904.                   connection.
  905.                b)  by the SCCP to release an established connection.
  906.                All failures to maintain a connection are indicated in this way.
  907.  
  908.  
  909.  
  910.  
  911.  
  912.  
  913.  
  914.  
  915.  
  916.  
  917.          3) If the reason for the refusal is "destination address unknown",  then  the  maintenance
  918.          function is alerted.
  919.  
  920.  
  921.  
  922.                                                         Fascicle VI.7 - Rec. Q.714   PAGE1
  923.  
  924.                3.3.2  Frozen reference
  925.                The purpose of the frozen reference function is to prevent  the  initiation
  926.          of incorrect procedures as a connection section due  to  receipt  of  a  message,
  927.          which is associated with a previously established connection section.
  928.                When  a  connection  section  is  released,  the  local  reference   number
  929.          associated with the connection section is not immediately available for reuse  on
  930.          another connection section. A mechanism should be chosen to  sufficiently  reduce
  931.          the probability of erroneously associating a message with a  connection  section.
  932.          This particular mechanism is implementation dependent.
  933.          3.3.3  Actions at an end node initiating connection release
  934.          3.3.3.1   Initial actions
  935.                When a connection release is initiated at  an  end  node  of  a  signalling
  936.          connection, by the SCCP user invoking a N-DISCONNECT REQUEST primitive or by  the
  937.          node itself, the following actions are performed at the initiating node:
  938.                1)  A Released message is transferred on the connection section.
  939.                2)  A release timer T(rel) is started.
  940.                3)  If the  release  was  initiated  by  the  SCCP,  then  a  N-DISCONNECT
  941.                   INDICATION primitive is invoked.
  942.                4)  The inactivity control timers, T(ias) and T(iar), if still running, are 
  943.                   stopped.
  944.          3.3.3.2   Subsequent actions
  945.                The  following  actions  are  performed  at  the  originating  node  on   a
  946.          connection section for which a Released message has been previously transferred:
  947.                1)  When a Release Complete or Released message is received, the resources
  948.                   associated with the connection are  released,  the  timer,  T(rel),  is
  949.                   stopped, and the local reference number is frozen.
  950.                2)  When the release timer expires, a Released message is  transferred  on
  951.                   the connection section. The sending of the Released message is repeated
  952.                   every 4-15 seconds for an interval of up to one minute. At this point a
  953.                   maintenance function is alerted.
  954.          3.3.4  Actions at intermediate node
  955.                The connection release procedure is initiated at an  intermediate  node  by
  956.          the SCCP or by reception of a Released message on a connection section.
  957.          3.3.4.1   Initial actions
  958.                When a Released message is received on a connection section, the  following
  959.          actions then take place:
  960.                1)  A Release Complete message is transferred on the  connection  section,
  961.                   the resources associated with the connection are released and the local
  962.                   reference number is frozen.
  963.                2)  A Released message is transferred on the associated connection section; 
  964.                   the reason is identical to the reason in the received message.
  965.                3)  If the connection was established using a REQUEST  interface  element,
  966.                   then a N-DISCONNECT INDICATION primitive is invoked.
  967.                4)  The release timer, T(rel), is started on the associated connection.
  968.                5)  The inactivity control timers, T(ias) and T(iar), if still running, are 
  969.                   stopped on both connection sections.
  970.  
  971.  
  972.  
  973.  
  974.  
  975.  
  976.  
  977.  
  978.  
  979.  
  980.  
  981.  
  982.  
  983.  
  984.  
  985.  
  986.  
  987.  
  988.  
  989.  
  990.  
  991.  
  992.  
  993.          PAGE96  Fascicle VI.7 - Rec. Q.714
  994.  
  995.                When the connection release procedure is  initiated  by  the  SCCP  at  the
  996.          intermediate node during the data transfer  phase,  the  following  actions  take
  997.          place on both of the connection sections:
  998.                1)  A Released message is transferred on the connection section.
  999.                2)  If the connection section was established using an interface  element,
  1000.                   then a N-DISCONNECT INDICATION primitive is invoked.
  1001.                3)  The release timer, T(rel), is started.
  1002.                4)  The inactivity control timers, T(ias) and T(iar), if still running, are 
  1003.                   stopped on both connection sections.
  1004.          3.3.4.2   Subsequent actions
  1005.                The  following  actions  are  performed  at  an  intermediate  node  during
  1006.          connection release:
  1007.                1)  When a Release Complete or Released message is received on a connection 
  1008.                   section, the resources associated with the connection are released, the
  1009.                   timer T(rel) is stopped, and the local reference number is frozen.
  1010.                2)  When the release timer expires, a Released message is  transferred  on
  1011.                   the connection section. The sending of the Released message is repeated
  1012.                   every 4-15 seconds for an interval of up to one minute. At this point a
  1013.                   maintenance function is alerted.
  1014.          3.3.5  Actions at an end node not initiating connection release
  1015.                When a Released message  is  received  at  an  end  node  of  a  signalling
  1016.          connection, the following actions are performed on the connection section:
  1017.                1)  A Release Complete message is sent on the connection section.
  1018.                2)  The resources associated with the connection section are released, the
  1019.                   SCCP user is informed that  a  release  has  occured  by  invoking  the
  1020.                   N-DISCONNECT INDICATION primitive, and the local  reference  number  is
  1021.                   frozen.
  1022.                3)  The inactivity control timers, T(ias) and T(iar), if still running, are 
  1023.                   stopped.
  1024.          3.4    Inactivity control
  1025.                The purpose of the inactivity control is to recover from:
  1026.                1)  loss of a Connection Confirm message during connections establishment,
  1027.                   and
  1028.                2)  the unsignalled  termination  of  a  connection  section  during  data
  1029.                   transfer, and
  1030.                3)  a discrepancy in the connection data held at each end of a connection.
  1031.                Two inactivity control timers, the receive inactivity control timer  T(iar)
  1032.          and the send inactivity control timer T(ias), are  required  at  each  end  of  a
  1033.          connection section. The length of the receive inactivity  timer  must  be  longer
  1034.          than the length of the send inactivity timer.
  1035.                When any message is sent on  a  connection  section,  the  send  inactivity
  1036.          control timer is reset.
  1037.                When any message is sent on a connection section,  the  receive  inactivity
  1038.          control timer is reset.
  1039.                When the send inactivity timer, T(ias), expires, an  Inactivity  Test  (IT)
  1040.          message is sent on the connection section.
  1041.                The receiving SCCP checks the  information  contained  in  the  IT  message
  1042.          against the information held locally. If a discrepancy is detected, the following
  1043.          actions (Table 1/Q.714) are taken:
  1044.                When the receive inactivity control timer, T(iar), expires, the  connection
  1045.          release procedure is initiated on a temporary  connection  section  and  an  OA&M
  1046.          function is alerted for a permanent connection section.
  1047.                As an alternative to inactivity control timers in the SCCP, there  is  also
  1048.          the possibility of supervising a signalling connection by a SCCP user function.
  1049.                                                 TABLE 1/Q.714
  1050.          Discrepancy                     Action
  1051.          Source reference number         Release connection
  1052.          Protocol class                  Release connection
  1053.          Sequencing/segmenting a)         Reset connection
  1054.          Credit a)                        Reset connection
  1055.                     a) Does not apply to class 2 connection.
  1056.          3.5    Data transfer
  1057.          3.5.1  General
  1058.                The purpose of data transfer is  to  provide  the  functions  necessary  to
  1059.          transfer user information on a temporary or permanent signalling connection.
  1060.  
  1061.  
  1062.  
  1063.  
  1064.                                                         Fascicle VI.7 - Rec. Q.714   PAGE1
  1065.  
  1066.          3.5.1.1   Actions at the originating node
  1067.                The SCCP user at the originating node requests transfer of user data  on  a
  1068.          signalling connection by invoking the N-DATA REQUEST primitive.
  1069.                The Data message is then  generated,  which  must  be  transferred  on  the
  1070.          connection section. If flow control procedures apply to the  connection  section,
  1071.          these procedures must be enacted before the  message  can  be  forwarded  on  the
  1072.          connection section.
  1073.          3.5.1.2   Actions at the intermediate node
  1074.                If a signalling connection consists of more than  one  connection  section,
  1075.          then one or more intermediate nodes are involved in the transfer of Data messages
  1076.          on the signalling connection.
  1077.                When a valid Data message is received on an incoming connection section  at
  1078.          an intermediate node, the associated outgoing connection section  is  determined.
  1079.          The intermediate node then forwards the Data message to the  associated  outgoing
  1080.          connection section for transfer to the distant node. If flow  control  procedures
  1081.          apply to the connection sections, then the appropriate procedures must be enacted
  1082.          on both connection sections. On the incoming connection section, these procedures
  1083.          relate to the reception of a valid Data message and on  the  outgoing  connection
  1084.          section, the procedures control the flow  of  Data  messages  on  the  connection
  1085.          section.
  1086.          3.5.1.3   Actions at the destination node
  1087.                When the destination node receives a valid  Data  message,  the  SCCP  user
  1088.          (i.e., the Called Party Address) is notified by invoking  the  N-DATA  INDICATION
  1089.          primitive. If flow control procedures apply to  the  signalling  connection,  the
  1090.          flow control procedures relating to the reception of a  valid  Data  message  are
  1091.          enacted.
  1092.  
  1093.  
  1094.  
  1095.  
  1096.  
  1097.  
  1098.  
  1099.  
  1100.  
  1101.  
  1102.  
  1103.  
  1104.  
  1105.  
  1106.  
  1107.  
  1108.  
  1109.  
  1110.  
  1111.  
  1112.  
  1113.  
  1114.  
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.  
  1122.  
  1123.  
  1124.  
  1125.  
  1126.  
  1127.  
  1128.  
  1129.  
  1130.  
  1131.  
  1132.  
  1133.  
  1134.  
  1135.          PAGE96  Fascicle VI.7 - Rec. Q.714
  1136.  
  1137.                3.5.2  Flow control
  1138.          3.5.2.1   General
  1139.                The flow control procedures apply during data transfer only, and  are  used
  1140.          to control the flow of Data messages on each connection section.
  1141.                The flow control procedures apply only to protocol class 3.
  1142.                The reset procedure causes reinitialization of the flow control procedure.
  1143.                The  expedited  data  procedure  is  not  affected  by  this  flow  control
  1144.          procedure.
  1145.          3.5.2.2   Sequence numbering
  1146.                For protocol class 3, for each direction of transmission  on  a  connection
  1147.          section, the Data messages are sequentially numbered.
  1148.                The sequence numbering scheme of the Data messages is performed modulo  128
  1149.          on a connection section.
  1150.                Upon initialization or reinitialization of a  connection  section,  message
  1151.          send sequence numbers, P(S), are  assigned  to  Data  messages  on  a  connection
  1152.          section beginning with P(S) equal to 0. Each  subsequent  Data  message  sequence
  1153.          number is obtained by incrementing the last assigned value  by  1.  The  sequence
  1154.          numbering scheme assigns sequence numbers up to 127.
  1155.          3.5.2.3   Flow control window
  1156.                A separate window is defined, for each  direction  of  transmission,  on  a
  1157.          connection section in order to control the number of Data messages authorized for
  1158.          transfer on a connection section. The window is an ordered set of  W  consecutive
  1159.          message send sequence numbers associated with the Data  messages  authorized  for
  1160.          transfer on the connection section.
  1161.                The lower window edge is the lowest sequence number in the window.
  1162.                The sequence number of the first Data message not authorized  for  transfer
  1163.          on the connection is the value of the lower window edge plus W.
  1164.                The  maximum  window  size  is  set  during  connection  establishment  for
  1165.          temporary connection sections. For permanent connection sections, the window size
  1166.          is fixed at establishment. The maximum size cannot exceed 127.
  1167.                Negotiation  procedures  during  connection  establishment  allow  for  the
  1168.          negotiation of the window size.
  1169.          3.5.2.4   Flow control procedures
  1170.          3.5.2.4.1 Transfer of Data messages
  1171.                If flow control procedures apply to a connection  section,  then  all  Data
  1172.          messages on the connection section contain a send sequence number,  P(S),  and  a
  1173.          receive sequence number, P(R). The procedure for determining  the  send  sequence
  1174.          number to be used in a Data message  is  described  in  S  3.5.2.2.  The  receive
  1175.          sequence number, P(R), is set equal to the value of the next send sequence number
  1176.          expected on the connection section and P(R) becomes the lower window edge of  the
  1177.          receiving window.
  1178.                An originating or intermediate  node  is  authorized  to  transmit  a  Data
  1179.          message if the message send sequence number of the message is within the  sending
  1180.          window. That is, if P(S) is greater than or equal to the lower  window  edge  and
  1181.          less than the lower window edge plus W. When the send sequence number of  a  Data
  1182.          message is outside of the sending window, the node is not authorized to  transmit
  1183.          the message.
  1184.          3.5.2.4.2 Transfer of Data Acknowledgement messages
  1185.                Data Acknowledgement messages may be sent when there are no  Data  messages
  1186.          to be transferred on a connection section4).
  1187.  
  1188.  
  1189.  
  1190.  
  1191.  
  1192.  
  1193.  
  1194.  
  1195.  
  1196.  
  1197.  
  1198.  
  1199.  
  1200.          4) Further study is required to determine  criterion  to  be  used  to  decide  when  Data
  1201.            Acknowledgement messages are  sent  for  cases  other  than  the  congestion  situation
  1202.            described in this section.
  1203.  
  1204.  
  1205.  
  1206.                                                         Fascicle VI.7 - Rec. Q.714   PAGE1
  1207.  
  1208.                When a node transfers  a  Data  Acknowledgement  message  on  a  connection
  1209.          section, it is indicating that the node is  ready  to  receive  W  Data  messages
  1210.          within the window starting with the receive sequence number, P(R), found  in  the
  1211.          Data Acknowledgement message. That is, P(R) is  the  next  send  sequence  number
  1212.          expected at the remote node on the connection  section.  Furthermore,  P(R)  also
  1213.          becomes the lower window edge of the receiving window.
  1214.                A Data Acknowledgement message must be sent when a valid Data  message,  as
  1215.          per S 3.5.2.4.3 on P(S) and P(R), is received and P(S) is equal to the upper edge
  1216.          of the receiving window and there are no Data messages to be transferred  on  the
  1217.          connection section.  Sending  of  Data  Acknowledgement  messages  before  having
  1218.          reached the upper edge of the receiving window  is  also  allowed  during  normal
  1219.          operation.
  1220.                Data acknowledgement messages may also  be  sent  by  a  node  encountering
  1221.          congestion on a connection section as described below:
  1222.                Assuming nodes X and Y are the  two  ends  of  a  connection  section,  the
  1223.          following procedures apply.
  1224.                When a node (Y) experiences congestion on a connection section, it  informs
  1225.          the remote node (X) using the Data Acknowledgement message with the credit set to
  1226.          zero.
  1227.                Node (X) stops transferring Data messages on the connection section.
  1228.                Node X updates the window on the connection section using the value of  the
  1229.          receive sequence number, P(R), in the Data Acknowledgement message.
  1230.                Node  X  begins  transfer  of  Data  message  when  it  receives   a   Data
  1231.          Acknowledgement message with a credit field greater than zero  or  when  a  Reset
  1232.          message is received on a connection section  for  which  a  Data  Acknowledgement
  1233.          message with a credit field equal to zero had previously been received.
  1234.                Node X updates the window on the connection using  the  credit  value.  The
  1235.          credit value in a Data Acknowledgement message must either equal  zero  or  equal
  1236.          the initial credit agreed to at connection establishment.
  1237.          3.5.2.4.3 Reception of a Data or Data Acknowledgement message
  1238.                When an intermediate or  destination  node  receives  a  Data  message,  it
  1239.          performs the following test on the send sequence number, P(S), contained  in  the
  1240.          Data message:
  1241.                1)  If P(S) is the next send sequence number expected and  is  within  the
  1242.                   window, then the node accepts the Data message and  increments  by  one
  1243.                   the value of the  next  sequence  number  expected  on  the  connection
  1244.                   section.
  1245.                2)  If P(S) is not the next send sequence number expected, then the  reset
  1246.                   procedure is initiated on the connection section.
  1247.                3)  If P(S) is not within the window, then  this  is  considered  a  local
  1248.                   procedure error and the connection reset procedure is initiated.
  1249.                4)  If P(S) is not equal to 0 for the first Data  message  received  after
  1250.                   initialization or reinitialization of the connection section,  this  is
  1251.                   considered a local procedure error and the connection  reset  procedure
  1252.                   is initiated.
  1253.                The message receive sequence number, P(R), is included in  Data,  and  Data
  1254.          Acknowledgement messages. When a node receives a  Data  or  Data  Acknowledgement
  1255.          message on a connection section, the value of the receive sequence number,  P(R),
  1256.          implies that the remote node has accepted at least all Data messages numbered  up
  1257.          to and including P(R) - 1. That is, the next expected send sequence number at the
  1258.          remote node is P(R). The receive sequence number, P(R), contains information from
  1259.          the node sending the message, which authorizes the transfer of a  limited  number
  1260.          of Data messages on the connection section. When a node receives a Data  or  Data
  1261.          Acknowledgement message:
  1262.                a)  the receive sequence number, P(R), contained in the message becomes the 
  1263.                   lower window edge of the sending window:
  1264.                   1)  if the value of P(R) is greater than or  equal  to  the  last  P(R)
  1265.                       received by the node on that connection section, and also,
  1266.                   2)  if the value of the received P(R) is less than or equal to the P(S)
  1267.                       of the next Data message  to  be  transferred  on  that  connection
  1268.                       section;
  1269.                b)  the node initiates the reset procedure on the connection section if the 
  1270.                   receive sequence number, P(R), does not meet conditions 1) and 2).
  1271.  
  1272.  
  1273.  
  1274.  
  1275.  
  1276.  
  1277.          PAGE96  Fascicle VI.7 - Rec. Q.714
  1278.  
  1279.                3.5.3  Segmenting and reassembly
  1280.                During the data transfer phase, the N-DATA REQUEST  primitive  is  used  to
  1281.          request transfer of octet-aligned data (NSDUs) on a signalling connection.  NSDUs
  1282.          longer than 255 octets must be segmented before insertion into the  "data"  field
  1283.          of a Data message.
  1284.                The more-data indicator (M-bit) is used to reassemble a NSDU that has  been
  1285.          segmented for conveyance in multiple Data messages. The M-bit is set to 1 in  all
  1286.          Data messages except the last message whose data field relates  to  a  particular
  1287.          NSDU. In this way, the SCCP can reassemble the NSDU by combining the data  fields
  1288.          of all Data messages with the M-bit set to 1 with the following Data message with
  1289.          the M-bit set to 0. The NSDU is then delivered to the SCCP user using the  N-DATA
  1290.          INDICATION. Data messages in which the M-bit is set to 1 do not necessarily  have
  1291.          the maximum length.
  1292.                Segmentation and reassembly are not required if the length of the  NSDU  is
  1293.          less than or equal to 255 octets.
  1294.          3.6    Expedited data transfer
  1295.          3.6.1  General
  1296.                The expedited data procedure applies only during the  data  transfer  phase
  1297.          and is applicable to protocol class 3.
  1298.                For the case of expedited data transfer, each message  contains  one  NSDU,
  1299.          and no segmenting and reassembly is provided.
  1300.                If an Expedited Data or Expedited Data  Acknowledgement  message  is  lost,
  1301.          then subsequent Expedited Data messages cannot be  forwarded  on  the  connection
  1302.          section.
  1303.          3.6.2  Actions at the originating node
  1304.                The expedited data transfer procedure is initiated by the user of the  SCCP
  1305.          using the N-EXPEDITED-DATA REQUEST primitive, which contains up to 32  octets  of
  1306.          user data.
  1307.                When the SCCP user  invokes  the  N-EXPEDITED-DATA  REQUEST  primitive,  an
  1308.          Expedited Data message with up to 32 octets of user data is  transferred  on  the
  1309.          connection section once all previous Expedited Data messages for  the  connection
  1310.          section have been acknowledged.
  1311.          3.6.3  Actions at intermediate node
  1312.                Upon receiving  a  valid  Expedited  Data  message,  an  intermediate  node
  1313.          confirms this message by transferring an Expedited Data  Acknowledgement  message
  1314.          on  the  incoming  connection  section.  Withholding  of   the   Expedited   Data
  1315.          Acknowledgement message is a means of providing flow control  of  Expedited  Data
  1316.          messages.
  1317.                If  a  node  receives  another  Expedited  Data  message  on  the  incoming
  1318.          connection section before sending the  Expedited  Data  Acknowledgement  message,
  1319.          then the node  will  discard  the  subsequent  message  and  reset  the  incoming
  1320.          connection section.
  1321.                The  intermediate  node  determines  the  associated  outgoing   connection
  1322.          section. An Expedited Data message is then transferred on the associated outgoing
  1323.          connection section, once all previous Expedited Data messages on that  connection
  1324.          section have been acknowledged.
  1325.                The  Expedited  Data  Acknowledgement   message   must   be   sent   before
  1326.          acknowledging subsequent Data or Expedited Data messages received on the incoming
  1327.          connection section.
  1328.          3.6.4  Actions at destination node
  1329.                The destination node of the connection section confirms a  valid  Expedited
  1330.          Data message by transferring an Expedited Data  Acknowledgement  message  on  the
  1331.          connection section. Withholding of the Expedited Data Acknowledgement message  is
  1332.          a means of providing flow control of Expedited Data messages.
  1333.  
  1334.  
  1335.  
  1336.  
  1337.  
  1338.  
  1339.  
  1340.  
  1341.  
  1342.  
  1343.  
  1344.  
  1345.  
  1346.  
  1347.  
  1348.                                                         Fascicle VI.7 - Rec. Q.714   PAGE1
  1349.  
  1350.                If a node receives another Expedited Data message on a  connection  section
  1351.          before sending the Expedited Data Acknowledgement message,  then  the  node  will
  1352.          discard the subsequent message and reset the connection section.
  1353.                The  destination  node  then  invokes  the  N-EXPEDITED   DATA   INDICATION
  1354.          primitive.
  1355.                The N-EXPEDITED-DATA  INDICATION  must  be  issued  to  the  SCCP  user  at
  1356.          destination node before N-DATA or N-EXPEDITED-DATA indications resulting from any
  1357.          subsequently issued N-DATA or N-EXPEDITED-DATA requests at the  originating  node
  1358.          of  that  signalling  connection.  The   initiation   of   the   Expedited   Data
  1359.          Acknowledgement message is implementation dependent.
  1360.          3.7    Reset
  1361.          3.7.1  General
  1362.                The purpose  of  the  reset  procedure  is  to  reinitialize  a  connection
  1363.          section. It is applicable only to protocol class 3. It is  noted  that  the  time
  1364.          sequence of the primitives in the reset procedure may be varied as long as it  is
  1365.          consistent with Recommendation X.213.
  1366.                For a connection reset initiated  by  the  SCCP,  Data  or  Expedited  Data
  1367.          messages should not be  transferred  on  the  connection  section  prior  to  the
  1368.          completion of the reset procedure.
  1369.          3.7.2  Action at the initiating node
  1370.          3.7.2.1   Initial actions
  1371.                When a connection reset is initiated, by the SCCP user invoking  a  N-RESET
  1372.          REQUEST primitive or by the node itself, the following actions are  performed  at
  1373.          the initiating node:
  1374.                1)  A Reset Request message is transferred on the connection section.
  1375.                2)  The send sequence number, P(S), for the next Data message is set to 0.
  1376.                   The lower window edge is set to 0. The window  size  is  reset  to  the
  1377.                   initial credit value.
  1378.                3)  The SCCP user is informed that a reset has taken place by:
  1379.                   -   invoking the N-RESET INDICATION primitive if the reset  is  network
  1380.                       originated.
  1381.                4)  The reset timer T (reset) is started.
  1382.          3.7.2.2   Subsequent actions
  1383.                The following actions are performed at the initiating node on a  connection
  1384.          section for which a Reset Request message has been previously transferred:
  1385.                1)  When a Data, Data Acknowledgement, Expedited Data, or  Expedited  Data
  1386.                   Acknowledgement message is received, the message is discarded. When  an
  1387.                   N-DATA REQUEST or N-EXPEDITED DATA REQUEST primitive is  received,  the
  1388.                   primitive is discarded or stored up to  the  completion  of  the  reset
  1389.                   procedure. The choice between these two is implementation dependent.
  1390.                2)  When the reset timer expires,  the  connection  release  procedure  is
  1391.                   initiated on a temporary connection section and  maintenance  functions
  1392.                   are alerted for a permanent connection section.
  1393.                3)  When a Reset Confirm or a Reset Request message  is  received  on  the
  1394.                   connection section, the  reset  is  completed  provided  the  SCCP  has
  1395.                   previously received an N-RESET REQUEST or RESPONSE primitive  from  the
  1396.                   SCCP user and, therefore,  data  transfer  is  resumed  and  the  timer
  1397.                   T(reset) is stopped. The SCCP  user  is  informed  that  the  reset  is
  1398.                   completed by invoking the N-RESET CONFIRMATION primitive.
  1399.                4)  When a Released message is received on a temporary connection section,
  1400.                   the release procedure  is  initiated  and  the  timer,  T  (reset),  is
  1401.                   stopped.
  1402.  
  1403.  
  1404.  
  1405.  
  1406.  
  1407.  
  1408.  
  1409.  
  1410.  
  1411.  
  1412.  
  1413.  
  1414.  
  1415.  
  1416.  
  1417.  
  1418.  
  1419.          PAGE96  Fascicle VI.7 - Rec. Q.714
  1420.  
  1421.                3.7.3  Actions at the intermediate node
  1422.          3.7.3.1   Initial actions
  1423.                The connection reset  procedure  is  initiated  at  the  intermediate  node
  1424.          either by the SCCP at the node itself or by the  reception  of  a  Reset  Request
  1425.          message.
  1426.                When a Reset Request message is  received  on  a  connection  section,  the
  1427.          following actions take place:
  1428.                1)  A Reset Confirm message is transferred on the connection section.
  1429.                2)  A Reset Request message is transferred on  the  associated  connection
  1430.                   section; the reason for reset is identical to the reason in  the  Reset
  1431.                   Request message.
  1432.                3)  On both the connection section and the associated connection  section,
  1433.                   the send sequence number,  P(S),  for  the  next  Data  message  to  be
  1434.                   transmitted is set to 0 and the lower window edge  is  set  to  0.  The
  1435.                   window size is reset to the initial credit  value  on  both  connection
  1436.                   sections.
  1437.                4)  The data transfer procedure is initiated on the connection section.
  1438.                5)  The reset timer, T (reset), is started on  the  associated  connection
  1439.                   section.
  1440.                When the connection reset  procedure  is  initiated  by  the  SCCP  at  the
  1441.          intermediate node, the following actions take place on  both  of  the  connection
  1442.          sections:
  1443.                1)  A Reset Request message is transferred.
  1444.                2)  The send sequence number, P(S), for the next Data message is set to 0.
  1445.                   The lower window edge is set to 0. The window  size  is  reset  to  the
  1446.                   initial credit value.
  1447.                3)  The reset timer T (reset) is started.
  1448.          3.7.3.2   Subsequent actions
  1449.                If the connection reset was initiated  by  reception  of  a  Reset  Request
  1450.          message on a connection section, then the following actions are  performed  after
  1451.          initial actions are completed:
  1452.                1)  When a Data, Data  Acknowledgement,  Expedited  Data,  Expedited  Data
  1453.                   Acknowledgement  message  is  received  on  the  associated  connection
  1454.                   section, the message is discarded.
  1455.                2)  When the reset timer expires on the associated connection section, the
  1456.                   connection release procedure is initiated on both temporary  connection
  1457.                   sections and the maintenance  function  is  alerted  on  an  associated
  1458.                   permanent connection section.
  1459.                3)  When a Released message is received on a temporary connection section,
  1460.                   the connection  release  procedure  is  initiated  on  both  connection
  1461.                   sections and the timer, T (reset), is stopped.
  1462.                4)  When a Reset Confirm or Reset  Request  message  is  received  on  the
  1463.                   associated connection section, the data transfer procedure  is  resumed
  1464.                   and the timer, T (reset), is stopped.
  1465.                If the connection reset was initiated  by  the  SCCP  at  the  intermediate
  1466.          node, then the following actions are  performed  once  the  initial  actions  are
  1467.          completed:
  1468.                1)  When a Data, Data Acknowledgement, Expedited Data, or  Expedited  Data
  1469.                   Acknowledgement message is received on either connection  section,  the
  1470.                   message is discarded.
  1471.                2)  When the reset timer expires on a temporary  connection  section,  the
  1472.                   connection release procedure is initiated on both connection  sections,
  1473.                   and on  a  permanent  connection  section  a  maintenance  function  is
  1474.                   alerted.
  1475.                3)  When a Released message is received on a temporary connection section,
  1476.                   the connection  release  procedure  is  initiated  on  both  connection
  1477.                   sections and the timer, T (reset), is stopped .
  1478.                4)  When a Reset Confirm  or  Reset  Request  message  is  received  on  a
  1479.                   connection section, data transfer is resumed on that connection and the
  1480.                   timer, T (reset), is stopped.
  1481.  
  1482.  
  1483.  
  1484.  
  1485.  
  1486.  
  1487.  
  1488.  
  1489.  
  1490.                                                         Fascicle VI.7 - Rec. Q.714   PAGE1
  1491.  
  1492.          3.7.4  Actions at the destination node
  1493.                When a Reset Request message is received at a node, the  following  actions
  1494.          are performed on the connection section:
  1495.                1)  The send sequence number, P(S), for the next Data message is set to 0,
  1496.                   the lower window edge is set to 0. The window  size  is  reset  to  the
  1497.                   initial credit value.
  1498.                2)  The SCCP user is informed that a reset has occurred  by  invoking  the
  1499.                   N-RESET INDICATION primitive.
  1500.                3)  A Reset Confirm message is transferred on the connection section after
  1501.                   an N-RESET RESPONSE or REQUEST primitive is invoked by the user.
  1502.                4)  An N-RESET CONFIRMATION primitive is invoked to inform the  SCCP  user
  1503.                   that the reset is completed and the data transfer can be resumed.
  1504.          3.7.5  Handling of messages during the reset procedures
  1505.                Once the reset procedure is initiated,  the  following  actions  are  taken
  1506.          with respect to Data messages:
  1507.                -   those that have been transmitted, but for which an acknowledgement has
  1508.                   not been received, are discarded, and
  1509.                -   those that have not been transmitted, but are contained  in  an  M-bit
  1510.                   sequence for which  some  Data  messages  have  been  transmitted,  are
  1511.                   discarded,
  1512.                -   those Data  messages  that  have  been  received,  but  which  do  not
  1513.                   constitute an entire M-bit sequence, are discarded.
  1514.          3.8    Restart
  1515.          3.8.1  General
  1516.                The purpose of the restart procedure is to  provide  a  recovery  mechanism
  1517.          for signalling connection sections in the event of a node failure.
  1518.          3.8.2  Actions at the recovered node
  1519.          3.8.2.1   Initial actions
  1520.                When  a  node  recovers  from  its  failure,  the  following  actions   are
  1521.          performed:
  1522.                1)  A guard timer, T(guard)5) , is started.
  1523.                2)  If the recovered node has knowledge about the local reference  numbers
  1524.                   in use  before  failure,  then  the  normal  procedures  for  temporary
  1525.                   signalling connections are resumed with the assumption that  the  local
  1526.                   reference numbers which were in use before the  node  failure  are  not
  1527.                   assigned at least during T(guard).
  1528.                3)  An OA&M function is informed for  the  re-establishment  of  permanent
  1529.                   signalling connections.
  1530.          3.8.2.2   Subsequent actions
  1531.                The following actions  are  performed  at  the  recovered  node,  on  every
  1532.          temporary signalling connection section if the  node  does  not  know  the  local
  1533.          reference numbers in use before failure, or  only  on  the  temporary  signalling
  1534.          connection sections in operation before failure if the node has such knowledge:
  1535.                a)  Before the guard timer, T(guard), expires:
  1536.                   1)   When  a  Released  message  is  received  with  both  source   and
  1537.                       destination local reference numbers, a  Release  Complete  message,
  1538.                       with  reversed  local  reference  numbers,  is  returned   to   the
  1539.                       originating point code.
  1540.                   2)  Any other connection-oriented messages received are discarded.
  1541.                b)  When the guard timer, T(guard), expires, normal procedures are resumed.
  1542.  
  1543.  
  1544.  
  1545.  
  1546.  
  1547.  
  1548.  
  1549.  
  1550.  
  1551.  
  1552.  
  1553.  
  1554.  
  1555.                5) The guard timer must be large enough, so that all the  non-failed  far  end  nodes  can
  1556.            detect the failure and can safely release the affected temporary signalling  connection
  1557.            sections. This implies T(guard) > T(iar) + T(rel).
  1558.  
  1559.  
  1560.  
  1561.          PAGE96  Fascicle VI.7 - Rec. Q.714
  1562.  
  1563.                3.8.3  Actions at the non-failed far end node
  1564.                The inactivity control procedure, described  in  S  3.4,  is  used  by  the
  1565.          non-failed far end  node  to  recover  from  the  unsignalled  termination  of  a
  1566.          connection section during data transfer.
  1567.          3.9    Permanent signalling connections
  1568.                Permanent  signalling  connections  are   set   up   administratively   and
  1569.          connection establishment procedures and connection  release  procedures  are  not
  1570.          initiated by the SCCP user.
  1571.                Permanent signalling connections are realized using one or more  connection
  1572.          sections.
  1573.                A permanent signalling connection is either in the data transfer  phase  or
  1574.          the reset phase. Therefore, all procedures relating to the  data  transfer  phase
  1575.          for connection-oriented protocol classes and the reset procedures are  applicable
  1576.          to permanent signalling connections.
  1577.          3.10   Abnormalities
  1578.          3.10.1 General
  1579.                Errors can be classified into the three categories listed  below.  Examples
  1580.          of each category are included for clarification:
  1581.                1)  Syntax errors - This type of error  occurs  when  a  node  receives  a
  1582.                   message that does not conform to the format specifications of the SCCP.
  1583.                   Examples of syntax errors are:
  1584.                   -   reception of message with an invalid message type code, and
  1585.                   -   reception of a message with an unassigned local reference number.
  1586.                2)  Logical errors - This type of error occurs  when  a  node  receives  a
  1587.                   message that is not an acceptable input to the  current  state  of  the
  1588.                   connection section, or whose value of P(S) or P(R) is invalid. Examples
  1589.                   of logical errors are:
  1590.                   -   reception of an  acknowledgement  message  when  the  corresponding
  1591.                       request message has not been sent,
  1592.                   -   reception of a Data message whose data  field  length  exceeds  the
  1593.                       maximum data field permitted on the connection section,
  1594.                   -   reception of a second Expedited Data message  before  an  Expedited
  1595.                       Data Acknowledgement message has been sent, and
  1596.                   -   reception of message whose value of P(R) is  not  greater  than  or
  1597.                       equal to the last P(R) received and is not less than  or  equal  to
  1598.                       the next value of P(S) to be transmitted.
  1599.                3)  Transmission errors - This type of error occurs when a message is lost
  1600.                   or delayed. Examples of transmission errors are:
  1601.                   -    expiration  of  a  timer  before  reception  of  the   appropriate
  1602.                       acknowledgement message.
  1603.          3.10.2 Action tables
  1604.                The  action  tables  found  in  Recommendation  Q.714,  Annex  B,   include
  1605.          information, in addition to that found  in  the  text  of  Recommendation  Q.714,
  1606.          regarding the actions to be performed upon receipt of a message.  In  particular,
  1607.          these tables are helpful in determining the actions to be performed upon  receipt
  1608.          of a message resulting in a logical error.
  1609.          3.10.3 Actions upon the reception of an ERR message
  1610.                Upon the reception of a Protocol Data Unit Error (ERR) message at  a  node,
  1611.          the following actions are performed on the connection section  for  error  causes
  1612.          other than "service class mismatch":
  1613.                1)  The resources associated with the connection are released.
  1614.                2)  The local reference number is frozen (see S 3.3.2).
  1615.                Upon the reception of a Protocol Data Unit Error (ERR) message  at  a  node
  1616.          with the error cause "service class mismatch", the connection  release  procedure
  1617.          is initiated by the SCCP at that node (see S 3.3).
  1618.  
  1619.  
  1620.  
  1621.  
  1622.  
  1623.  
  1624.  
  1625.  
  1626.  
  1627.  
  1628.  
  1629.  
  1630.  
  1631.  
  1632.                                                         Fascicle VI.7 - Rec. Q.714   PAGE1
  1633.  
  1634.                4      Connectionless procedures
  1635.                The connectionless procedures allow a user of the SCCP to request  transfer
  1636.          of up to X octets6) of user data without  first  requesting  establishment  of  a
  1637.          signalling connection.
  1638.                The N-UNITDATA REQUEST and INDICATION primitives are used by  the  user  of
  1639.          the SCCP to request transfer of user data  by  the  SCCP  and  for  the  SCCP  to
  1640.          indicate delivery of user data to the  destination  user.  Parameters  associated
  1641.          with the N-UNITDATA REQUEST primitive must contain all information necessary  for
  1642.          the SCCP to deliver the user data to the destination.
  1643.                Transfer of the user data is accomplished by including  the  user  data  in
  1644.          Unitdata messages.
  1645.                The user of the SCCP should ensure that the total length of the  user  data
  1646.          and the SCCP address information does not exceed the total permissible length  of
  1647.          the SCCP Unitdata message.
  1648.                If user data of excessive length is presented by the user of the SCCP,  the
  1649.          SCCP should not transmit a part of it to the remote user of the SCCP.
  1650.                Whether or not the local SCCP user  should  be  informed  by  the  SCCP  is
  1651.          implementation dependent.
  1652.                When the user of the SCCP requests transfer  of  user  data  by  issuing  a
  1653.          N-UNITDATA REQUEST primitive, there are  two  classes  of  service  that  can  be
  1654.          provided by the SCCP, protocol classes  0  and  1.  These  protocol  classes  are
  1655.          distinguished by their message sequencing characteristics.
  1656.                When the user of the SCCP requests transfer of several messages by  issuing
  1657.          multiple N-UNITDATA REQUEST primitives, the probability of these  messages  being
  1658.          received in sequence at the  "Called  address"  depends  on  the  protocol  class
  1659.          designated in the request primitives. For protocol class 0 the  sequence  control
  1660.          parameter is not included in the N-UNITDATA REQUEST primitive and  the  SCCP  may
  1661.          generate a different SLS for each of these messages. For  protocol  class  1  the
  1662.          sequence control parameter is included in the N-UNITDATA REQUEST  primitive  and,
  1663.          if the parameter is the same in  each  request  primitive,  then  the  SCCP  will
  1664.          generate the same SLS for these messages.
  1665.                The Message Transfer Part retains message  sequencing  for  those  messages
  1666.          with the same SLS field. The Signalling Connection Control  Part  relies  on  the
  1667.          services of the MTP for transfer of SCCP messages. Based on  the  characteristics
  1668.          of the MTP, the protocol class 1 service may be  used  in  such  a  way  that  it
  1669.          provides a quality of service that has a  lower  probability  of  out-of-sequence
  1670.          messages than that provided by protocol class 0.
  1671.          4.1    Data transfer
  1672.                The N-UNITDATA REQUEST  primitive  is  invoked  by  the  SCCP  user  at  an
  1673.          originating  node  to  request  connectionless   data   transfer   service.   The
  1674.          connectionless data transfer service is also used to  transport  SCCP  management
  1675.          messages, which are transferred in the "data" field of Unitdata messages.
  1676.                The Unitdata message is  then  transferred,  using  SCCP  and  MTP  routing
  1677.          functions, to the "Called address" indicated in the UNITDATA REQUEST primitive.
  1678.                SCCP routing and relaying functions may be required at intermediate  nodes,
  1679.          since complete translation and routing tables for all addresses are not  required
  1680.          at every node.
  1681.                When the Unitdata message cannot be transferred  to  its  destination,  the
  1682.          message return function is initiated.
  1683.                The SCCP uses the services of  the  MTP  and  the  MTP  may,  under  severe
  1684.          network conditions, discard messages. Therefore, the user of  the  SCCP  may  not
  1685.          always be informed of non-delivery of user data. The MTP  notifies  the  SCCP  of
  1686.          unavailable signalling points using the  MTP-STOP  INDICATION  and  of  congested
  1687.          signalling points using the MTP-PAUSE  INDICATION.  The  SCCP  then  informs  its
  1688.          users.
  1689.                When a Unitdata message is received at the destination node,  a  N-UNITDATA
  1690.          INDICATION primitive is invoked except for the SCCP management messages. The SCCP
  1691.          management (SCMG) messages are passed to the SCMG entity instead.
  1692.  
  1693.  
  1694.  
  1695.  
  1696.                6) Due to the ongoing studies on the SCCP called and calling party address, the maximum of
  1697.            this value needs further study. It is also noted that the transfer of up to 255  octets
  1698.            of user data is allowedd when the SCCP called and calling party address do not  include
  1699.            global title.
  1700.  
  1701.  
  1702.  
  1703.          PAGE96  Fascicle VI.7 - Rec. Q.714
  1704.  
  1705.                4.2    Message return
  1706.                The purpose of message return  is  to  discard  or  return  messages  which
  1707.          encounter routing failure and cannot be delivered to their final destination.
  1708.                The message return procedure is initiated if  SCCP  routing  is  unable  to
  1709.          transfer a Unitdata or Unitdata Service message. The procedure may be  initiated,
  1710.          for  example,  as  a  result  of  insufficient  translation  information  or  the
  1711.          inaccessibility of a subsystem or point code. Specific reasons are enumerated  in
  1712.          S 2.3.
  1713.                a)  If the message is a Unitdata message, and
  1714.                   -   the option field is set to return message on error, then a Unitdata
  1715.                       Service message is transferred to the "calling party address".  (If
  1716.                       the message is  originated  locally,  then  a  N-NOTICE  INDICATION
  1717.                       primitive is invoked.)
  1718.                   -   the option field is not set to return on error, then the message is
  1719.                       discarded.
  1720.                b)  If the undeliverable message is a  Unitdata  Service  message,  it  is
  1721.                   discarded.
  1722.                The user "data" field of the Unitdata message and  the  reason  for  return
  1723.          are included in the Unitdata Service message.
  1724.                When a Unitdata Service message is received  at  the  destination  node,  a
  1725.          N-NOTICE INDICATION primitive is invoked.
  1726.          4.3    Syntax error
  1727.                This type of error occurs when a node receives  a  message  that  does  not
  1728.          conform to the format specifications of the SCCP. Examples of syntax errors are:
  1729.                -   unreasonable pointer  value  (e.g.,  points  beyond  the  end  of  the
  1730.                   message);
  1731.                -   mismatch between message type and protocol class parameters; and
  1732.                -   inconsistent address indicator and address contents.
  1733.                When syntax error is detected for a connectionless message, the message  is
  1734.          discarded. Checking for syntax errors beyond the processing required for the SCCP
  1735.          connectionless message routing is not mandatory.
  1736.          5      SCCP management procedures
  1737.          5.1    General
  1738.                The purpose of  SCCP  management  is  to  provide  procedures  to  maintain
  1739.          network performance by rerouting or throttling traffic in the event of failure or
  1740.          congestion in the network.
  1741.                Although SCCP management has its own subsystem number,  the  procedures  in
  1742.          this section does not apply to it.
  1743.                SCCP management  is  organized  into  two  subfunctions:  signalling  point
  1744.          status management  and  subsystem  status  management.  Signalling  point  status
  1745.          management  and  subsystem  status  management  allow  SCCP  management  to   use
  1746.          information concerning the accessibility of  signalling  points  and  subsystems,
  1747.          respectively,  to  permit  the  network  to  adjust  to  failure,  recovery   and
  1748.          congestion.
  1749.                SCCP management procedures rely on:
  1750.                1)  failure, recovery, and congestion information provided in the MTP-PAUSE 
  1751.                   INDICATION, MTP-RESUME INDICATION and MTP-STATUS INDICATION primitives;
  1752.                   and
  1753.                2)  subsystem failure, recovery and congestion information received in SCCP 
  1754.                   management messages7).
  1755.                SCCP management information is currently defined to  be  transferred  using
  1756.          SCCP connectionless service with no return on error requested. Formats  of  these
  1757.          messages appear in Recommendation Q.713.
  1758.  
  1759.  
  1760.  
  1761.  
  1762.  
  1763.  
  1764.  
  1765.  
  1766.  
  1767.  
  1768.  
  1769.  
  1770.          7) Subsystem congestion control is for further study.
  1771.  
  1772.  
  1773.  
  1774.                                                         Fascicle VI.7 - Rec. Q.714   PAGE1
  1775.  
  1776.                The  information  pertaining  to  both  single  and  replicated  nodes   or
  1777.          subsystems is used for  SCCP  management  purposes.  This  allows  "called  party
  1778.          addresses" that are specified in the form of a global title to be  translated  to
  1779.          different point codes and/or subsystem numbers depending on network or  subsystem
  1780.          status.
  1781.                Replicated nodes or subsystems may relate to their  replicates  in  one  of
  1782.          several ways. ("Replicate" is a term meaning one of a set of "multiple copies". A
  1783.          node of subsystem which is not replicated is termed "solitary".)
  1784.                One mode uses a replicate in  a  dominant  role.  Traffic  is  split  among
  1785.          several nodes/subsystems. Under normal conditions, each portion of the traffic is
  1786.          routed  to  a  preferred,  or  "primary",  node/subsystem.   When   the   primary
  1787.          node/subsystem  is  inaccessible,  this  traffic  is   routed   to   a   "backup"
  1788.          node/subsystem . When the  primary  node/subsystem  recovers,  it  reassumes  its
  1789.          normal traffic load.
  1790.                A second mode  uses  a  replicate  in  a  replacement  role.  Consider  two
  1791.          replicates, A and B, which are "alternatives". When A becomes  inaccessible,  its
  1792.          traffic is routed to B; but when A recovers, the traffic is not moved back to  A.
  1793.          It is only when B becomes inaccessible that traffic is  shifted  back  to  A.  In
  1794.          addition, other modes are possible.
  1795.                The current SCCP management procedures  are  designed  to  manage  solitary
  1796.          nodes/subsystems, and replicated nodes/subsystems which  operate  in  a  dominant
  1797.          mode and for which any given primary node/subsystem has only  one  backup  (i.e.,
  1798.          duplicated nodes/subsystems). Management procedures  for  nodes/subsystems  which
  1799.          operate in a mode other than the dominant mode  and  which  have  more  than  one
  1800.          backup are for further study.
  1801.                SCCP management procedures utilize the concept of a  "concerned"  subsystem
  1802.          or signalling point. In this context, a "concerned" entity means an  entity  with
  1803.          an immediate need to be  informed  of  a  particular  signalling  point/subsystem
  1804.          status change, independently of whether SCCP communication is in progress between
  1805.          the "concerned" entity and the affected entity with the status change8).
  1806.                In some situations, the number of concerned subsystem or signalling  points
  1807.          for a given subsystem may be zero. In this case, when  the  subsystem  fails,  or
  1808.          becomes  unavailable,  no  broadcast  of  the  subsystem  prohibited  message  is
  1809.          performed.  Instead,  the  response  method  is  used  to  return  the  subsystem
  1810.          prohibited message. Similarly, no broadcast of the subsystem allowed  message  is
  1811.          performed for that given subsystem when it recovers. The response method is again
  1812.          used to return a subsystem allowed message in reply to a subsystem status test.
  1813.                The signalling point prohibited, signalling point  allowed  and  signalling
  1814.          point congested procedures, specified in SS 5.2.2, 5.2.3 and 5.2.4  respectively,
  1815.          deal with the accessibility of a signalling point.
  1816.                The subsystem prohibited and subsystem allowed procedures, detailed  in  SS
  1817.          5.3.2 and 5.3.3 respectively, deal with the accessibility of a subsystem.
  1818.                An  audit  procedure  to  ensure  that   necessary   subsystem   management
  1819.          information is always  available  is  specified  in  the  subsystem  status  test
  1820.          procedure in S 5.3.4.
  1821.                A subsystem may request to go out of service using  the  coordinated  state
  1822.          change control procedure specified in S 5.3.5.
  1823.                Local subsystems are informed of any related subsystem status by the  local
  1824.          broadcast procedure specified in S 5.3.6.
  1825.                Concerned signalling points are informed of any  related  subsystem  status
  1826.          by the broadcast procedure specified in S 5.3.7.
  1827.          5.2    Signalling point status management
  1828.          5.2.1  General
  1829.                Signalling point status management updates translation and status based  on
  1830.          the information of network failure,  recovery,  or  congestion  provided  by  the
  1831.          MTP-PAUSE INDICATION, MTP-RESUME INDICATION, or MTP-STATUS INDICATION primitives.
  1832.          This allows  alternative  routing  to  backup  signalling  points  and/or  backup
  1833.          subsystems.
  1834.  
  1835.  
  1836.  
  1837.  
  1838.  
  1839.  
  1840.                8) Further explicit definition of "concerned" subsystems or  signalling  points  would  be
  1841.            network/architecture/application dependent.
  1842.  
  1843.  
  1844.  
  1845.          PAGE96  Fascicle VI.7 - Rec. Q.714
  1846.  
  1847.                5.2.2  Signalling point prohibited
  1848.                When  SCCP  management  receives  a  MTP-PAUSE  INDICATION  relating  to  a
  1849.          destination that become inaccessible, SCCP management:
  1850.                1)  marks the translation as appropriate:
  1851.                   -   "translate to backup node" if that signalling point has a backup;
  1852.                   -    "translate  to  backup  subsystem"  for  each  subsystem  at  that
  1853.                       signalling point for which a backup subsystem exists.
  1854.                2)  marks as "prohibited" the status of that signalling point and of  each
  1855.                   subsystem at that signalling point.
  1856.                3)  discontinues any subsystem status tests (S 5.3.4) it may be conducting
  1857.                   to any subsystems at that signalling point.
  1858.                4)   initiates  a  local  broadcast  (S  5.3.6)  of  "User-out-of-service"
  1859.                   information for each subsystem at that signalling point.
  1860.                5)   initiates  a  local  broadcast  (S  5.3.6)   of   "signalling   point
  1861.                   inaccessible" information for that signalling point.
  1862.          5.2.3  Signalling point allowed
  1863.                When SCCP  management  receives  a  MTP-RESUME  INDICATION  relating  to  a
  1864.          destination that becomes accessible, SCCP management:
  1865.                1)  resets the congestion level of that signalling point.
  1866.                2)  marks the translation as appropriate:
  1867.                   -   "translate to primary node" if that signalling point has a backup.
  1868.                3)  marks as "allowed" the status of that signalling point.
  1869.                4)  initiates the subsystem status test procedure (S 5.3.4) with  affected
  1870.                   subsystems at that signalling point.
  1871.                5)   initiates  a  local  broadcast  (S  5.3.6)   of   "signalling   point
  1872.                   inaccessible" information for that signalling point.
  1873.          5.2.4  Signalling point congested
  1874.                When  SCCP  management  receives  a  MTP-status  indication   relating   to
  1875.          signalling network congestion to a signalling point, SCCP management:
  1876.                1)  updates that signalling point status to reflect the congestion.
  1877.                2)  initiates a local broadcast (S 5.3.6) of "signalling point  congested"
  1878.                   information for that signalling point.
  1879.          5.3    Subsystem status management
  1880.          5.3.1  General
  1881.                Subsystem status management updates translation and  status  based  on  the
  1882.          information of failure, withdrawal, congestion9),  and  recovery  of  subsystems.
  1883.          This allows alternative routing to backup systems, if  appropriate.  Local  users
  1884.          are informed of the status of their backup subsystems.
  1885.          5.3.2  Subsystem prohibited
  1886.          5.3.2.1   Receipt of messages for a prohibited subsystem
  1887.                If SCCP routing control receives a message, whether originated  locally  or
  1888.          not, for a prohibited  local  system,  SCCP  routing  control  invokes  subsystem
  1889.          prohibited control. A Subsystem-Prohibited message is  sent  to  the  originating
  1890.          signalling point if the  originating  subsystem  is  not  local  (the  OPC  is  a
  1891.          parameter in the MTP-TRANSFER INDICATION primitive). The action, if  any,  to  be
  1892.          taken, if the originating subsystem is local, is for further study.
  1893.  
  1894.  
  1895.  
  1896.  
  1897.  
  1898.  
  1899.  
  1900.  
  1901.  
  1902.  
  1903.  
  1904.  
  1905.  
  1906.  
  1907.  
  1908.  
  1909.  
  1910.  
  1911.  
  1912.          9) Subsystem congestion control is for further study.
  1913.  
  1914.  
  1915.  
  1916.                                                         Fascicle VI.7 - Rec. Q.714   PAGE1
  1917.  
  1918.                5.3.2.2   Receipt of Subsystem-Prohibited message or N-STATE REQUEST primitive or 
  1919.                local user failed
  1920.                Under one of the following conditions:
  1921.                a)  SCCP  management  receives  a  Subsystem-Prohibited  message  about  a
  1922.                   subsystem marked allowed, or
  1923.                b)  a N-STATE REQUEST primitive with "User-out-of-service" information  is
  1924.                   invoked by a subsystem marked allowed, or
  1925.                c)  SCCP management detects that a local subsystem has failed,
  1926.          then SCCP management does the following:
  1927.                1)  marks the translation as appropriate:
  1928.                   -   "translate to backup subsystem" if a backup  subsystem  exists  for
  1929.                       the prohibited subsystem.
  1930.                2)  marks as "prohibited" the status of that subsystem.
  1931.                3)   initiates  a  local  broadcast  (S  5.3.6)  of  "User-out-of-service"
  1932.                   information for the prohibited subsystem.
  1933.                4)  initiates the  subsystem  status  test  procedure  (S  5.3.4)  if  the
  1934.                   prohibited subsystem is not local.
  1935.                5)  forwards the  information  throughout  the  network  by  initiating  a
  1936.                   broadcast (S  5.3.7)  of  Subsystem-Prohibited  messages  to  concerned
  1937.                   signalling points.
  1938.                6)  cancels "ignore subsystem status test" and the associated timer if they 
  1939.                   are in progress and if the newly prohibited subsystem  resides  at  the
  1940.                   local node.
  1941.          5.3.3  Subsystem allowed
  1942.                Under one of the following conditions:
  1943.                a)  SCCP management receives a Subsystem-Allowed message about a subsystem
  1944.                   marked prohibited, or
  1945.                b)  a N-STATE REQUEST  primitive  with  "User-in-Service"  information  is
  1946.                   invoked by a subsystem marked prohibited,
  1947.          then SCCP management does the following:
  1948.                1)  marks the translation as appropriate:
  1949.                   -   "translate to primary subsystem" if that  subsystem  is  duplicated
  1950.                       and the primary subsystem is allowed;
  1951.                   -   "translate to backup subsystem" if that subsystem is duplicated and
  1952.                       the primary subsystem is prohibited.
  1953.                2)  marks as "allowed" the status of that subsystem.
  1954.                3)   initiates  as  a  local  broadcast  (S  5.3.6)  of  "User-in-service"
  1955.                   information for the allowed subsystem.
  1956.                4)  discontinues the subsystem status test relating to that  subsystem  if
  1957.                   such a test was in progress.
  1958.                5)  forwards the  information  throughout  the  network  by  initiating  a
  1959.                   broadcast  (S  5.3.7)  of  Subsystem-Allowed  messages   to   concerned
  1960.                   signalling points.
  1961.          5.3.4  Subsystem status test
  1962.          5.3.4.1   General
  1963.                The subsystem status test procedure is an audit  procedure  to  verify  the
  1964.          status of a subsystem marked prohibited.
  1965.          5.3.4.2   Actions at the initiating node
  1966.                A subsystem status test is initiated when:
  1967.                a)  a Subsystem-Prohibited message is received (S 5.3.2.2), or
  1968.                b)  a  MTP-RESUME  INDICATION  primitive  for  a  previously  inaccessible
  1969.                   signalling point is invoked (S 5.2.3).
  1970.  
  1971.  
  1972.  
  1973.  
  1974.  
  1975.  
  1976.  
  1977.  
  1978.  
  1979.  
  1980.  
  1981.  
  1982.  
  1983.  
  1984.  
  1985.  
  1986.  
  1987.          PAGE96  Fascicle VI.7 - Rec. Q.714
  1988.  
  1989.                A subsystem status test associated with a failed subsystem is commenced  by
  1990.          starting a timer (stat.info) and marking a test in progress. No  further  actions
  1991.          are taken until the timer expires.
  1992.                Upon expiration of the timer, a Subsystem-Status-Test message  is  sent  to
  1993.          SCCP management at the node of the failed subsystem and the timer is reset.
  1994.                The  cycle  continues  until  the  test  is  terminated  by  another   SCCP
  1995.          management function at that node. Termination of the test causes  the  timer  and
  1996.          the test mark to be cancelled.
  1997.          5.3.4.3   Actions at the receiving node
  1998.                When SCCP management receives a Subsystem-Status-Test message and there  is
  1999.          no "ignore subsystem status test" in progress, it checks the status of the  named
  2000.          subsystem. If the subsystem is allowed, a Subsystem-Allowed message  is  sent  to
  2001.          the SCCP management at  the  node  conducting  the  test.  If  the  subsystem  is
  2002.          prohibited, no reply is sent.
  2003.          5.3.5  Coordinated state change
  2004.          5.3.5.1   General
  2005.                A duplicated subsystem may be withdrawn from service without degrading  the
  2006.          performance of the network  by  using  the  coordinated  state  change  procedure
  2007.          described below when its backup is not  local.  The  procedure,  if  any,  to  be
  2008.          specified in case the primary and the backup subsystems are  co-located,  is  for
  2009.          further study.
  2010.          5.3.5.2   Actions at the requesting node
  2011.                When a duplicated subsystem wishes to go  out  of  service,  it  invokes  a
  2012.          N-COORD   REQUEST   primitive.   SCCP   management   at   that   node   sends   a
  2013.          Subsystem-Out-of-Service-Request message to  the  backup  system,  sets  a  timer
  2014.          (coord.chg) and marks the subsystem as "waiting for grant".
  2015.                Arrival of a Subsystem-Out-of-Service-Grant message at the requesting  SCCP
  2016.          management causes the timer (coord.chg) to be cancelled, the "waiting for  grant"
  2017.          state to be cancelled, and a N-COORD CONFIRMATION primitive to be invoked to  the
  2018.          requesting subsystem. Subsystem-Prohibited messages are broadcast  (S  5.3.7)  to
  2019.          concerned signalling points.
  2020.                In addition, an "ignore subsystem status test" timer  is  started  and  the
  2021.          requesting subsystem is marked  as  "ignore  subsystem  status  test".  Subsystem
  2022.          status tests are ignored until the "ignore subsystem status test"  timer  expires
  2023.          or  the   marked   subsystem   invokes   a   N-STATE   REQUEST   primitive   with
  2024.          "User-out-of-service" information.
  2025.                If no "waiting for grant" is associated with the  subsystem  named  in  the
  2026.          Subsystem-Out-of-Service-Grant   message,   the    Subsystem-Out-of-Service-Grant
  2027.          message is discarded and no further action is taken.
  2028.                If the timer associated with the subsystem waiting for  the  grant  expires
  2029.          before a Subsystem-Out-of-Service-Grant message is  received,  the  "waiting  for
  2030.          grant" is cancelled and the request is implicitly denied.
  2031.          5.3.5.3   Actions at the requested node
  2032.                When the SCCP management at the node  at  which  the  backup  subsystem  is
  2033.          located receives the  Subsystem-Out-of-Service-Request  message,  it  checks  the
  2034.          status of local resources10). If the SCCP has sufficient resources to assume  the
  2035.          increased  load,  it  invokes  a  N-COORD  INDICATION  primitive  to  the  backup
  2036.          subsystem. If the SCCP does not have sufficient resources, no further  action  is
  2037.          taken11).
  2038.  
  2039.  
  2040.  
  2041.  
  2042.  
  2043.  
  2044.  
  2045.  
  2046.  
  2047.  
  2048.  
  2049.  
  2050.  
  2051.          10)     Local resources are  whatever  is  critical  to  this  particular  node,  and  are
  2052.          implementation dependent.
  2053.          11)     The possibility of introducing an explicit Subsystem-Out-of-Service-Denial message
  2054.            containing additional information and associated primitive is for further study.
  2055.  
  2056.  
  2057.  
  2058.                                                         Fascicle VI.7 - Rec. Q.714   PAGE1
  2059.  
  2060.                If the backup system has sufficient resources to allow its mate to  go  out
  2061.          of service, it informs SCCP management by invoking a N-COORD RESPONSE  primitive.
  2062.          A Subsystem-Out-of-Service Grant message  is  sent  to  SCCP  management  at  the
  2063.          requesting node. If the backup subsystem does not have sufficient  resources,  no
  2064.          reply is returned12).
  2065.          5.3.6  Local broadcast
  2066.          5.3.6.1   General
  2067.                The local broadcast procedure provides a mechanism to inform local  allowed
  2068.          concerned subsystems of any related subsystem/signalling point status information
  2069.          received.
  2070.          5.3.6.2   User-out-of-service
  2071.                A local broadcast of "User-out-of-service" information is initiated when:
  2072.                a)  a Subsystem-Prohibited message is received about  a  subsystem  marked
  2073.                   allowed (S 5.3.2.2), or
  2074.                b)  an N-STATE REQUEST primitive with "User-out-of-service" information is
  2075.                   invoked by a subsystem marked allowed (S 5.3.2.2)13), or
  2076.                c)   a  local  subsystem  failure  is  detected  by  SCCP  management   (S
  2077.                   5.3.2.2)13),
  2078.                d)  an MTP-PAUSE indication primitive is received (S 5.2.2).
  2079.                SCCP management then informs local allowed concerned SCCP subsystems  about
  2080.          the  subsystem   status   by   invoking   N-STATE   indication   primitive   with
  2081.          "User-out-of-service" information.
  2082.          5.3.6.3   User-in-service
  2083.                A local broadcast of "subsystem-in-service" information is initiated when:
  2084.                a)  a Subsystem-Allowed message  is  received  about  a  subsystem  marked
  2085.                   prohibited (S 5.3.3), or
  2086.                b)  an N-STATE REQUEST primitive  with  "User-in-service"  information  is
  2087.                   invoked by a subsystem marked prohibited (S 5.3.3).
  2088.                SCCP management then  informs  local  allowed  concerned  SCCP  subsystems,
  2089.          except the newly allowed one, about the subsystem status by invoking  an  N-STATE
  2090.          indication primitive with "User-in-service" information.
  2091.          5.3.6.4   Signalling point inaccessible
  2092.                A  local  broadcast  of  "signalling  point  inaccessible"  information  is
  2093.          initiated when an MTP-RESUME primitive is received. SCCP management then  informs
  2094.          local allowed concerned SCCP subsystems about  the  signalling  point  status  by
  2095.          invoking an N-PCSTATE INDICATION primitive  with  "signalling  point  accessible"
  2096.          information.
  2097.          5.3.6.5   Signalling point accessible
  2098.                A  local  broadcast  of  "signalling  point  accessible"   information   is
  2099.          initiated when an MTP-RESUME primitive is received. SCCP management then  informs
  2100.          local allowed concerned SCCP subsystems about  the  signalling  point  status  by
  2101.          invoking an N-PCSTATE INDICATION primitive  with  "signalling  point  accessible"
  2102.          information.
  2103.          5.3.6.6   Signalling point congested
  2104.                A local broadcast of "signalling point congested" information is  initiated
  2105.          when an MTP-STATUS primitive is received.  SCCP  management  then  informs  local
  2106.          allowed concerned SCCP subsystems about the signalling point status  by  invoking
  2107.          an N-PCSTATE indication  primitive  with  "signalling  point  congested  (level)"
  2108.          information.
  2109.  
  2110.  
  2111.  
  2112.  
  2113.  
  2114.  
  2115.  
  2116.  
  2117.  
  2118.  
  2119.  
  2120.  
  2121.  
  2122.                12)     The possibility of introducing an explicit Subsystem-Out-of-Service-Denial message
  2123.            containing additional information and associated primitive is for further study.
  2124.          13)     These cases are applicable when  the  SCCP  is  used  for  routing  between  local
  2125.            subsystems. This function is implementation dependent.
  2126.  
  2127.  
  2128.  
  2129.          PAGE96  Fascicle VI.7 - Rec. Q.714
  2130.  
  2131.                5.3.7  Broadcast
  2132.          5.3.7.1   General
  2133.                The broadcast procedure provides a mechanism that may  be  used  to  inform
  2134.          concerned signalling points of any related subsystem status change  at  local  or
  2135.          adjacent signalling points. It is an optional  procedure  supplementary  to  that
  2136.          defined in S 5.3.2.1. This procedure is suggested not to be used on a  signalling
  2137.          point restart. This matter is for further study.
  2138.                In some circumstances, the number of concerned signalling  points  is  zero
  2139.          and no broadcast is performed. The action taken in this case is  described  in  S
  2140.          5.1.
  2141.          5.3.7.2   Subsystem prohibited
  2142.                A broadcast of Subsystem-Prohibited messages is initiated when:
  2143.                a)  a Subsystem Prohibited message is received about a subsystem presently
  2144.                   marked allowed (S 5.3.2.2), and the affected point code  identified  in
  2145.                   the SSP message is the same as that of the informer  signalling  point,
  2146.                   or
  2147.                b)  an N-STATE REQUEST primitive with "User-out-of-service" information is
  2148.                   invoked by a subsystem marked allowed (S 5.3.2.2), or
  2149.                c)  a local subsystem failure is detected by SCCP management S 5.3.2.2), or
  2150.                d)  a Subsystem-Out-of-Service-Grant message arrives for a subsystem marked 
  2151.                   "waiting for grant" (S 5.3.5.2).
  2152.                This broadcast permits SCCP management to inform all  concerned  signalling
  2153.          points, except the informer signalling  point,  about  the  subsystem  status  by
  2154.          Subsystem-Prohibited messages. SCCP management does not broadcast  if  the  point
  2155.          code of  the  prohibited  subsystem  is  different  from  that  of  the  informer
  2156.          signalling point which originates the Subsystem-Prohibited message.
  2157.          5.3.7.3   Subsystem allowed
  2158.                A broadcast of Subsystem-Allowed messages is initiated when:
  2159.                a)  a Subsystem-Allowed message is received about  a  subsystem  presently
  2160.                   marked prohibited (S 5.3.3), and the affected point code identified  in
  2161.                   the SSA message is the same as that of the informer  signalling  point,
  2162.                   or
  2163.                b)  an N-STATE REQUEST primitive  with  "User-in-service"  information  is
  2164.                   invoked by a subsystem marked prohibited (S 5.3.3).
  2165.                This broadcast permits SCCP management to inform all  concerned  signalling
  2166.          points, except the informer signalling  point,  about  the  subsystem  status  by
  2167.          Subsystem-Allowed messages. SCCP management does not broadcast if the point  code
  2168.          of the allowed subsystem is different from that of the informer signalling  point
  2169.          which originates the Subsystem-Allowed message.
  2170.          5.4    SCMG restart
  2171.                Note - This section is for further study.)
  2172.                On a signalling point restart, an indication is given to the  SCCP  by  the
  2173.          MTP about the signalling points which are accessible after the  restart  actions.
  2174.          For each accessible, concerned signalling point, all subsystems there are  marked
  2175.          allowed. The response method is used to determine the status of  SCCP  subsystems
  2176.          in those signalling points in the absence of the receipt  of  subsystem  allowed,
  2177.          and subsystem prohibited messages, which may have been broadcast from them.
  2178.                At the restarted signalling point, the status of  its  own  subsystems  are
  2179.          not broadcast to concerned signalling points. In this case, the  response  method
  2180.          is used to inform other nodes attempting to access prohibited subsystems  at  the
  2181.          restarted signalling points.
  2182.                The SCCP management procedures specified in Recommendation  Q.714,  S  5.2,
  2183.          describe the normal operation of  management  procedures,  and  do  not  describe
  2184.          signalling point restart actions.
  2185.  
  2186.  
  2187.  
  2188.  
  2189.  
  2190.  
  2191.  
  2192.  
  2193.  
  2194.  
  2195.  
  2196.  
  2197.  
  2198.  
  2199.  
  2200.                                                         Fascicle VI.7 - Rec. Q.714   PAGE1
  2201.  
  2202.