home *** CD-ROM | disk | FTP | other *** search
Text File | 1991-12-22 | 86.2 KB | 3,071 lines |
-
-
-
- 5i'
-
-
- Figure 1/Q.724, p. 1
-
-
-
-
-
-
-
- Figure 2/Q.724, p. 2
-
-
-
-
-
- Figure 3/Q.724 (feuillet 1 sur 7), p. 3
-
-
-
-
-
- Figure 3/Q.724 (feuillet 2 sur 7), p. 4
-
-
-
-
-
- Figure 3/Q.724 (feuillet 3 sur 7), p. 5
-
-
-
-
-
- Figure 3/Q.724 (feuillet 4 sur 7), p. 6
-
-
-
-
-
- Figure 3/Q.724 (feuillet 5 sur 7), p. 7
-
-
-
-
-
- Figure 3/Q.724 (feuillet 6 sur 7), p. 8
-
-
-
-
-
- Figure 3/Q.724 (feuillet 7 sur 7), p. 9
-
-
-
-
-
-
-
-
-
-
-
-
-
- Figure 4/Q.724, p. 10
-
-
-
-
-
- Figure 5/Q.724, p. 11
-
-
-
-
-
- Figure 6/Q.724 (feuillet 1 sur 2), p. 12
-
-
-
-
-
- Figure 6/Q.724 (feuillet 2 sur 2), p. 13
-
-
-
-
-
- Figure 7/Q.724, p. 14
-
-
-
-
-
- Figure 8/Q.724 (feuillet 1 sur 4), p. 15
-
-
-
-
-
- Figure 8/Q.724 (feuillet 2 sur 4), p. 16
-
-
-
-
-
- Figure 8/Q.724 (feuillet 3 sur 4), p. 17
-
-
-
-
-
- Figure 8/Q.724 (feuillet 4 sur 4), p. 18
-
-
-
-
-
- Figure 9/Q.724, p. 19
-
-
-
-
-
-
-
-
-
-
-
- Figure 10/Q.724, p. 20
-
-
-
-
-
- Figure 11/Q.724, p. 21
-
-
-
-
-
- Figure 12/Q.724, p. 22
-
-
-
-
-
- Figure 13/Q.724, p. 23
-
-
-
-
-
- Figure 14/Q.724 (feuillet 1 sur 2), p. 24
-
-
-
-
-
- Figure 14/Q.724 (feuillet 2 sur 2), p. 25
-
-
-
-
-
- Figure 15/Q.724 (feuillet 1 sur 2), p. 26
-
-
-
-
-
- Figure 15/Q.724 (feuillet 2 sur 2), p. 27
-
-
-
-
-
- Figure 16/Q.724 (feuillet 1 sur 2), p. 28
-
-
-
-
-
- Figure 16/Q.724 (feuillet 2 sur 2), p. 29
-
-
-
-
-
-
-
-
-
-
-
- Figure 17/Q.724 (feuillet 1 sur 2), p. 30
-
-
-
-
-
- Figure 17/Q.724 (feuillet 2 sur 2), p. 31
-
-
-
-
-
- Figure 18/Q.724 (feuillet 1 sur 2), p. 32
-
-
-
-
-
- Figure 18/Q.724 (feuillet 2 sur 2), p. 33
-
-
-
-
-
- Figure 19/Q.724 (feuillet 1 sur 2), p. 34
-
-
-
-
-
- Figure 19/Q.724 (feuillet 2 sur 2), p. 35
-
-
-
-
-
- References
-
-
- [1] CCITT Recommendation Sending sequence of numerical (or
- address) signals , | Rec. Q.107.
-
- [2] CCITT Recommendation Performance requirements , |
- Rec. Q.504.
-
- [3] CCITT Recommendation Special release arrangements , |
- Rec. Q.118.
-
- [4] CCITT Recommendation Overflow-alternative,
- routing-rerouting automatic repeat attempt , | Rec. Q.12.
-
- [5] CCITT Recommendation Interruption control , |
- Rec. Q.416.
-
-
-
- Recommendation Q.725
-
-
-
-
-
-
-
-
-
- SIGNALLING PERFORMANCE IN THE TELEPHONE APPLICATION
-
-
-
-
- 1 Introduction
-
-
- This Recommendation gives the requirements of the telephone
- application of Signalling System No. 7.
-
- In Recommendation Q.706, the Message Transfer Part performance
- is described. The Message Transfer Part is the basis of the tele-
- phone application of Signalling System No. 7 and provision of a
- signalling network to serve the telephone service must take account
- of the performance of the Message Transfer Part and the require-
- ments of the telephone application. For example, taking account of
- the message transfer times detailed in Recommendation Q.706 and the
- requirements for message transfer times between two telephone
- exchanges, a figure may be derived for the total permissible number
- of signalling links in signalling relations in tandem for a partic-
- ular call.
-
-
- 2 Unsuccessful calls due to signalling malfunction
-
-
- The proportion of calls that are unsuccessful due to signal-
- ling malfunction should be less than 1 in 105.
-
- By means of error detection (see Recommendation Q.703) as well
- as transmission fault indication (see Recommendations G.732 [1]
- and G.733 [2]), it is ensured that, overall, not more than one
- error in 108 of all signal units transmitted is accepted and will
- cause false operation.
-
- Unsuccessful calls may be caused by undetected errors, loss of
- messages or messages delivered out of sequence (during emergency
- situations within the signalling network) and may result in:
-
- - incomplete call set-up,
-
- - misrouted calls (e.g. connection of wrong
- numbers),
-
- - calls routed correctly but mishandled (e.g. false
- clearing).
-
-
- 3 Unavailability of a signalling route set
-
-
- The overall unavailability of a signalling route set causing
- the unavailability of a signalling relation should not exceed a
- total of 10 minutes per year.
-
- Note - The availability of a signalling route set within a
-
-
-
-
-
-
-
-
-
- signalling network may be enhanced by replication of signalling
- links, signalling paths and signalling routes.
-
-
- 4 Labelling potential
-
-
- The label of the Telephone User Part of Signalling System
- No. 7 provides the potential to identify 16 | 84 signalling points
- and up to 4096 speech circuits for each signalling relation.
-
-
-
- 5 Cross-office transfer time
-
-
-
- 5.1 Functional reference points and transfer time com-
- ponents
-
-
-
- Figure 1/Q.725, p.
-
-
-
- 5.2 Definitions
-
-
- a) cross-office transfer time, Tvcvu
-
- Tc\duis the period which starts when the last bit of the
- signal unit leaves the incoming signalling data link and ends when
- the last bit of the signal unit enters the outgoing signalling data
- link for the first time. It also includes the queueing delay in the
- absence of disturbances but not the additional queueing delay
- caused by retransmission.
-
- b) user handling time, Tvhvu
-
- Th\duis the period which starts when the last bit of the
- message has entered the Telephone User Part and ends when the last
- bit of the derived message has left the Telephone User Part.
-
-
- 5.3 Queueing delay
-
-
- The formulae for the queueing delays are described in
- Recommendation Q.706, S 4.2.
-
- The telephone traffic model assumed is given in Table 1/Q.725,
- from which the proportion of signal messages may be obtained as
- shown in Table 2/Q.725. Using Table 2/Q.725, examples of queueing
- delays are calculated as shown in Figures 2/Q.725 to 5/Q.725, where
- one call attempt per second per 64 kbit/s signalling data link may
- yield 0.00577 Erlang of the traffic loading of each channel.
-
-
-
-
-
-
-
-
-
- 5.4 Estimates for message transfer time
-
-
- The figures in Table 3/Q.725 are related to a signalling bit
- rate of 64 kbit/s.
-
-
- 5.5 Effect of retransmission
-
-
- As a consequence of correction by retransmission, not more
- than one in 104 signals should be delayed more than 300 ms as a
- long-term average. This requirement refers to each signalling link.
-
- This requirement is laid down in order to ensure satisfactory
- answer delays.
-
-
- H.T. [T10]
- TABLE 1/Q.725
- Traffic model
-
- __________________________________________
- Sending procedure "En bloc" Overlap
- __________________________________________
-
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- _______________________________________________________________________
- Type of call AW SB CC AB AW SB CC AB
- _______________________________________________________________________
- Percent calls 30 10 5 5 30 10 5 5
- _______________________________________________________________________
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- {
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Others 112 3,5 2 3 0 3,5 2 3 2
- _______________________________________________________________________
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- AW Answered SB Subscriber busy and not answered CC Circuit conges-
- tion AB Abortive
-
- Note - The assumptions used in this model are chosen for illustra-
- tive purposes, and should not be considered to be typical.
- Tableau 1/Q.725 [T1.725], p. 37
-
-
-
- Blanc
-
-
-
-
-
-
-
-
-
- H.T. [T2.725]
- TABLE 2/Q.725
- Proportion of messages
-
- ___________________________________________________________________________
- Length (bits) 176 152 128 112 104 Total
- ___________________________________________________________________________
- {
- Messages per call
- in both directions
- } 0.45 0.5 0.45 2.0 2.9 6.3
- ___________________________________________________________________________
- Percent 7.1 |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
- 7.9|
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
- 7.1 |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
- 31.7|
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
- 46.0
-
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
- 100 |
- ___________________________________________________________________________
- {
- Mean message
- length (T
- m
- )
- } 117.2 bits
- ___________________________________________________________________________
- k 1 1.032
- ___________________________________________________________________________
- k 2 1.107
- ___________________________________________________________________________
- k 3 1.239
- ___________________________________________________________________________
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Tableau 2/Q.725 [T2.725], p. 38
-
-
-
- Figure 2/Q.725, p. 39
-
-
-
-
-
- Figure 3/Q.725, p. 40
-
-
-
-
-
- Figure 4/Q.725, p. 41
-
-
-
- Figure 5/Q.725, p. 42
-
-
-
- H.T. [T3.725]
- TABLE 3/Q.725
- lw(60p) | lw(60p) | lw(30p) | lw(30p) .
-
- Tableau 3/Q.725 [T3.725], p. 43
-
-
-
-
-
-
-
-
-
- References
-
-
- [1] CCITT Recommendation Characteristics of primary PCM
- multiplex equipment operating at 2048 kbit/s , | Rec. G.732.
-
- [2] CCITT Recommendation Characteristics of primary PCM
- multiplex equipment operating at 1544 kbit/s , | Rec. G.733.
-
-
- Blanc
-
-
-
- MONTAGE: PAGE PAIRE = PAGE BLANCHE
-
-
-
-
-
-
-
-
- SECTION 2
-
- ISDN SUPPLEMENTARY SERVICES
-
-
-
- Recommendation Q.730
-
-
- ISDN SUPPLEMENTARY SERVICES
-
-
-
-
- 1 General
-
-
- 1.1 This Recommendation describes the signalling procedures
- for Supplementary Services to be used in conjunction with the ISDN
- User Part defined in Recommendations Q.761-764, Q.766 and the Tran-
- saction Capabilities Applications Part (TCAP) defined in
- Recommendations Q.771-774.
-
-
- Each Supplementary Service has been defined in separate sec-
- tions each containing the complete procedures encompassing both the
- ISDN User Part and the procedures to be used on the top of TCAP
- where appropriate.
-
- Each section contains a general paragraph giving details of
- the specific service with references to the Stage I and II descrip-
- tions defined in the relevant Recommendations of the I.200 and
- Q.80 Series. The call set-up
-
- procedures and the actions taken at originating
- exchanges, etc. are defined. Arrow diagrams showing the message
- flows for both successful and unsuccessful establishment of the
-
-
-
-
-
-
-
-
-
- service are generally included. The formats and codings aspects are
- not defined in this Recommendation but references are made to the
- appropriate ISDN User Part, TC or SCCP Recommendations.
-
-
- 1.2 Information request/response
-
-
- The "information request/response" message interchange
- described in the calling line identity supplementary services uses
- a general request/response mechanism (e.g. INR/INF messages) which
- can be used in the future for supplementary services not currently
- defined (see Recommendation Q.764).
-
-
- 1.3 Exceeding the maximum message length (e.g. ISDN User
- Part 272 octets)
-
-
- If for any reason the combination of basic plus supplementary
- service information causes the overall maximum length of the mes-
- sage (e.g. Initial Address Message) to be exceeded then the
- user-to-user supplementary service 1, if included, should be
- rejected (see S 2 covering interactions).
-
- The combination of other services which may cause the message
- length to be exceeded will depend on the call state and the
- requested service.
-
-
- 1.4 Layout of Recommendation Q.730
-
-
- S 1 General
-
- S 2 User-to-user signalling (Note)
-
- S 3 Close user group
-
- S 4 Calling line identification (presentation and
- restriction)
-
- S 5 Direct dialling in
-
- S 6 Call forwarding (Note)
-
- S 7 Time-out table for supplementary services
- (requires further study)
-
- Note - The text for the explicit invocation of the
- user-to-user signalling has been included as Annex A.
-
-
-
- 2 User-to-user signalling service
-
-
-
-
-
-
-
-
-
-
-
- 2.1 General description of user-to-user service
-
-
- The user-to-user signalling supplementary service(s)
- provide(s) a means of communication between two users by using the
- ISDN User Part or SCCP protocols defined in Recommendations
- Q.711-714 and Q.761-764, 766. In order for the services to be
- usable, they also have to be provided in the access protocol.
-
- User-to-user signalling is used to exchange I.257 information
- between two users to provide the user-to-user services described in
- Recommendation I.257. This section is specific to Signalling
- System No. 7. The general description for services 1-3 may be
- found in the last mentioned Recommendation and the functional
- description in Recommendation Q.87.
-
-
- 2.1.1 User-to-user services
-
-
- Three user-to-user signalling services associated with
- circuit-switched calls that may be provided by the network users
- are:
-
- Service 1: user-to-user signalling exchanged during the
- set-up and clearing phases of a call, within ISDN User Part call
- set-up and release messages as defined in Recommendation Q.763;
-
- Service 2: user-to-user signalling exchanged during call
- set-up between the address complete or call progress messages and
- the answer or connect messages, within user-to-user information
- messages; and
-
- Service 3: user-to-user signalling exchanged while a call
- is in the active state, within user-to-user information messages.
-
- All three services may be used separately or in any combina-
- tion within a single call. As an option at call set-up, users may
- be able to specify whether the requested user-to-user signalling
- service(s) is(are) essential or non-essential for the call (i.e.
- whether the call should be completed or not if user-to-user infor-
- mation cannot be passed). Up to 128 octets of user information may
- be transferred in a message in each of the three services informa-
- tion parameter name, the protocol control indicator or the length
- octets.
-
-
- 2.1.2 Service request
-
-
- _________________________
- During an interim period of time, networks may support
- a lesser number (e.g. 32 octets) due to protocol res-
- trictions; 32 octets will always be supported. Restric-
- tions may apply to calls requesting user-to-user infor-
- mation more than 32 octets.
-
-
-
-
-
-
-
-
-
-
- Service 1 may be requested implicitly by the presence of the
- user-to-user information parameter in the Initial Address Message.
- An implicit request is "non-essential" by default.
-
- Explicit requests of Service 1 and 2 must be in the Initial
- Address Message. Service 3 may be explicitly requested in the Ini-
- tial Address Message during call set-up. When there is an explicit
- request a single user-to-user indicators parameter will be used
- with one of the following indications for each of the three ser-
- vices:
-
- - no information;
-
- - requested, non-essential;
-
- - requested, essential.
-
-
- 2.1.3 Response (Confirmation)
-
-
- If explicit requests are used there should, in general, be
- explicit responses in a user-to-user indicators parameter with one
- of the following indications for each of the three services:
-
- - no information;
-
- - provided;
-
- - not provided.
-
-
- Implicit "not provided" responses occur when:
-
- - Service 1 has been implicitly requested and no
- user-to-user information is received in call set-up or release mes-
- sages; or
-
- - Service 1, 2 or 3 has been explicitly requested
- and there is no indication of acceptance or rejection from call
- control.
-
-
- 2.1.4 Flow control
-
-
- The exchange of user-to-user signalling is limited by flow
- control procedures provided on the access by either the user or
- network. The need for interexchange flow control procedures by the
- ISDN User Part for user-to-user signalling should be evaluated.
-
-
- 2.2 Procedures for user-to-user signalling associated with
- circuit-switched call
-
-
- The following sections only specify the signalling procedure
-
-
-
-
-
-
-
-
-
- used to implicitly invoke the Service 1. Signalling procedures
- defined to support the other services are specified in Annex A.
-
-
- 2.2.1 User-to-user signalling, Service 1
-
-
-
- 2.2.1.1 General characteristics
-
-
- Service 1 allows users to communicate with user-to-user sig-
- nalling by transferring user-to-user information within ISDN User
- Part messages during the call set-up and clearing phases. The
- user-to-user signalling service provided is not a guaranteed ser-
- vice. If for any reason the combination of the basic plus supple-
- mentary service information causes the overall maximum length of
- the message to be exceeded then if the User-to-user Signalling Ser-
- vice 1 is included, then the service should be rejected.
-
-
- 2.2.1.2 User-to-user signalling in the call set-up phase -
- implicit service request
-
-
- Procedures for call set-up are as described in Recommendation
- Q.764, S 2, with the following changes:
-
- Service 1 may be invoked by sending the user-to-user informa-
- tion parameter of variable length that is specified in
- Recommendation Q.763, S 3.34 in an Initial Address Message that is
- requested in a call set-up request from call control. This informa-
- tion parameter is transported across the network and delivered
- unchanged to the terminating call control for the called user. The
- user-to-user indicators parameter will not be sent.
-
- The reception of a user-to-user information parameter in a
- call set-up or release request from the terminating call control is
- an implicit indication of the acceptance of Service 1.
-
- The user or network may not be able to interpret incoming
- user-to-user information. In such situations, the user should dis-
- card this information without disrupting normal call handling. No
- specific signalling is provided by the network to accommodate this
- situation.
-
-
- 2.2.1.3 Interworking
-
-
- In the case of interworking with a non-ISDN network, the
- "interworking" protocol control information will be returned to the
- originating exchange in the first appropriate message, e.g. an
- Address Complete Message. Two ISDN networks that interwork may have
- to retain knowledge of the service request until it is clear
- whether both can support the service.
-
-
-
-
-
-
-
-
-
-
- 2.2.1.4 Rejection of implicit service requests
-
-
- Networks that cannot provide the service requested may not
- return a rejection indication.
-
-
- 2.2.1.5 User-to-user signalling in the call clearing phase
-
-
- A user-to-user information parameter may be included in the
- Release Message. The user-to-user information parameter received at
- the distant exchange in the Release Message is passed to the call
- control for the remote user. In the case of simultaneous clearing
- of the call, the Release Message may not reach the distant local
- exchange and the user-to-user information will be lost.
-
-
-
- 2.2.1.6 Message flow diagrams
-
-
- The message flow diagrams are shown in Figure 1B/FQ.730 as
- well as the use of user-to-user signalling service 1 when impli-
- citly requested in a point-to-point configuration.
-
- The messages shown with dashed lines are not part of the ISDN
- User Part protocol and are for information only. For detailed
- information on the access protocol user-to-user procedures the ISDN
- access protocol Recommendation should be examined.
-
-
- Figure 1/Q.730, p. 44
-
-
-
-
-
-
-
- 2.2.2 Interaction with other supplementary services
-
-
-
- 2.2.2.1 Call forwarding services
-
-
- Interactions with the call forwarding services are shown in
- the call forwarding protocol sections.
-
-
- 2.2.2.2 Call waiting service
-
-
- Interactions with the call waiting service are shown in the
- call waiting protocol sections. (Call waiting is for further
- study.)
-
-
-
-
-
-
-
-
-
- 2.2.2.3 Other services
-
-
- There are no known interactions with services other than those
- listed.
-
-
- 2.2.2.4 State transition diagrams
-
-
- The state transition diagrams may be found in Stage 2 descrip-
- tions of the user-to-user service.
-
-
- 3 Closed user group (CUG)
-
-
-
- 3.1 General
-
-
- The closed user group (CUG) supplementary service enables a
- group of users to intercommunicate only among themselves or, as
- required, one or more users may be provided with incoming/outgoing
- access to users outside the group.
-
- The stage I definition of the CUG service is given in
- Recommendation I.255, and its stage II service definition including
- network functions are given in Recommendation Q.85.
-
- The realization of the CUG facilities is done by the provision
- of interlock codes and is based on various validation checks as
- defined in Q.85 at call set-up, determining whether or not a
- requested call to or from a user having a CUG facility is allowed.
- In particular, a validation check is performed by verifying that
- both the calling and called parties belong to the CUG indicated by
- the interlock code.
-
- The data for each CUG that a user belongs to can either be
- stored at the local exchange to which the user is connected (decen-
- tralized administration of CUG data), or at dedicated point(s) in
- the network (centralized administration of CUG data).
-
- In S 3.2 the call set-up procedure based on decentralized
- administration of CUG data is specified making use of the ISDN User
- Part as defined in Recommendations Q.761-764 and Q.766.
-
- In S 3.3 the call set-up procedure based on centralized
- administration of CUG data is specified making use of the ISDN User
- Part as defined in Recommendations Q.761-764 and Q.766 and the
- Transaction Capabilities Application Part (TCAP) as defined in
- Recommendations Q.771-775.
-
- Section 3.4 specifies the application service element (ASE),
- situated above the Transaction Capabilities Application Part
- (TCAP), and used for CUG validation check with centralized adminis-
- tration of CUG data.
-
-
-
-
-
-
-
-
-
- 3.2 Call set-up procedure with decentralized administration
- of CUG data
-
-
-
- 3.2.1 Originating exchange
-
-
- The actions at the originating exchange at call set-up from a
- user belonging to a CUG depend on the result of the validation
- checks performed there based on whether the user belongs to one or
- more CUGs and on the combination of CUG facilities that applies.
-
-
- a) CUG call without outgoing access
-
- If the result of the validation check indicates that the
- call should be dealt with as a CUG call, the interlock code of the
- selected CUG is obtained. The initial address message forwarded to
- the next exchange then includes the interlock code together with an
- indication that the call is a CUG call without outgoing access. The
- ISUP preference indicator of the forward call indicators parameter
- in the IAM is set to "ISUP required all the way".
-
- b) CUG call with outgoing access
-
- If the result of the validation check indicates that the
- call should be dealt with as a CUG call with outgoing access, the
- interlock code of the selected CUG together with an outgoing access
- indication is obtained. The initial address message forwarded to
- the next exchange then includes the interlock code together with an
- indication that the call is a CUG call for which outgoing access is
- allowed. The ISUP preference indicator of the forward call indica-
- tors parameter in the IAM is set to "ISUP preferred all the way",
- unless another service requires a more stringent setting.
-
- c) Non-CUG call
-
- If the result of the validation check indicates that the
- call should be dealt with as a non-CUG call, the initial address
- message forwarded to the next exchange then does not include an
- interlock code nor a CUG call indication.
-
- d) Call rejected
-
- If the result of the validation check indicates that the
- call is to be rejected, the call set-up is not initiated.
-
-
- 3.2.2 Transit exchange
-
-
- With the possible exception of some gateway exchanges, each
- transit exchange sets up a CUG call as an ordinary call. The infor-
- mation related to the CUG facilities received from the preceding
- exchange, i.e. an interlock code, a CUG call indication - possibly
- with an indication that outgoing access is allowed - is forwarded
-
-
-
-
-
-
-
-
-
- to the succeeding exchange.
-
- In the case of an international CUG call, no special functions
- are required at the gateway exchange provided that the interna-
- tional interlock code assigned to the international CUG concerned
- is used in the national network. However, in the case where a
- national interlock code other than the applicable international
- interlock code is used within a national network, interlock code
- conversion is required at the gateway (or corresponding) exchange.
-
- In case of interworking with a network which does not support
- the CUG facility, the gateway exchange may release the call,
- depending on the contents of the CUG call indicator in the received
- IAM. The action at the gateway exchange, in this case, is indicated
- in Table 1/Q.730. In cases where a call is rejected as the result
- of the interworking, a release message including the cause parame-
- ter indicating ## 88 is sent towards the originating exchange.
-
-
- 3.2.3 Destination exchange
-
-
- At the destination exchange a validation check of the accepta-
- bility of a call is made according to the rule specified in the
- Recommendation Q.85 where either the calling party (as indicated by
- a CUG call indication in the initial address message received) or
- the called party belongs to a CUG. The call set-up is continued
- only in cases where the information received checks with the infor-
- mation stored at the destination exchange. Table 2/Q.730 indicates
- the action to be taken by the destination exchange as the result of
- the validation check.
-
- In cases where a call is rejected as the result of the valida-
- tion check because of incompatible CUG information, a release mes-
- sage including the cause parameter indicating one of the following
- values is sent towards the originating exchange:
-
- ##55: Incoming calls barred within CUG
-
- ##87: Called user not member of CUG
-
- ##88: Incompatible destination
-
- Figure 2/Q.730 illustrates example message flows for CUG calls
- with decentralized administration of CUG data.
-
-
-
- 3.3 Call set-up procedure with centralized administration
- of CUG data
-
-
- In the local exchange an indication is stored, showing only
- whether the user has one or none of the closed user group facili-
- ties.
-
-
-
-
-
-
-
-
-
-
-
- 3.3.1 Originating exchange
-
-
- The originating exchange requests the CUG validation check to
- the dedicated point by invocation of the "CUG check 1" operation
- through TCAP. This operation and associated parameters are
- described in S 3.4 of this Recommendation. The following actions at
- the originating exchange depend on the result of this validation
- check:
-
- a) CUG call indication
-
- If the result of the validation check for the calling user
- at the originating exchange indicates that the check for the cal-
- ling user has been successful, the interlock code of the selected
- CUG possibly together with an outgoing access indication is
- obtained. The initial address message forwarded to the next
- exchange then includes the interlock code together with an indica-
- tion that the call is a CUG call without outgoing access or a CUG
- call with outgoing access.
-
- b) Non-CUG call indication
-
- If the result of the validation check indicates that the
- call should be dealt with as a non-CUG call, the initial address
- message forwarded to the next exchange then does not include an
- interlock code nor a CUG call indication.
-
- c) Call rejected
-
- If the result of the validation check indicates that the
- call is to be rejected, the call set-up is not initiated.
-
-
- 3.3.2 Transit exchange
-
-
- Refer to S 3.2.2.
-
-
- 3.3.3 Destination exchange
-
-
- In the case of an incoming CUG call for which the validation
- check for the calling user has successfully been performed, the
- received initial address message includes the interlock code and
- CUG call indication possibly with an indication that outgoing
- access is allowed. The destination exchange then forwards the
- information received in the initial address message to the dedi-
- cated point for CUG validation check. In this case, the destination
- exchange invokes the "CUG check 2" operation through TCAP. This
- operation and associated parameters are defined in S 3.4 of this
- Recommendation.
-
- a) Check successful indication
-
- If the result of the validation check indicates that the
-
-
-
-
-
-
-
-
-
- check has been successful, the index of the CUG selected for the
- called user and possibly an outgoing access indication are
- obtained. The CUG call set-up request is forwarded to the called
- user with these indications.
-
- b) Non-CUG call indication
-
- If the result of the validation check indicates that the
- call should be dealt with as a non-CUG call, the set-up request of
- a non-CUG call is forwarded to the called user.
-
- c) Call rejected
-
- If the result of the validation check indicates that the
- call is rejected, the reason why the call has been rejected is
- obtained. A release message including the cause parameter indicat-
- ing one of the values as listed in S 3.2.3 is sent towards the ori-
- ginating exchange.
-
-
- 3.3.4 Dedicated point
-
-
- At the dedicated point, the CUG validation check is performed
- according to the rules defined in Recommendation Q.85. The pro-
- cedures between the dedicated point and the exchange follow those
- as defined in the ASE part of this Recommendation.
-
- Figure 3/Q.730 illustrates an example message flow for a CUG
- call with centralized administration of CUG data.
-
- H.T. [T1.730]
- TABLE 1/Q.730
- Action at the gateway with a network without CUG
-
- capability
-
- _______________________________________________________________________________
- CUG call indicator in IAM {
- Action at the gateway exchange
- }
- _______________________________________________________________________________
- CUG without outgoing access {
- Release the call with cause ##88
- }
- _______________________________________________________________________________
- CUG with outgoing access {
- Treat the call as an ordinary call | ua)
- }
- _______________________________________________________________________________
- Non-CUG Treat the call as an ordinary call
- _______________________________________________________________________________
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
-
-
-
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
-
-
-
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- a) Discard the interlock code parameter and change the CUG call
- indicator of the optional forward call indicator to indicate
- non-CUG call or discard the whole parameter if appropriate.
-
-
-
-
-
-
-
-
-
- Tableau 1/Q.730 [T1.730], p. 45
-
- H.T. [T2.730]
- TABLE 2/Q.730
- Handling of a CUG call at the destination exchange
-
- ____________________________________________________________________________________________________________________________________________
- Class of called user
- |
-
- CUG call indicator in IAM CUG match check
- No ICB ICB CUG + IA No ICB
- ____________________________________________________________________________________________________________________________________________
- Match CUG call |
- |
- |
-
- Release cause ##55 CUG call |
- |
- {
-
-
- No match {
-
- {
-
-
-
-
- CUG with OA not allowed Release cause ##55
-
-
-
- ____________________________________________________________________________________________________________________________________________
- Match CUG call |
- |
- Release cause ##55 CUG+OA call |
- |
- Non-CUG call
- No match {
-
-
- CUG with OA allowed
- Non-CUG call |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
-
-
-
- Non-CUG call
-
- ____________________________________________________________________________________________________________________________________________
- Non-CUG - {
- Release the call with cause ##88
- } Non-CUG call Non-CUG call
- ____________________________________________________________________________________________________________________________________________
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- |
- |
- |
- |
- |
-
-
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IA Incoming access
-
- OA Outgoing access
-
- ICB Incoming calls barred
-
- Match The interlock code in the received IAM matches one of the
- CUGs to which the called user belongs.
-
- No match The interlock code does not match any of the CUGs to which
- the called user belongs.
-
- Note - As OA attribute of the called user is of no concern at the
- destination exchange, CUG+OA class is equivalent to CUG, and CUG/IA
- class is equivalent to CUG+IA in this table. Subscription of pre-
- ferential CUG by the called user is also of no concern in this
- table.
- Tableau 2/Q.730 [T2.730], p. 46
-
-
-
-
-
- Figure 2/Q.730, p. 47
-
-
-
-
-
-
-
-
-
-
-
-
- Figure 3/Q.730, p. 48
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-