Closed User Group (CUG) using IP Multimedia (IM) Core Network (CN) subsystem, Protocol Specification

3GPP TS 24.654 V9.4.0 (2013-03)
Technical Specification
3rd Generation Partnership Project; 
Technical Specification Group Core Network and Terminals;
Closed User Group (CUG) using IP Multimedia (IM) Core Network (CN) subsystem,
Protocol Specification 
(Release 9)

	
The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP.	
The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented.	
This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this Specification.
Specifications and reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices.


Keywords
GSM, UMTS, CUG, supplementary service, LTE

3GPP
Postal address

3GPP support office address
650 Route des Lucioles - Sophia Antipolis
Valbonne - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Internet
http://www.3gpp.org

Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© 2013, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TTA, TTC).
All rights reserved.

UMTS™ is a Trade Mark of ETSI registered for the benefit of its members
3GPP™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners
LTE™ is a Trade Mark of ETSI currently being registered for the benefit of its Members and of the 3GPP Organizational Partners
GSM® and the GSM logo are registered and owned by the GSM Association

Contents
 TOC \o "1-9" Foreword	 PAGEREF _Toc350843710 \h 5
1	Scope	 PAGEREF _Toc350843711 \h 6
2	References	 PAGEREF _Toc350843712 \h 6
3	Definitions and abbreviations	 PAGEREF _Toc350843713 \h 6
3.1	Definitions	 PAGEREF _Toc350843714 \h 6
3.2	Abbreviations	 PAGEREF _Toc350843715 \h 7
4	Closed User Group (CUG)	 PAGEREF _Toc350843716 \h 8
4.1	Introduction	 PAGEREF _Toc350843717 \h 8
4.2	Description	 PAGEREF _Toc350843718 \h 8
4.3	Operational requirements	 PAGEREF _Toc350843719 \h 8
4.3.1	Provision/withdrawal	 PAGEREF _Toc350843720 \h 8
4.3.2	Requirements on the originating network side	 PAGEREF _Toc350843721 \h 9
4.3.3	Requirements in the terminating network	 PAGEREF _Toc350843722 \h 9
4.4	Coding requirements	 PAGEREF _Toc350843723 \h 10
4.4.1	XML definition	 PAGEREF _Toc350843724 \h 10
4.4.2	SIP-Messages used for CUG	 PAGEREF _Toc350843725 \h 11
4.5	Signalling requirements	 PAGEREF _Toc350843726 \h 11
4.5.0	General	 PAGEREF _Toc350843727 \h 11
4.5.1	Activation/deactivation	 PAGEREF _Toc350843728 \h 11
4.5.1a	Registration/erasure	 PAGEREF _Toc350843729 \h 11
4.5.1b	Interrogation	 PAGEREF _Toc350843730 \h 11
4.5.2	Invocation and operation	 PAGEREF _Toc350843731 \h 11
4.5.2.1	Actions at the originating UA	 PAGEREF _Toc350843732 \h 11
4.5.2.2	Void	 PAGEREF _Toc350843733 \h 12
4.5.2.3	Void	 PAGEREF _Toc350843734 \h 12
4.5.2.4	Actions at the AS of the originating User	 PAGEREF _Toc350843735 \h 12
4.5.2.5	Void	 PAGEREF _Toc350843736 \h 14
4.5.2.6	Void	 PAGEREF _Toc350843737 \h 14
4.5.2.7	Void	 PAGEREF _Toc350843738 \h 14
4.5.2.8	Void	 PAGEREF _Toc350843739 \h 14
4.5.2.9	Void	 PAGEREF _Toc350843740 \h 14
4.5.2.10	Actions at the AS of the terminating user	 PAGEREF _Toc350843741 \h 14
4.5.2.11	Void	 PAGEREF _Toc350843742 \h 14
4.5.2.12	Actions at the terminating UA	 PAGEREF _Toc350843743 \h 14
4.6	Interaction with other services	 PAGEREF _Toc350843744 \h 14
4.6.1	Communication Hold (HOLD)	 PAGEREF _Toc350843745 \h 14
4.6.2	Terminating Identification Presentation (TIP)	 PAGEREF _Toc350843746 \h 14
4.6.3	Terminating Identification Restriction (TIR)	 PAGEREF _Toc350843747 \h 15
4.6.4	Originating Identification Presentation (OIP)	 PAGEREF _Toc350843748 \h 15
4.6.5	Originating Identification Restriction (OIR)	 PAGEREF _Toc350843749 \h 15
4.6.6	Conference calling (CONF)	 PAGEREF _Toc350843750 \h 15
4.6.7	Communication Diversion Services (CDIV)	 PAGEREF _Toc350843751 \h 15
4.6.7.1	Communication Forwarding Unconditional (CFU)	 PAGEREF _Toc350843752 \h 15
4.6.7.2	Communication Forwarding Busy (CFB)	 PAGEREF _Toc350843753 \h 15
4.6.7.3	Call Forwarding No Reply (CFNR)	 PAGEREF _Toc350843754 \h 15
4.6.7.4	Communication Forwarding on Not Logged-in (CFNL)	 PAGEREF _Toc350843755 \h 15
4.6.7.5	Communication Forwarding on Subscriber Not Reachable (CFNRc).	 PAGEREF _Toc350843756 \h 15
4.6.7.6	Communication Deflection (CD)	 PAGEREF _Toc350843757 \h 16
4.6.8	Malicious Communication Identification (MCID)	 PAGEREF _Toc350843758 \h 16
4.6.9	Anonymous Communication Rejection and Communication Barring (ACR/CB)	 PAGEREF _Toc350843759 \h 16
4.6.10	Explicit Communication Transfer (ECT)	 PAGEREF _Toc350843760 \h 16
4.6.11	Closed User Group (CUG)	 PAGEREF _Toc350843761 \h 16
4.6.12	Three-Party (3PTY)	 PAGEREF _Toc350843762 \h 16
4.7	Interactions with other networks	 PAGEREF _Toc350843763 \h 16
4.7.1	Void	 PAGEREF _Toc350843764 \h 16
4.7.2	Void	 PAGEREF _Toc350843765 \h 16
4.7.3	Void	 PAGEREF _Toc350843766 \h 16
Annex A (informative):	Void	 PAGEREF _Toc350843767 \h 17
Annex B (informative):	Change history	 PAGEREF _Toc350843768 \h 17

