4 Closed User Group (CUG)

24.6543GPPClosed User Group (CUG) using IP Multimedia (IM) Core Network (CN) subsystem, Protocol SpecificationRelease 16TS

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 version="1.0" encoding="UTF-8"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:ss="http://uri.etsi.org/ngn/params/xml/simservs/xcap" targetNamespace="http://uri.etsi.org/ngn/params/xml/simservs/xcap" elementFormDefault="qualified" attributeFormDefault="unqualified">

<xs:annotation>

<xs:documentation>XML Schema Definition for the closed user group parameter</xs:documentation>

</xs:annotation>

<xs:include schemaLocation="xcap.xsd"/>

<!–Definition of simple types–>

<xs:simpleType name="twobitType">

<xs:restriction base="xs:string">

<xs:pattern value="[0-1][0-1]"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="networkIdentityType">

<xs:restriction base="xs:hexBinary">

<xs:length value="2"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="sixteenbitType">

<xs:restriction base="xs:hexBinary">

<xs:length value="2"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="cugIndexType">

<xs:restriction base="xs:integer">

<xs:minInclusive value="0"/>

<xs:maxInclusive value="32767"/>

</xs:restriction>

</xs:simpleType>

<!–Definition of complex types–>

<xs:complexType name="cugRequestType">

<xs:sequence>

<xs:element name="outgoingAccessRequest" type="xs:boolean"/>

<xs:element name="cugIndex" type="cugIndexType" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

<!–Definition of document structure–>

<xs:element name="cug" substitutionGroup="ss:absService">

<xs:complexType>

<xs:complexContent>

<xs:extension base="ss:simservType">

<xs:sequence>

<xs:element name="cugCallOperation" type="cugRequestType" minOccurs="0"/>

<xs:element name="networkIndicator" type="networkIdentityType"
minOccurs="0"/>

<xs:element name="cugInterlockBinaryCode" type="sixteenbitType"
minOccurs="0"/>

<xs:element name="cugCommunicationIndicator" type="twobitType"
minOccurs="0"/>

</xs:sequence>

</xs:extension>

</xs:complexContent>

</xs:complexType>

</xs:element>

</xs:schema>

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 including a Reason header field and a cause code as specified in table 4.5.2.4.1 shall be sent back.

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 including Reason header field set to "Q.850" and cause code set to "62"

Return 403 (Forbidden) response including Reason header field set to "Q.850" and cause code set to "62"

403 (Forbidden) response including Reason header field set to "Q.850" and cause code set to "62"

CUGOAE without preference

CUG communication (*1) (*3)
IC: spec. CUG

CUGOA (*2) (*3)
IC: spec. CUG

Return 403 (Forbidden) response including Reason header field set to "Q.850" and cause code set to "62"

Non-CUG communication

Return 403 (Forbidden) response including Reason header field set to "Q.850" and cause code set to "62"

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 including Reason header field set to "Q.850" and cause code set to "62"

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 including Reason header field set to "Q.850" and cause code set to "50"

Return 403 (Forbidden) response including Reason header field set to "Q.850" and cause code set to "50"

Return 403 (Forbidden) response including Reason header field set to "Q.850" and cause code set to "50"

Return 403 (Forbidden) response including Reason header field set to "Q.850" and cause code set to "50"

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 including Reason header field set to "Q.850" , and cause code set to "55"

CUG call

Sent 603 (Decline) response including Reason header field set to "Q.850" , and cause code set to "55"

Sent 403 (Forbidden) response including Reason header field set to "Q.850" , and cause code set to "87"

No match

Send 403 (Forbidden) response including Reason header field set to "Q.850" , and cause code set to "87"

Sent 403 (Forbidden) response including Reason header field set to "Q.850" , and cause code set to "87"

CUG with OA allowed

Match

CUG call

Sent 603 (Decline) response including Reason header field set to "Q.850" , and cause code set to "55"

CUG+OA
call

Non-CUG call

Non-CUG call

No match

Sent 403 (Forbidden) response including Reason header field set to "Q.850" , and cause code set to "87"

