WPCL 2BJ|x ` Hx   x|@  6'6' X  `  @  <AP IX99E AXX  `  @  <AP IX99E AX   !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) A* A @** A A H0 h Recommendation Q.85 +COMMUNITY OF INTEREST SUPPLEMENTARY SERVICES 1.HClosed user group 1.1HIntroduction  X HThe 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 nonmembers from reaching these applications. HThe 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.2HDefinition of functional model 1.2.1HFunctional model description HThe high level functional model for the CUG service contains the following network addressable functional entities: IFIGURE 11/Q.85 P BCUG service functional modelă HHFE 1: originating CUG agent HHFE 2: outgoing CUG determination HHFE 3: outgoing CUG control HHFE 4: incoming CUG determination HHFE 5: incoming CUG control HHFE 6: destination CUG agent  `  HH1.2.2.1 Outgoing CUG determination entity (FE 2) HIt has the ability: HH© to identify a CUG call; HH© to check the CUG subscription of the calling user; HH© to access the outgoing CUG control entity HH1.2.2.2 Outgoing CUG control entity (FE 3) HIt performs:   HH© the validation checks of CUG information of a calling user;  `  HH© the conversion of the CUG index to an interlock code. HH1.2.2.3 Incoming CUG determination entity (FE 4) HIt has the ability: HH© to identify a CUG call; H to check the CUG subscription of the called user; HH© to access the incoming CUG control entity. HH1.2.2.4 Incoming CUG control entity (FE 5) HIt performs: HH© the conversion of the interlock code to CUG index;   HH© the validation checks of CUG information of a called user (including the compatibility with the called user class CUGIA in case of an ordinary incoming call).  `   X Note FE 3 and FE 5 are coupled in the sense that they handle a common set of data (interlock codes). 1.2.3HRelationship to basic service HRefer to  1.6 for the physical location of each entity residing in the following figure. P P P IFIGURE 12/Q.85 P ?Relationship to basic service modelă AFirst case: type A of scenarioă 1.3.hHInformation flow description 1.3.1HInformation flow diagrams Note 1 This information flow may be omitted. P IFIGURE 13/Q.85 P FSuccessful CUG callsă P IFIGURE 14/Q.85 P AUnsuccessful CUG calls Case 1ă IFIGURE 15/Q.85 P AUnsuccessful CUG calls Case 2ă 1.3.2HDefinition of individual information flows HThe parameters that are carried on the information flows in the successful case are as follows: HH1.3.2.1 SETUP (FE 1 FE 2) in addition to called party number and CLI HH© nothing, or  `  HH© index, or HH© index + OA indication.  x 1.3.2.2 ENQUIRY (FE 2 FE 3) carries the same information as SETUP (FE1 FE2) except called party number. HH1.3.2.3 ENQUIRY (FE 3 FE 2): HH© nothing, or  `  HH© interlock code, or HH© interlock code + OA indication.   HH1.3.2.4 SETUP (FE 2 FE 4) in addition to called party number HH© nothing, or  `  HH© interlock code, or HH© interlock code + OA indication.  1.3.2.5 ENQUIRY (FE 4 FE 5) carries exactly the same information as SETUP (FE2 FE4). HH1.3.2.6 ENQUIRY (FE 5 FE 6): HH© nothing, or  `  HH© index, or HH© index + OA indication. 1.4.hHFunctional entity actions   HFE 1 A user initiates call SETUP request with the CUG index code (when a preferential CUG is used, no index code is designated). HFE 2 identify a CUG call and receive CUG information, HH CUG subscription check of the calling user.  `  HHFE 3 Outgoing validation check:   HHX 1)hCUG index code check of a calling user (when no index code is designated, preferential CUG is used);  `  HHX 2)houtgoing barring check within CUG;   HHX When any logical contradiction is detected in the above procedure, a call is rejected (see Table 11/Q.85).  `  HH conversion of the index code to an interlock code.   HHFE 4 identify an incoming CUG call and receive CUG information;  `  HH CUG subscription check of the called user. HHFE 5 incoming validation check: HHX 1)hincoming barring check within CUG;   HHX 2)hif interlock codes do not match between a calling user and a called user, a call is rejected;  `  HHX 3)hordinary incoming call check (CUG IA);   HHX When any logical contradiction is detected in the above procedure, a call is rejected (see Table 12/Q.85).  `   H HH an index code corresponding to the designated interlock code is HHX extracted from CUG data of a called user.  `   X HHFE 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.  `  1.5.hHSDL diagrams for functional entities 1.5.1HFE 1 originating CUG agent   HFE 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). 1.5.2HFE 2 outgoing CUG determination HRefer to the following figure M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M FFIGURE 16/Q.85 M CSDL diagram for FE 2ă 1.5.3HFE 3 outgoing CUG control HRefer to the following figure M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M FFIGURE 17/Q.85 KFE 3 FTABLE 11/Q.85 M 9CUG interpretation table (outgoing side)ă    SETUP CUG with CUG with CUG without No. CUG INFO.   presen index index index   Callingtation    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   HH*1 : In case of OCB (CUG), a call is rejected *2 : In case of OCB (CUG), a call is interpreted as an ordinary call HHOA(E) : Outgoing access explicit HHOA(I) : Outgoing access implicit HHOA : Outgoing access allowed HHOCB : Outgoing access barred within the CUG HHpCUG : Preferential call HHY : Yes  HHNote 1  When an illegal index code is received, the outgoing call is rejected.  HHNote 2  All the user classes are not necessarily supported by all the networks. User classes to be supported are network dependent. 1.5.4HFE 4 incoming CUG determination HRefer to the following figure IFIGURE 18/Q.85 (1 of 2) U SFE 4ă U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U IFIGURE 18/Q.85 (2 of 2) U SFE 4 1.5.5  FE 5 incoming CUG control HRefer to the following figure MFIGURE 19/Q.85 SFE 3 NTABLE 12/Q.85 U GCUG checking in incoming sideă 5   A  Called Called user is CUG Called user  :  user's is not CUG  7  class CUG with or CUG IA with or   =  without pCUG without pCUG   5 SETUP   : presentation No ICB ICB No ICB ICB   5 B  M (1)  M (1)    A CUGREJREJ REJ  9  NM REJ  NM REJ    5 B  M (1)  M (2)    > CUG and OAREJ(3) (3)  B  NM REJ  NM (3)    5 D Ordinary REJ REJ (3) (3) (3)*  5   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 12/Q.85 HHNote 1  (1)(3) shows CUG parameter to be used in the SETUP to the called user. HH(1) CUG (index) HH(2) CUG + OA (index + OA mark) HH(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: F   G No ICB ICB  F G M (1) REJ  F   HThis 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.  X 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    M  M  M (3)  M    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 HFE 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 P See the following two diagrams. P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P DFIGURE 110/Q.85 (1 of 5) P >C C Functional Entity (r1ri) i = 1,2ă@(based on Recommendation Q.71) P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P DFIGURE 110/Q.85 (2 of 5) P >C C Functional Entity (r1ri) i = 1,2ă @(based on Recommendation Q.71) P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P DFIGURE 110/Q.85 (3 of 5) P =C C Functional Entity (r1ri) i = 1,2) 0(based on Recommendation Q.71) P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P DFIGURE 110/Q.85 (4 of 5) P >C C Functional Entity (r2ri) i = 1,2ă @(based on Recommendation Q.71) P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P DFIGURE 110/Q.85 (5 of 5) P >C C Functional Entity (r2ri) i = 1,2ă0(based on Recommendation Q.71) 1.6 HNetwork physical allocation scenarios ITABLE 13/Q.85 P =Network physical allocation scenario A 0   0         0   FE 1  FE 2  FE 3  FE 4  FE 5  FE 6  0 ? 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 A.4 TE NT2A NT2A NT2A NT2B TE  0   HThe network scenario A.1 represents the decentralized approach of the CUG service implementation. HThe network scenario A.2 describes the fully centralized approach with a unique data base (DB1). HThe network scenario A.3 describes a centralized approach with two data bases (DB1 and DB2). HIn the network scenario A.4, the Cug service is handled in the NT2s and then the network is transparent for this service.