Foreword
This Technical Specification (TS) was been produced by ETSI Technical Committee Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN) and originally published as ETSI TS 183 054 []. It was transferred to the 3rd Generation Partnership Project (3GPP) in December 2007.The contents of the present document are subject to continuing work within the TSG and may change following formal TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an identifying change of release date and an increase in version number as follows:
Version x.y.z
where:
x	the first digit:
1	presented to TSG for information;
2	presented to TSG for approval;
3	or greater indicates TSG approved document under change control.
y	the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc.
z	the third digit is incremented when editorial only changes have been incorporated in the document.
1	Scope
The present document specifies the stage three Protocol Description of the Closed User Group (CUG) service, based on stage one and two of the ISDN Communication diversion supplementary services. It provides the protocol details in the IP Multimedia (IM) Core Network (CN) subsystem based on the Session Initiation Protocol (SIP) and the Session Description Protocol (SDP).
The present document is applicable to User Equipment (UE) and Application Servers (AS) which are intended to support the CUG supplementary service.
2	References
The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
References are either specific (identified by date of publication, edition number, version number, etc.) or non‑specific.
For a specific reference, subsequent revisions do not apply.
For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
[1]	3GPP TS 22.173: "IP Multimedia Core Network Subsystem (IMS) Multimedia Telephony Service and supplementary services, stage 1".
[2]	3GPP TS 24.229: "Internet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3".
[3]	Void
[4]	Void
[5]	3GPP TS 24.238: "Session Initiation Protocol (SIP) based user configuration; stage 3".
[6]	3GPP TS 24.623: "Extensible Markup Language (XML) Configuration Access Protocol (XCAP) over the Ut interface for Manipulating Supplementary Services".
[7]	IETF RFC 5621: "Message Body Handling in the Session Initiation Protocol (SIP)".
3	Definitions and abbreviations
3.1	Definitions
For the purposes of the present document, the terms and definitions given in 3GPP TS 22.173 [1] and the following apply:
basic service: bearer or teleservice. Within the scope of SIP based networks the identification of a bearer or teleservice can be derived from the SDP used
Closed User Group (CUG) communication: closed user group communication is a communication which is restricted to a pre-defined group of users
Closed User Group (CUG) member: user who has subscribed to the CUG service and is one of the users in the group formed by a particular closed user group
CUG index: parameter used by the originating user to select a particular CUG when originating a communication
NOTE 1:	The index is also used by the network to indicate to the terminating user the CUG from which an incoming communication has originated. This index has only local significance, i.e. the index used by the originating user is, in general, different from the index used by the terminating user to identify the same CUG.
CUG interlock code: means of identifying CUG membership within the network
NOTE 2:	At the originating side, if a CUG match exists, the CUG index identifying a CUG maps to the CUG interlock code for that CUG. If a CUG match exists at the terminating side the CUG interlock code identifying a CUG maps to the CUG index representing that CUG. CUG interlock code has relevance on NN level between AS.
CUG manager: authority representing the interests of all the members of a CUG
NOTE 3:	By planning and controlling the membership and members' options, the manager can provide the overall CUG service expected by the members as a whole. The CUG manager need not be a CUG member and the concept has no signalling implications.
incoming access: arrangement which allows a member of a closed user group to receive communications from outside the closed user group
incoming communications barred within a closed user group: access restriction that prevents a closed user group member from receiving communications from other members of that group
outgoing access: arrangement which allows a member of a closed user group to place communications outside the closed user group
outgoing communications barred within a closed user group: access restriction that prevents a closed user group member from placing communications to other members of that group
preferential CUG: user subscribing to preferential CUG nominates a CUG index which the network uses as a default to identify the required CUG in the absence of any CUG information in the outgoing communication request
NOTE 4:	A preferential CUG applies to a Public ID.
3.2	Abbreviations
For the purposes of the present document, the following abbreviations apply:
ACR	Anonymous Call Rejection
AS	Application Server
CDIV	Communication DIVersion
CONF	CONFerence calling
CUG	Closed User Group
ECT	Explicit Communication Transfer
HOLD	communication HOLD
IA	Incoming Access
ICB	Incoming Communication Barring
IMS	IP Multimedia Subsystem
IP	Internet Protocol
ISDN	Integrated Service Data Network
MCID	Malicious Communication IDentification
OA	Outgoing Access
OCB	Outgoing Communication Barring
OIP	Originating Identification Presentation
OIR	Originating Identification Restriction
PSTN	Public Switched Telephone Network
SDP	Session Description Protocol
SIP	Session Initiation Protocol
TIP	Terminating Identity Presentation
TIR	Terminating Identification Restriction
UA	User Agent
UE	User Equipment
URI	Universal Resource Identifier
XML	eXtensible Markup Language
4	Closed User Group (CUG)
4.1	Introduction
The Closed User Group (CUG) service enables users to form groups of members, whose communication profile is restricted for incoming and outgoing communications. 
4.2	Description
Members of a specific CUG can communicate among themselves but not, in general, with users outside the group.
Specific CUG members can have additional capabilities that allow them to initiate outgoing communications to users outside the group, and/or to accept incoming communications from users outside the group. Specific CUG members can have additional restrictions that prevent outgoing communications to other members of the CUG, or prevent incoming communications from other members of the CUG.
A closed user group consists of a number of members from one or more public, and/or private networks. A specific user may be a member of one or more CUGs. Subscription to a closed user group shall be defined for all communication services, or in relation to one, or to a list of communication services.
4.3	Operational requirements
4.3.1	Provision/withdrawal
The CUG service shall be provided after prior arrangement with the service provider.
As a network option based on subscription basis. The CUG service can be offered with several subscription options.
The provisioning of a new CUG shall require a prior arrangement between the CUG Manager and the network provider.
The provision of the CUG service to a new member and also the assignment of the various CUG service options to a new or existing member shall require a prior arrangement between the CUG member and the network provider in coordination with the CUG Manager of the affected CUG.
The CUG Service is provisioned by the operator.
The subscription options can be divided into three groups:
-	General Subscription options.
-	Per CUG.
-	Per Public ID.
General Subscription options:
A user can be a member of several closed user groups as shown in table 4.3.1.1. Each CUG is bind to the members with an individual CUG Index. Each network operator shall define the maximum number of closed user groups which can be allocated to an individual user.
Table 4.3.1.1: General subscription options 
Subscription options
Value
Closed user groups
List of one or more closed user group indices