Non-CUG call

Non-CUG

Sent 403 (Forbidden) response including Reason header field set to "Q.850" , and cause code set to "87"

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.6.13 Enhanced Calling Name (eCNAM)

No impact, i.e. neither service shall affect the operation of the other service.

4.6.14 Multi-Device (MuD)

No impact. Neither service shall affect the operation of the other service.

4.6.15 Multi-Identity (MiD)

In addition to the CUG restrictions for called and calling users, the CUG service restrictions apply to originating calls such that identity C as defined in 3GPP TS 24.174 [8] cannot be used if CUG restricts calling identity C. The CUG restrictions shall also apply at identity C both for the calls from identity A, defined in 3GPP TS 24.174 [8] and for the outgoing calls.

For incoming calls at identity D, defined in 3GPP TS 24.174 [8] that are forwarded according to procedures in 3GPP TS 24.174 [8], the same restrictions as for CDIV apply, see subclause 4.6.7.1.

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

Date

TSG #

TSG Doc.

CR

Rev

Subject/Comment

Old

New

2007-11

Publication as ETSI TS 183 054

2.1.0

2007-12

Conversion to 3GPP TS 24.454

2.1.1

2007-12

Technically identical copy as 3GPP TS 24.654 as basis for further development

2.1.2

2008-02

Implemented C1-080094

2.2.0

2008-04

Implemented C1-080812,C1-080896, C1-081100, C1-081101

And alignment with 3GPP Skeleton

2.3.0

2008-05

Implemented C1-81562, C1-81837, C1-81919

Editorial: Change of Keywords, Change of title

Incorporation of comments from ETSI Edit help

2.4.0

2008-05

CT#40

CP-080336

Editorial changes done by MCC

2.4.0

2.4.1

2008-06

CT#40

CP-080336

CP-080336 was approved by CT#40 and version 8.0.0 is created by MCC for publishing

2.4.1

8.0.0

2008-06

Version 8.0.1 created to include attachments (.xml and .xsd files)

8.0.0

8.0.1

2008-09

CT#41

CP-080533

0001

1

Alignment of user configuration

8.0.1

8.1.0

2008-09

CT#41

CP-080539

0002

1

Allow SIP based user configuration mechanism for configuring supplementary services

8.0.1

8.1.0

2008-09

CT#41

CP-080533

0003

Applicability statement in scope

8.0.1

8.1.0

2008-12

CT#42

CP-080865

0004

Removal of unused reference in TS 24.654

8.1.0

8.2.0

2008-12

CT#42

CP-080864

0005

2

Interaction between SIP and Ut based service configuration

8.1.0

8.2.0

2008-12

CT#42

Editorial cleanup by MCC

8.1.0

8.2.0

2009-12

CT#46

Upgrade to Rel-9

8.2.0

9.0.0

2010-03

CT#47

CP-100114

0007

Clarification of the use of Content-Disposition in CUG.

9.0.0

9.1.0

2011-03

CT#51

Upgrade to Rel-10

9.1.0

10.0.0

2012-03

CT#55

CP-120097

0014

1

Incorrect XSD for CUG

10.0.0

10.1.0

2012-06

CT#56

CP-120291

0017

2

Wrong xml NetworkIndicator element

10.1.0

10.2.0

2012-06

CT#56

CP-120307

0020

1

CUG failure code specification

10.2.0

11.0.0

2013-03

CT#59

CP-130095

0028

2

Corection of CUG description due to mandatory CUG Index

11.0.0

11.1.0

2014-09

CT#65

Upgrade to Rel-12

11.1.0

12.0.0

2015-12

CT#70

Upgrade to Rel-13

12.0.0

13.0.0

Change history

Date

Meeting

TDoc

CR

Rev

Cat

Subject/Comment

New version

2017-03

SA#75

Upgrade to Rel-14

14.0.0

2017-12

CT-78

CP-173071

0029

2

B

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

15.0.0

2019-12

CT-86

CP-193111

0030

1

B

Adding interactions with "Multi-Device" and "Multi-Identity" services

16.0.0