home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Standards
/
CD2.mdf
/
ccitt
/
1992
/
q
/
q85.asc
< prev
next >
Wrap
Text File
|
1991-12-31
|
36KB
|
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.