Subscription options per CUG:
-	For a particular closed user group, the associated set of general subscription options can apply to one basic service, to a particular set of basic services, or to all basic services (see table 4.3.1.2).
Table 4.3.1.2: Subscription options per CUG
Subscription options
Value
Intra closed user group restrictions (for each closed user group)
None designated
________________________
Incoming communications barred within a closed user group
________________________
Outgoing communications barred within a closed user group
Applicability to basic services (for each closed user group) 
list of one or more basic services
________________________
all basic services 

Subscription options per Public ID:
-	The network shall provide a subscription option in order to enable the user to specify a preferential closed user group (see table 4.3.1.3).
-	The user can request that no preferential closed user group exists, or can request that a particular one of the user's closed user groups (or the only one if a single closed user group applies) is used as a preferential closed user group.
-	The closed user group indices shall be allocated by prior arrangement with the service provider.
-	The choice of preferential closed user group shall be alterable only by service provider action upon request by the served user.
-	The CUG service shall be withdrawn at the customer's request, or for administrative reasons.
Table 4.3.1.3: Subscription options per Public ID
subscription options
Value
Preferential closed user group 
None designated 
________________________
closed user group index 
Outgoing access
allowed per communication
________________________
allowed permanent (default)
________________________
not allowed
Incoming access
allowed
________________________
not allowed

