home *** CD-ROM | disk | FTP | other *** search
Text File | 1991-12-31 | 34.8 KB | 1,243 lines |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- - 2 -
- AP IX-99-E
-
-
- Contents of Recommendation Q.85
- COMMUNITY OF INTEREST SUPPLEMENTARY SERVICES
- 1. Closed user group
-
- 2. ISDN networking (under study)
-
- 3. Private numbering plan (under study)
-
-
- *
-
- * *
-
-
-
-
- Recommendation Q.85
-
-
- COMMUNITY OF INTEREST SUPPLEMENTARY SERVICES
-
- 1. Closed user group
-
- 1.1 Introduction
-
- The supplementary service closed user group (CUG) makes provision for a
- group of users to meet security requirements of certain applications by
- providing restrictions, which prevent non-members from reaching these applications.
-
- The basic facility provides, via the ISDN, the CUG members with
- controlled intercommunication exclusively amongst themselves and denies access into or
- outside the group. This facility can be extended to include outgoing and/or incoming
- access for specified CUG members.
-
- 1.2 Definition of functional model
-
- 1.2.1 Functional model description
-
- The high level functional model for the CUG service contains the
- following network addressable functional entities:
-
-
-
-
- - 3 -
- AP IX-99-E
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- FIGURE 1-1/Q.85
-
- CUG service functional model
-
-
- FE 1: originating CUG agent
- FE 2: outgoing CUG determination
- FE 3: outgoing CUG control
- FE 4: incoming CUG determination
- FE 5: incoming CUG control
- FE 6: destination CUG agent
-
- 1.2.2.1 Outgoing CUG determination entity (FE 2)
-
- It has the ability:
-
- - to identify a CUG call;
-
- - to check the CUG subscription of the calling user;
-
- - to access the outgoing CUG control entity
-
- 1.2.2.2 Outgoing CUG control entity (FE 3)
-
- It performs:
-
- - the validation checks of CUG information of a calling user;
-
- - the conversion of the CUG index to an interlock code.
-
- 1.2.2.3 Incoming CUG determination entity (FE 4)
-
- It has the ability:
-
- - to identify a CUG call;
-
- - to check the CUG subscription of the called user;
-
- - to access the incoming CUG control entity.
-
-
-
-
-
-
-
-
- - 4 -
- AP IX-99-E
-
-
- 1.2.2.4 Incoming CUG control entity (FE 5)
-
- It performs:
-
- - the conversion of the interlock code to CUG index;
-
- - the validation checks of CUG information of a called user
- (including the compatibility with the called user
- class - CUG IA - in case of an ordinary incoming call).
-
- Note - FE 3 and FE 5 are coupled in the sense that they handle a common set of
- data (interlock codes).
-
- 1.2.3 Relationship to basic service
-
- Refer to 1.6 for the physical location of each entity residing in the
- following figure.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- FIGURE 1-2/Q.85
-
- Relationship to basic service model
- First case: type A of scenario
-
-
-
-
-
- - 5 -
- AP IX-99-E
-
-
- 1.3. Information flow description
-
- 1.3.1 Information flow diagrams
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Note 1 - This information flow may be omitted.
-
-
- FIGURE 1-3/Q.85
-
- Successful CUG calls
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- - 6 -
- AP IX-99-E
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- FIGURE 1-4/Q.85
-
- Unsuccessful CUG calls - Case 1
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- FIGURE 1-5/Q.85
-
- Unsuccessful CUG calls - Case 2
-
-
-
- - 7 -
- AP IX-99-E
-
-
- 1.3.2 Definition of individual information flows
-
- The parameters that are carried on the information flows in the
- successful case are as follows:
-
- 1.3.2.1 SETUP (FE 1 - FE 2) - in addition to called party number and CLI
-
- - nothing, or
-
- - index, or
-
- - index + OA indication.
-
- 1.3.2.2 ENQUIRY (FE 2 - FE 3) - carries the same information as SETUP (FE 1 -
- FE 2) except called party number.
-
- 1.3.2.3 ENQUIRY (FE 3 - FE 2):
-
- - nothing, or
-
- - interlock code, or
-
- - interlock code + OA indication.
-
- 1.3.2.4 SETUP (FE 2 - FE 4) - in addition to called party number
-
- - nothing, or
-
- - interlock code, or
-
- - interlock code + OA indication.
-
- 1.3.2.5 ENQUIRY (FE 4 - FE 5) - carries exactly the same information as SETUP
- (FE 2 - FE 4).
-
- 1.3.2.6 ENQUIRY (FE 5 - FE 6):
-
- - nothing, or
-
- - index, or
-
- - index + OA indication.
-
- 1.4. Functional entity actions
-
-
-
-
-
-
-
-
- - 8 -
- AP IX-99-E
-
-
- FE 1 - A user initiates call SETUP request with the CUG index code
- (when a preferential CUG is used, no index code is designated).
-
- FE 2 - identify a CUG call and receive CUG information,
-
- - CUG subscription check of the calling user.
-
- FE 3 - Outgoing validation check:
-
- 1) CUG index code check of a calling user (when no index code
- is designated, preferential CUG is used);
-
- 2) outgoing barring check within CUG;
-
- When any logical contradiction is detected in the above
- procedure, a call is rejected (see Table 1-1/Q.85).
-
- - conversion of the index code to an interlock code.
-
- FE 4 - identify an incoming CUG call and receive CUG information;
-
- - CUG subscription check of the called user.
-
- FE 5 - incoming validation check:
-
- 1) incoming barring check within CUG;
-
- 2) if interlock codes do not match between a calling user and
- a called user, a call is rejected;
-
- 3) ordinary incoming call check (CUG IA);
-
- When any logical contradiction is detected in the above
- procedure, a call is rejected (see Table 1-2/Q.85).
-
- - an index code corresponding to the designated interlock code is
- extracted from CUG data of a called user.
-
- FE 6 - a user checks whether or not the designated index code exists in
- the index code list of his own. A user shall give proper
- responses.
-
-
-
-
- - 9 -
- AP IX-99-E
-
- 1.5. SDL diagrams for functional entities
-
- 1.5.1 FE 1 originating CUG agent
-
- FE 1 has the same SDL diagram as the CCA FE (basic call) except that
- the SETUP information flow to the FE 2 must carry additional information
- (index or index + OA or nothing).
-
-
-
-
-
-
-
-
-
- - 10 -
- AP IX-99-E
-
- 1.5.2 FE 2 outgoing CUG determination
-
- Refer to the following figure
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- FIGURE 1-6/Q.85
-
- SDL diagram for FE 2
-
-
-
-
- - 11 -
- AP IX-99-E
-
- 1.5.3 FE 3 outgoing CUG control
-
- Refer to the following figure
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- FIGURE 1-7/Q.85
-
- FE 3
-
-
-
-
-
-
-
-
- - 12 -
- AP IX-99-E
-
-
- TABLE 1-1/Q.85
-
- CUG interpretation table (outgoing side)
-
- ┌──────────────────┬──────────┬───────────┬───────────┬─────────────┐
- │ SETUP │CUG with │ CUG with │CUG without│No. CUG INFO.│
- │ presen-│index │ index │index │ │
- │Calling tation │ │ │ │Ordinary │
- │user class │OA=OFF │ OA=ON │OA=ON │subscriber │
- ├───┬────┬────┬────┤ │ │ │ │
- │ │CUG+│CUG+│ │ │ │ │ │
- │CUG│ OA │ OA │pCUG│ │ │ │ │
- │ │(E) │(I) │ │ │ │ │ │
- ├───┼────┼────┼────┼──────────┼───────────┼───────────┼─────────────┤
- │ Y │ │ │ │Specified │ Specified │ Rejected │ Rejected │
- │ │ │ │ │CUG *1│ CUG *1│ │ │
- ├───┼────┼────┼────┼──────────┼───────────┼───────────┼─────────────┤
- │ │ Y │ │ │Specified │ Specified │ Ordinary │ Rejected │
- │ │ │ │ │CUG │ CUG with │ call │ │
- │ │ │ │ │ *1│ OA *2│ │ │
- ├───┼────┼────┼────┼──────────┼───────────┼───────────┼─────────────┤
- │ │ │ Y │ │Specified │ Specified │ Ordinary │ Ordinary │
- │ │ │ │ │CUG with │ CUG with │ call │ call │
- │ │ │ │ │OA *1│ OA *2│ │ │
- ├───┼────┼────┼────┼──────────┼───────────┼───────────┼─────────────┤
- │ Y │ │ │ Y │Specified │ Specified │ pCUG │ pCUG │ FE 3
- │ │ │ │ │CUG *1│ CUG *1│ *1│ *1│
- ├───┼────┼────┼────┼──────────┼───────────┼───────────┼─────────────┤
- │ │ Y │ │ Y │Specified │ Specified │ pCUG with │ pCUG │
- │ │ │ │ │CUG │ CUG with │ OA │ │
- │ │ │ │ │ *1│ OA *2│ *2│ *2│
- ├───┼────┼────┼────┼──────────┼───────────┼───────────┼─────────────┤
- │ │ │ Y │ Y │Specified │ Specified │ pCUG with │ pCUG with │
- │ │ │ │ │CUG with │ CUG with │ OA │ OA │
- │ │ │ │ │OA *1│ OA *1│ *1│ *2│
- └───┴────┴────┴────┴──────────┴───────────┴───────────┴─────────────┘
- . . . . . . . . .
- . . . . . . . . .
- . . . . . . . . .
- ┌──────────────────┬──────────────────────────────────┬─────────────┐
- │ Calling user is │ REJECT │ Ordinary │
- │ NOT CUG │ │ call │ FE 2
- └──────────────────┴──────────────────────────────────┴─────────────┘
-
- *1 : In case of OCB (CUG), a call is rejected
- *2 : In case of OCB (CUG), a call is interpreted as an ordinary call
- OA(E) : Outgoing access explicit
- OA(I) : Outgoing access implicit
- OA : Outgoing access allowed
- OCB : Outgoing access barred within the CUG
- pCUG : Preferential call
- Y : Yes
- Note 1 - When an illegal index code is received, the outgoing call is rejected.
- Note 2 - All the user classes are not necessarily supported by all the networks.
- User classes to be supported are network dependent.
-
-
-
-
- - 13 -
- AP IX-99-E
-
- 1.5.4 FE 4 incoming CUG determination
-
- Refer to the following figure
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- FIGURE 1-8/Q.85 (1 of 2)
-
- FE 4
-
-
-
-
-
-
-
-
-
- - 14 -
- AP IX-99-E
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- FIGURE 1-8/Q.85 (2 of 2)
-
- FE 4
-
-
-
- - 15 -
- AP IX-99-E
-
-
- 1.5.5 FE 5 incoming CUG control
-
- Refer to the following figure
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- FIGURE 1-9/Q.85
-
- FE 3
-
-
-
-
-
-
-
-
- - 16 -
- AP IX-99-E
-
-
- TABLE 1-2/Q.85
-
- CUG checking in incoming side
-
- ┌─────────────────┬──────────────────────────────┬─────────────┐
- │ Called│ Called user is CUG │ Called user │
- │ user's├─────────────┬────────────────┤ is not CUG │
- │ class │CUG with or │ CUG IA with or │ │
- │ │without pCUG │ without pCUG │ │
- │SETUP ├───────┬─────┼─────────┬──────┤ │
- │presentation │No ICB │ ICB │ No ICB │ ICB │ │
- ├─────────────────┼───────┼─────┼─────────┼──────┼─────────────┤
- │ │M (1) │ │ M (1) │ │ │
- │CUG ├───────┤ REJ ├─────────┤ REJ │ REJ │
- │ │NM REJ │ │ NM REJ │ │ │
- ├─────────────────┼───────┼─────┼─────────┼──────┼─────────────┤
- │ │M (1) │ │ M (2) │ │ │
- │CUG and OA ├───────┤ REJ ├─────────┤ (3) │ (3) │
- │ │NM REJ │ │ NM (3) │ │ │
- ├─────────────────┼───────┼─────┼─────────┼──────┼─────────────┤
- │Ordinary │ REJ │ REJ │ (3) │ (3) │ (3) * │
- └─────────────────┴───────┴─────┴─────────┴──────┴─────────────┘
-
- ICB: Incoming access barred within the CUG
-
- Note - Since CUG OA user class is not concerned in the incoming case, it is not shown
- in the above list. It shall be regarded that CUG OA user class is the same as user
- class CUG, and CUG OA/IA is the same as user class CUG IA in this table.
-
- - Most of the table is performed in FE 5.
-
- Notes to the TABLE 1-2/Q.85
-
- Note 1 - (1)-(3) shows CUG parameter to be used in the SETUP to the called user.
- (1) - CUG (index)
- (2) - CUG + OA (index + OA mark)
- (3) - No CUG (ordinary call)
-
- Note 2 - ICB means incoming calls barred within the CUG. The interpretation
- logic is changed in this case as shown in each column in the table. For
- example:
-
- ┌───────┬─────┐
- │No ICB │ ICB │
- ├───────┼─────┤
- │M (1) │ REJ │
- └───────┴─────┘
-
- This means that when the interlock codes are matched and no ICB is
- applied for the CUG, then (1) is used. However, when ICB is applied for the CUG,
- the incoming call is rejected even if interlock codes are matched.
-
- Note 3 - M means that the interlock code is matched with the CUG of the called
- user.
-
- Note 4 - NM means "not matched".
-
- Note 5 - REJ means that an incoming call is rejected.
-
- Note 6 - Interpretation logic, e.g.:
- ┌ ─┐
- │ M │
- │(3) │
- └ ─┘
-
-
-
- - 17 -
- AP IX-99-E
-
- means that when matched with CUG, no CUG selection facility field is set in the
- SETUP to the called user.
-
- 1.5.6 FE 6 destination in CUG agent
-
- FE 6 has the same SDL diagram as the CCA FE (basic call) except that the
- SETUP information flow to the FE 6 must carry additional information (index or
- index + OA mark or nothing).
-
- 1.5.7 Basic call hooks
- See the following two diagrams.
-
-
-
-
-
-
-
-
- - 18 -
- AP IX-99-E
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- FIGURE 1-10/Q.85 (1 of 5)
-
- C C Functional Entity (r1-ri) i = 1,2(based on Recommendation Q.71)
-
-
-
- - 19 -
- AP IX-99-E
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- FIGURE 1-10/Q.85 (2 of 5)
-
- C C Functional Entity (r1-ri) i = 1,2
- (based on Recommendation Q.71)
-
-
-
-
-
-
-
-
- - 20 -
- AP IX-99-E
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- FIGURE 1-10/Q.85 (3 of 5)
-
- C C Functional Entity (r1-ri) i = 1,2)
- (based on Recommendation Q.71)
-
-
-
- - 21 -
- AP IX-99-E
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- FIGURE 1-10/Q.85 (4 of 5)
-
- C C Functional Entity (r2-ri) i = 1,2
- (based on Recommendation Q.71)
-
-
-
-
-
-
-
-
-
- - 22 -
- AP IX-99-E
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- FIGURE 1-10/Q.85 (5 of 5)
-
- C C Functional Entity (r2-ri) i = 1,2(based on Recommendation Q.71)
-
-
-
- - 23 -
- AP IX-99-E
-
-
- 1.6 Network physical allocation scenarios
-
- TABLE 1-3/Q.85
-
- Network physical allocation scenario A
- ┌────┬────────┬─────────┬─────────┬─────────┬─────────┬─────────┐
- │ │ │ │ │ │ │ │
- │ │ FE 1 │ FE 2 │ FE 3 │ FE 4 │ FE 5 │ FE 6 │
- ├────┼────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
- │A.1 │ TE/NT2 │ LE1 │ LE1 │ LE2 │ LE2 │ TE/NT2 │
- │A.2 │ TE/NT2 │ LE1 │ DB1 │ LE2 │ DB1 │ TE/NT2 │
- │A.3 │ TE/NT2 │ LE1 │ DB1 │ LE2 │ DB2 │ TE/NT2 │
- │A.4 │ TE │ NT2A │ NT2A │ NT2A │ NT2B │ TE │
- └────┴────────┴─────────┴─────────┴─────────┴─────────┴─────────┘
- The network scenario A.1 represents the decentralized approach of the CUG
- service implementation.
-
- The network scenario A.2 describes the fully centralized approach with a
- unique data base (DB1).
-
- The network scenario A.3 describes a centralized approach with two data
- bases (DB1 and DB2).
-
- In the network scenario A.4, the Cug service is handled in the NT2s and
- then the network is transparent for this service.
-
-
-
-
-
-
-
-
-