4.3.2	Requirements on the originating network side
For correct interactions with other services, it is necessary for the originating network side to store, for the duration of the communication, details of whether a non-CUG, CUG (without outgoing access) or CUG (with outgoing access) communication was requested in the information sent to the destination network side. The CUG identity (if any) requested of the destination network side must also be retained.
4.3.3	Requirements in the terminating network
For correct interactions with other supplementary services, it is necessary for the destination network side to store, for the duration of the communication, details of whether a non-CUG or CUG (with or without outgoing access) communication request was passed to the user. The CUG identity (if any) requested must also be retained.
4.4	Coding requirements
4.4.1	XML definition
This subclause defines the XML Schema to be used for providing the CUG Interlock code and the CUGcommunicationindicator.
The application/vnd.etsi.cug+xml MIME type used to provide CUG Interlock code, cugIndex outgoingAccessRequest and the CUGcommunicationindicator the XML used shall be coded as following described:


	
		XML Schema Definition for the closed user group 	
		parameter
	
	
	
	
		
			
		
	
	
		
			
		
	
	
		
			
		
	
	
		
			
			
		
	
	
	
		
			
			
		
	
	
	
		
			
				
					
						
						
						
						
					
				
			
		
	


4.4.2	SIP-Messages used for CUG
The following SIP messages are used for the invocation and control of the CUG service.
Table 4.4.1.1: SIP Message used for CUG
SIP Message
SIP URI parameter
Used for
INVITE request
xml MIME CUG

403 (Forbidden) response

rejection because the user does not belongs to the CUG or other failure.
603 (Decline) response

rejection because of barring or CUG with call barring.
500 (Server Internal Error) response

rejection of a CUG communication due to network caused reasons e.g. traversing the communication towards an IMS not supporting the CUG Service.

4.5	Signalling requirements
4.5.0	General
Configuration of supplementary services by the user should: 
-	take place over the Ut interface using XCAP as enabling protocol as described in 3GPP TS 24.623 [6]; or
-	use SIP based user configuration as described in 3GPP TS 24.238 [5];
NOTE:	Other possibilities for user configuration, such as web-based provisioning or pre-provisioning by the operator are outside the scope of the present document, but are not precluded.
The enhancements to the XML schema for use over the Ut interface are described in subclause 4.9.
4.5.1	Activation/deactivation
The CUG service is activated at provisioning or at the subscriber’s request by using the mechanisms specified in subclause 4.5.0.
The CUG service is deactivated at withdrawal or at the subscriber’s request by using the mechanisms specified in subclause 4.5.0.
4.5.1a	Registration/erasure
For registration of CUG-related information, the mechanisms specified in subclause 4.5.0 should be used.
For erasure of CUG-related information, the mechanisms specified in subclause 4.5.0 should be used.
4.5.1b	Interrogation
For interrogation of CUG-related information, the mechanisms specified in subclause 4.5.0 should be used.
4.5.2	Invocation and operation
4.5.2.1	Actions at the originating UA
Explicit request of CUG service:
-	The originating user can explicitly request the CUG service by including in the initial INVITE request an xml CUGrequestType containing the preferred CUG and an outgoing access request.
NOTE:	If the user is subscribed to the preferential CUG service and the preferred CUG is not included, the default CUG will be used.
-	To indicate outgoing access the user shall set the value of the "outgoingAccessRequest" parameter to TRUE.
Implicit request of CUG service:
-	The originating user with CUG service can request the CUG service without including an xml CUGrequestType in the initial INVITE request. In this case the procedures according to 3GPP TS 24.229 [2] shall apply 
Call originating from a user without CUG service:
-	It is possible for a user without CUG service to make a call to a user with CUG service. In this case the procedures according to 3GPP TS 24.229 [2] shall apply.
4.5.2.2	Void
4.5.2.3	Void
4.5.2.4	Actions at the AS of the originating User
Upon receipt of a request for CUG service the AS shall check its validity as shown in table 4.5.2.4.1 in conjunction with the access capabilities contained in the user profile. If a non-valid request is received or the checks cannot be performed, then the network shall reject the communication and return an appropriate indication to the originating user.
A received INVITE request may include an xml CUGrequestType containing the preferred CUG and an outgoing access request.
NOTE:	In particular, a validation check is performed by verifying that both the originating and terminating parties belong to the CUG indicated by the interlock code.
The data for each CUG that a user belongs to, is stored at the AS of the originating User. 
The actions at AS of the originating user at communication set-up from a user belonging to a CUG, depends on the result of the validation checks performed, based on whether the user belongs to one or more CUGs.
a)	CUG without outgoing access.
	If the result of the validation check indicates that the communication should be dealt with as a CUG communication, the interlock code of the selected CUG is obtained. The INVITE request forwarded towards the terminating network then includes the cugInterlockBinaryCode, networkIndicator and cugCommunicationIndicator. 
b)	CUG communication with outgoing access.
	If the result of the validation check indicates that the communication should be dealt with as a CUG communication with outgoing access, the communication shall be treated as a Non-CUG communication. 
c)	Non-CUG.
	If the result of the validation check indicates that the communication should be dealt with as a non‑CUG communication, the INVITE request forwarded towards the terminating network then does not include a cugInterlockBinaryCode, networkIndicator and cugCommunicationIndicator 
d)	Communication rejected.
	If the result of the validation check indicates that the communication is to be rejected, the communication set‑up is not initiated. A 403 (Forbidden) response with a Reason header included shall be sent back as shown in table 4.5.2.4.1.
Table 4.5.2.4.1: Validation check of CUG communication concerning the originating user

Indication from originating user sent within an INVITE request
Calling user class defined within the user profile
INVITE request for CUG with CUGIndex 
INVITE request for CUG with CUGIndex & outgoingAccessRequest
INVITE request for CUG communication without CUGIndex 
INVITE request for CUG communication without CUGIndex & with outgoingAccessRequest 
INVITE request for Non-CUG communication
CUG without preference
CUG communication (*1) (*3)
IC: spec. CUG
CUG communication (*1) (*3)
IC: spec. CUG
Return 403 (Forbidden) response
Return 403 (Forbidden) response
403 (Forbidden) response
CUG+OAE without preference 
CUG communication (*1) (*3)
IC: spec. CUG
CUG+OA (*2) (*3)
IC: spec. CUG
Return 403 (Forbidden) response
Non-CUG communication
Return 403 (Forbidden) response
CUG+OAI 
without preference 
CUG+OA (*2) (*3)
IC: spec. CUG
CUG+OA (*2) (*3)
IC: spec. CUG
Non-CUG communication
Non-CUG communication
Non-CUG communication
CUG with preference 
CUG communication (*1) (*3)
IC: spec. CUG
CUG communication (*1) (*3)
IC: spec. CUG
CUG (*4) communication
IC: pref. CUG
403 (Forbidden) response
CUG communication
IC: pref. CUG (*4)
CUG+OAE with preference 
CUG communication (*1) (*3)
IC: spec. CUG
CUG+OA (*2) (*3)
IC: spec. CUG
CUG (*4) 
IC: pref. CUG
Non-CUG communication
CUG communication (*4)
pref. CUG
CUG+OAI with preference 
CUG+OA
(*1) (*2) (*3)
IC: spec. CUG
CUG+OA
(*2) (*3) (*1)
IC: spec. CUG
(*4) (*5)
CUG+OA (*1) (*4)
IC: pref. CUG
(*4) (*5)
No CUG
Return 403 (Forbidden) response
Return 403 (Forbidden) response
Return 403 (Forbidden) response
Return 403 (Forbidden) response
Non-CUG communication
OAE	Outgoing access, explicit request required.
OAI	Outgoing access, implicit outgoing access for all communications.
IC	Interlock code of the CUG selected.
spec. CUG 	specific CUG indicated within the CUCIndex
pref. CUG 	preferred CUG indicated by the user profile

NOTE:	As IA (incoming access) attribute of the calling user is of no concern for this validation check, CUG+OA/IA is equivalent to CUG+OA in this table.
(*1)	In case of OCB (outgoing communications barred) return 603 (Decline) response.
(*2)	In case of OCB within the CUG, the communication is interpreted as a non-CUG communication. An INVITE request without a cugInterlockBinaryCode, networkIndicator and cugCommunicationIndicator shall be sent towards the terminating user.
(*3)	In case the specified index does not match any of the registered indices, 403 (Forbidden) response
(*4)	In the case of OCB within the CUG, this combination is not allowed.
(*5)	Both 'Preferential CUG' and 'implicit' outgoing access options imply that no subscriber procedures are needed to invoke either option when placing a communication. When a user subscribes to both options, the network does not know which option the user is invoking, if no additional procedures are used when placing the communication. Then one of the following operations are recommended:
	a)	if no information is given, the preferential CUG will be assumed, this shall be included in the INVITE request sent towards the terminating user.
	b)	the network will route the communication with preferential CUG with outgoing access. The communication will therefore be connected if the terminating access is:
	-	a member of preferential CUG; or
	-	a member of another CUG with incoming access; or
	-	a non-CUG user.

When a vnd.etsi.cug+xml MIME body is included in the outgoing INVITE request the AS shall set the handling parameter in the Content-Disposition for this MIME body to "required" as described in RFC 5621 [7] if outgoing access is not allowed.
4.5.2.5	Void
4.5.2.6	Void
4.5.2.7	Void
4.5.2.8	Void
4.5.2.9	Void
4.5.2.10	Actions at the AS of the terminating user
Table 4.5.2.10.1: Handling of a CUG communication at the AS of the terminating user 


Class of terminating user
CUG cugCommunicationIndicator in INVITE request
CUG match check
CUG
CUG+IA
No CUG


No ICB
ICB
No ICB
ICB

CUG with OA not allowed
Match
CUG call
Sent 603 (Decline) response
CUG call
Sent 603 (Decline) response
Sent 403 (Forbidden) response

No match
Sent 403 (Forbidden) response
Sent 403 (Forbidden) response

CUG with OA allowed
Match
CUG call
Sent 603 (Decline) response
CUG+OA
call
Non-CUG call
Non-CUG call

No match
Sent 403 (Forbidden) response
Non-CUG call

Non-CUG
–
Sent 403 (Forbidden) response
Non-CUG call

IA	Incoming access Non-CUG call
OA	Outgoing access
ICB	Incoming communications barred
Match	The interlock code in the received INVITE request matches one of the CUGs to which the user belongs.
No match	The interlock code does not match any of the CUGs to which the terminating user belongs.
NOTE:	As OA attribute of the terminating user is of no concern at the AS of the terminating User , CUG+OA class is equivalent to CUG, and CUG+IA class is equivalent to CUG+IA in this table. Subscription of preferential CUG by the terminating user is also of no concern in this table.

In case of each successful CUG Check an INVITE request without a CUG xml MIME shall be sent towards the terminating user. Therefore the received CUG xml MIME shall be discarded.
4.5.2.11	Void
4.5.2.12	Actions at the terminating UA
Procedures according to 3GPP TS 24.229 [2] shall apply.
4.6	Interaction with other services
4.6.1	Communication Hold (HOLD)
No impact, i.e. neither service shall affect the operation of the other service.
4.6.2	Terminating Identification Presentation (TIP)
No impact, i.e. neither service shall affect the operation of the other service.
4.6.3	Terminating Identification Restriction (TIR)
No impact, i.e. neither service shall affect the operation of the other service.
4.6.4	Originating Identification Presentation (OIP)
No impact, i.e. neither service shall affect the operation of the other service.
4.6.5	Originating Identification Restriction (OIR)
No impact, i.e. neither service shall affect the operation of the other service.
4.6.6	Conference calling (CONF)
When the communication involving the first conferee is added to the conference, then the conference shall assume the CUG of that communication. 
In order to add a subsequent communication to the conference, then the CUG of that communication shall be checked against the CUG of the conference.
4.6.7	Communication Diversion Services (CDIV)
4.6.7.1	Communication Forwarding Unconditional (CFU)
CUG restrictions shall be checked and met for the communication between the originating party and the forwarding party. The information of a CUG applied by the IMS on the original communication shall be used for the communication forwarding and by this means CUG restrictions shall be checked and met for the communication between the originating party and the forwarded-to party. 
In the case of multiple forwarding, CUG restrictions between the originating party and the forwarding party have to be checked and met at each intermediate forwarding point. In addition, CUG restrictions between the originating party and forwarded-to party shall be met end-to-end.
The outgoing communication barring information of the forwarding party shall not be used to determine whether the communication can be forwarded.
The CUG information sent to the "forwarded-to" destination shall the same CUG information of the originating party that was sent from the originating network.
4.6.7.2	Communication Forwarding Busy (CFB)
See interactions with CFU in subclause 4.6.7.1.
4.6.7.3	Call Forwarding No Reply (CFNR)
See interactions with CFU in subclause 4.6.7.1.
NOTE:	CUG restrictions were checked and met for the communication between the originating party and the forwarding party when the communication was offered to the forwarding party.
4.6.7.4	Communication Forwarding on Not Logged-in (CFNL)
See interactions with CFU in subclause 4.6.7.1.
4.6.7.5	Communication Forwarding on Subscriber Not Reachable (CFNRc).
See interactions with CFU in subclause 4.6.7.1.
4.6.7.6	Communication Deflection (CD)
The information of a CUG applied by the IMS on the original communication shall be used for the deflected part of the communication and by this means CUG restrictions shall be checked and met for the communication between the originating party and the deflected-to party. 
In the case of multiple deflections, CUG restrictions between the originating party and the deflecting party have to be checked and met at each intermediate deflecting point. In addition, CUG restrictions between the originating party and deflected-to party shall be met end-to-end. 
When a communication is deflected, a new check of the CUG restrictions between the originating party and the deflected-to party is made at the "deflected-to" destination. The CUG information sent to the 'deflected-to' destination is the same CUG information of the originating party that was sent from the originating network.
The outgoing communication barring information of the deflecting party shall not be used to determine whether the communication can be deflected.
NOTE:	CUG restrictions were checked and met for the communication between the originating party and the deflecting party when the communication was offered to the deflecting party.
4.6.8	Malicious Communication Identification (MCID)
No impact, i.e. neither service shall affect the operation of the other service.
4.6.9	Anonymous Communication Rejection and Communication Barring (ACR/CB)
No impact, i.e. neither service shall affect the operation of the other service.
4.6.10	Explicit Communication Transfer (ECT)
The two communications shall use the same CUG for the transfer to be successful.
NOTE:	CUG restrictions between users will have been checked when the first communication is established. Similarly, CUG restrictions between users will have been checked when establishing the second communication.
4.6.11	Closed User Group (CUG)
No impact, i.e. neither service shall affect the operation of the other service.
4.6.12	Three-Party (3PTY)
For the successful invocation of the three party service any CUG restrictions applied to one communication shall match with any CUG restrictions applied to the other communication.
4.7	Interactions with other networks
4.7.1	Void
4.7.2	Void
4.7.3	Void
Annex A (informative):
Void

Annex B (informative):
Change history

Change history
DateTSG #TSG Doc.CRRevSubject/CommentOldNew2007-11Publication as ETSI TS 183 0542.1.02007-12Conversion to 3GPP TS 24.4542.1.12007-12Technically identical copy as 3GPP TS 24.654 as basis for further development2.1.22008-02Implemented C1-0800942.2.02008-04Implemented C1-080812,C1-080896, C1-081100, C1-081101
And alignment with 3GPP Skeleton2.3.02008-05Implemented C1-81562, C1-81837, C1-81919
Editorial: Change of Keywords, Change of title
Incorporation of comments from ETSI Edit help2.4.02008-05CT#40CP-080336Editorial changes done by MCC2.4.02.4.12008-06CT#40CP-080336CP-080336 was approved by CT#40 and version 8.0.0 is created by MCC for publishing2.4.18.0.02008-06Version 8.0.1 created to include attachments (.xml and .xsd files)8.0.08.0.12008-09CT#41CP-08053300011Alignment of user configuration8.0.18.1.02008-09CT#41CP-08053900021Allow SIP based user configuration mechanism for configuring supplementary services8.0.18.1.02008-09CT#41CP-0805330003Applicability statement in scope8.0.18.1.02008-12CT#42CP-0808650004Removal of unused reference in TS 24.6548.1.08.2.02008-12CT#42CP-08086400052Interaction between SIP and Ut based service configuration8.1.08.2.02008-12CT#42Editorial cleanup by MCC8.1.08.2.02009-12CT#46Upgrade to Rel-98.2.09.0.02010-03CT#47CP-1001140007Clarification of the use of Content-Disposition in CUG.9.0.09.1.02012-03CT#55CP-12009700131Incorrect XSD for CUG 9.1.09.2.02012-06CT#56CP-12029100162Wrong xml NetworkIndicator element9.2.09.3.02013-03CT#59CP-13009500262Corection of CUG description due to mandatory CUG Index9.3.09.4.0








 STYLEREF ZA 3GPP TS 24.654 V9.4.0 (2013-03)
 PAGE 17
 STYLEREF ZGSM Release 9


3GPP