TS 22.183
CRS —
Customized Ringing Signal –
Stage 1

3GPP‑Page ETSI‑search CONTENT_↓

V18.0.1 (PDF) 2024/03 16 p.

V17.0.0 2022/03 16 p.

V16.0.0 2020/06 16 p.

V15.0.0 2018/06 15 p.

V14.0.0 2017/03 16 p.

V13.0.0 2014/09 16 p.

V12.0.0 2014/10 16 p.

V11.0.0 2012/09 16 p.

V10.0.0 2011/04 16 p.

V9.1.0 2009/12 16 p.

Rapporteur:: Dr. Song, Jin han
SK Telecom

Content for TS 22.183 Word version: 18.0.1

4.1 Basic functionality of CRS service 4.2 Normal procedures with successful outcome 4.3 CRS service configuration 4.4 The content of CRS 4.5 Inter-working CRS

1 Scope p. 5

The document specifies the requirements and technical considerations for Customized Ringing Signal (CRS) service in the PS and CS domains, especially additional features for roaming and interoperability support.

This document considers voice and multi-media CRS, so the CRS user may experience favourable songs, multi-media clips or other customized CRS.

This document specifies the CRS filtering service requirements that allow the user to filter the CRS.

2 References p. 5

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]

TR 21.905: "Vocabulary for 3GPP Specifications".

[2]

TS 22.173: "IP Multimedia Core Network Subsystem (IMS) Multimedia Telephony Service and supplementary services; Stage 1".

[3]

TS 22.240: "Service requirements for 3GPP Generic User Profile (GUP); Stage 1".

[4]

ETSI TISPAN TR 181 015: "Requirements for Customized Originating and Terminating Multimedia Information Presentation (COMIP/CTMIP) and Customized Originating and Terminating Multimedia Information Filtering (COMIF/CTMIF) Requirements Analysis".

3 Definitions, symbols and abbreviations p. 5

3.1 Definitions p. 5

For the purposes of the present document, the terms and definitions given in TR 21.905 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905.

Ringing Signal:

A Ringing Signal is played to the called party as an incoming communication indication during establishment of a communication. It is provided by the UE of the called party.

Customized Ringing Signal:

A Ringing Signal that is customized by the calling party or the called party, and it can contain additional media types. It is provided by the network.

CRS inter-action:

CRS inter-action is the interaction of the CRS service with other services, e.g. inter-action with Call Forwarding.

CRS inter-working:

CRS inter-working is the interworking of a CRS service over different domains or subsystems (CS or IMS) as well as between PLMNs.

CRS content provider:

A service provider that provides a set of Ring Signals for use as CRS for subscribes of the CRS service. A 3GPP operator may be a CRS content provider.

3.2 Abbreviations p. 6

For the purposes of the present document, the abbreviations given in TR 21.905 and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905.

CRS

Customized Ringing Signal

4 CRS Service Requirements p. 6

4.1 Basic functionality of CRS service p. 6

The Customized Ringing Signal service (CRS service) is an operator specific service by which an operator enables the subscriber to customize the ringing signal which is played to the called party. The CRS content will be provided to the called party only it's allowed by the called party. The called party does not need to be a CRS subscriber to experience the CRS set by calling subscriber.

The service shall support the CRS content types of audio, video, image, graphic, text, location, and electronic business card.
CRS can contain one or several content types, and at most one element of each type.
The called party should be able to simultaneously experience multiple CRS contents, e.g. audio and video.
The service user shall be able to subscribe to the services, activate the services, update the settings, e.g. to change his active CRS.
The CRS service shall override the default ringing signal towards the called party provided that media components are compatible.
The called party shall be able to experience the CRS set by the called service subscriber.
The called party shall be able to experience the CRS set by the calling service subscriber.
The operator should have the capability to store multiple CRSs per service subscriber.
It should be possible to inform the user about status and changes in his service, e.g. service expiry date or a particular CRS content.

NOTE:
In the CS domain, this information may be provided by existing means such as SMS and web access.
The operator shall be able to charge for the CRS service and the related contents on event, volume or media type basis.
It shall be possible for a subscriber to subscribe to CRS that is provided by a third party content provider.
CRS service should not negatively affect the conversation between calling and called parties, e.g. no voice /video clipping.
If the CRS can't be played for some reason (for example, the CRS system fails, or the CRS content expiry is up, or the called user roams from 3G network to 2G network, or other reasons), the called party shall experience the default ringing signal instead of the CRS.
When the multi-media CRS fails to be played in some condition (such as the caller roams from 3G network to 2G network or network congestion occurs), the voice CRS may be played instead if possible.
The operator shall be able to verify that the party is authorised to store and update CRS content.
The operator shall allow the calling party to select from the pre-stored CRS content according to the called party on a per call basis.
As service option, if a specific text (object of the communication) is provided by the calling party, this information should replace any potential text information pre-stored in the network.

4.1.1 Functionality - IMS domain p. 7

The CRS services in IMS domain are defined by:

For the CRS service, the called party's operator shall be able to configure which CRS should have priority, the one set by the called or calling CRS service subscriber. The called party's operator shall be able to take into account the called CRS service subscriber's preferences. By default, if no preference is set, the CRS set by the called party has priority.
When the called party answers the communication the CRS shall stop or continue to play during the conversation, depending on operator or user preferences. By default, if no preference is set, when the called party answers the communication the CRS shall stop.
When the calling party is setting up a communication, the calling party shall be able to send an indication to the CRS service which CRS to play to the called party.
The called party shall have the capability to copy the CRS of the calling party as his own CRS while the CRS is being played.The pre-requisites are that the calling party has enabled CRS sharing, if applicable, for that instance of CRS and that both parties are subscribers to the same HPLMN.

NOTE 1:
A CRS might also be copied offline via e.g. web interface but that functionality does not require standardisation.

NOTE 2:
The expression "to copy the CRS" does not necessarily mean that the CRS is actually copied. It may also mean that a purchase request is being sent to the CRS service provider.
The CRS service shall be able to send CRS to the called party on per call basis.
The CRS service shall send an indication to the multimedia information presentation service which multimedia information to play to the called party (e.g. when the called party is notified about an incoming communication, the CRS subscriber can send an indication to the CRS service which CRS to play to the called party).
The CRS subscriber may be able to replace one CRS with another one while it is playing.
The CRS subscriber may be able to receive CRS service after communication establishment.

4.1.2 Functionality - CS domain p. 7

The CRS services in CS domain are defined by:

For the CRS service, the called party's operator shall be able to configure which CRS should have priority, the one set by the called or calling CRS service subscriber. By default, if no preference is set, the CRS set by the called party has priority.
When the called party answers the communication the CRS shall stop.
The called party shall have the capability to copy the CRS of the calling party as his own CRS. The pre-requisites are that the calling user has enabled CRS sharing, if applicable, for that instance of CRS and that both parties are subscribers to the same HPLMN and the called party is within the HPLMN.

NOTE 1:
A CRS might also be copied offline via e.g. web interface but that functionality does not require standardisation.

NOTE 2:
The expression "to copy the CRS" does not necessarily mean that the CRS is actually copied. It may also mean that a purchase request is being sent to the CRS service provider.
During the call setup over the CS domain, the called party UE shall be able to start automatically downloading and streaming CRS content through PS domain. Downloaded CRS content shall not be used for other purposes except CRS service.

4.2 Normal procedures with successful outcome p. 8

4.2.1 Provisioning and Withdrawal p. 8

The CRS Service can be provisioned and withdrawn by the operator on a per subscriber basis.

If the CRS service is not provisioned, the called party shall not experience content of CRS, he should experience the default ringing signal.

4.2.2 Activation and Deactivation and Update p. 8

4.2.2.1 Activation p. 8

When a subscriber activates his CRS Service he shall be able to specify which CRS a called user should experience, or use the operator's default setting.

After a subscriber has activated his CRS Service a called user should experience the CRS that was chosen by the subscriber.

4.2.2.2 Deactivation p. 8

After a subscriber has deactivated his CRS Service a called user shall experience the default ringing signal.

4.2.2.3 Update p. 8

When a subscriber updates his CRS Service, updated CRS should overwrite the existing one.

4.2.3 Basic scenarios p. 8

4.2.3.1 Only calling party has activated the CRS service p. 8

In the following scenarios, contained in Table 1, it is assumed that only the calling party (A) has activated his CRS Service. Calling party (A) is calling B. The called party has subscribed and not activated the CRS service.

The CRS of A is CRS-A.

Table 1: Normal Operation Scenarios

	Called party B (condition)	Required behaviour
1	B, ringing	Depending on B settings, B will experience either CRS-A or the default ringing signal.

4.2.3.2 Only called party has activated the CRS service p. 8

In the following scenario, contained in Table 2, it is assumed that only the called party (B) has activated his CRS Service. Calling party (A) is calling B. The calling party has not subscribed and/or activated the CRS service.

The CRS of B is CRS-B.

Table 2: Normal Operation Scenarios

	Called party B (condition)	Required behaviour
1	B, ringing	B experiences CRS-B or the default ringing signal.

4.2.3.3 Both parties have activated the CRS service p. 9

In the following scenarios, contained in Table 3, it is assumed that both the calling party (A) and called party (B) have activated the CRS Service. Calling party (A) is calling B.

The CRS of B is CRS-B, the CRS for A is CRS-A.

Table 3: Normal Operation Scenarios

	Called party B (condition)	Required behaviour
1	B, ringing	Depending on B settings, B experiences CRS-A, CRS-B or the default ringing signal. If B has not set preference, B experiences CRS-B.

4.2.4 Interaction with Supplementary Services p. 9

4.2.4.1 Originating Identification Presentation (OIP) p. 9

No impact. The OIP service is performed independently of the CRS, the CRS will use the information provided by OIP.

The CRS service shall be able to distinguish information provided via service platform and information provided by the network (e.g. public identity sends by the OIP service).

4.2.4.2 Originating Identification Restriction (OIR) p. 9

The OIR service takes precedence over the CRS service subscribed by the calling party or by the called party.

4.2.4.3 Communication Diversion (CDIV) p. 9

Table 4 describes when the forwarded-to party (C) has not subscribed or activated the CRS service.

Table 4: Supplementary Service Interaction Scenarios

	Called party B (condition)	Forwarded-to-party (condition)	Required behaviour
1	B has activated Call Forwarding Unconditional (CFU) to C and A's call is forwarded to C	C, ringing	C experiences CRS-A or CRS-B or the default ringing signal.
2	B has activated Call Forwarding on Busy (CFB) to C, B is busy and A's call is forwarded to C	C, ringing	C experiences CRS-A or CRS-B or the default ringing signal.
3	B has activated Call Forwarding on No Reply (CFNRy) to C and A's call is forwarded to C	C, ringing	C experiences CRS-A or CRS-B or the default ringing signal.
4	B has activated Call Forwarding on Not Reachable (CFNRc) to C and A's call is forwarded to C	C, ringing	C experiences CRS-A or CRS-B or the default ringing signal.

Table 5 describes when the forwarded-to-party (C) has subscribed and activated the CRS service.

The CRS of C is CRS-C.

Table 5: Supplementary Service Interaction Scenarios

	Called party B (condition)	Forwarded-to-party (condition)	Required behaviour
1	B has activated Call Forwarding Unconditional (CFU), Call Forwarding on Busy (CFB) or Call Forwarding on Not Reachable (CFNRc) to C. A's call is forwarded to C	C, ringing	Depending on operator settings, subscriber C will experience the CRS-C or CRS-A or CRS-B or the default ringing signal.
2	B has activated Call Forwarding on No Reply (CFNRy) to C and A's call is forwarded to C	C, ringing	B experiences the standard ringing signal until B's CFNRy timer has expired. Then C experiences CRS-C or CRS-A or CRS-B or the default ringing signal.

4.2.4.4 Communication Waiting (CW) p. 10

If the called party B has activated the communication waiting service and he is busy, depending on the operator's settings, the called party will experience either the CRS service or the default communication waiting indication.

If B experiences the CRS service, B shall receive appropriate media in order to limit perturbation on the ongoing communication with C (e.g. CRS audio information may be replaced by the default communication waiting tone).

Table 6 describes the situation that only the calling party A has subscribed and activated the CRS service.

Table 6: Supplementary Service Interaction Scenarios

	Called party B (condition)	Required behaviour
1	B has activated Communication Waiting,	Depending on operator settings or user preference, B experiences the communication waiting indication or CRS-A whose audio information is replaced by the communication waiting indication.

Table 7 describes the situation that only the called party B has subscribed and activated the CRS service.

Table 7: Supplementary Service Interaction Scenarios

	Called party B (condition)	Required behaviour
1	B has activated Communication Waiting,	Depending on operator settings or user preference, B experiences the communication waiting indication or CRS-B whose audio information is replaced by the communication waiting indication.

Table 8 describes the situation that both the calling party A and called party B have subscribed and activated the CRS service.

Table 8: Supplementary Service Interaction Scenarios

	Called party B (condition)	Required behaviour
1	B has activated Communication Waiting,	Depending on operator settings or user preference, B experiences the communication waiting indication or CRS-A/CRS-B whose audio information is replaced by the communication waiting indication.

4.2.4.5 Explicit Communication Transfer (ECT) p. 11

In case of immediate transfer the called party C shall either experience the CRS from CRS-A or CRS-C depending on operator settings and if A or C has activated the CRS service.

In case of consultative transfer, when A is on hold and B has invoked the ECT service between A and C, C shall either experience the CRS from CRS-B or CRS-C depending on operator settings and if B or C has activated the CRS service. When the communication is established between A and C, C shall either experience the CRS from CRS-A or CRS-C depending on operator settings and if A or C has activated the CRS service.

4.3 CRS service configuration p. 12

The CRS subscriber should be able to configure the service with a service profile based on the following parameters:

CRS content descriptor - Pointing to the right content or combination of contents (e.g. personal prompt plus chosen music/video track)
CRS timing descriptor - Time of day, day of week, specific date and intervals based on each of those parameters.
User (called/calling party) descriptor - user ID (or group ID of users), user presence, user location, CRS user charging mode

The CRS service shall be able to select the appropriate CRS according to the CRS user profile.

A CRS subscriber who has activated his service, shall be able to select and update his settings - e.g. select a different CRS than the current one. It should be possible to charge the subscriber for selection / update of the CRS settings.

A storage mechanism for a user Profile relevant to CRS and/or CRS filtering should be supported.

A user/subscriber and/or CRS service provider should be able to access/manage CRS and/or a CRS filtering User Profile.

A means of managing Access rights for User Profile components and media content should be supported.

The network should provide the capability for the called/forwarded party to reject CRS provided by the calling party according to some rules:

reject all CRS, unconditionally.
reject CRS for unknown parties and accept all known parties,
reject CRS for parties identified as with malicious information in a black list and accept all others,
prompt the user to accept/reject CRS only for unknown parties and accept CRS all others (default)
For IMS CRS, it should be possible to prompt the user to accept or reject CRS for each incoming call (e.g. to present CRS or not).

4.4 The content of CRS p. 12

The content of CRS can be CRS such as music, voice, text, or video.

The CRS may be composed of music, voice, text, video, which can be provided by the CRS content provider, operator or by the user himself.

The content of the CRS service may be dynamically created, possibly taking into account information available in the network, e.g. calling and/or called user's location and/or presence information.

The dynamic content of CRS service may be stored in the network in order to be experienced again by the called party. This may be requested by the called party, calling party, or service provider. The content may be downloaded to the UE or streamed down to the UE when the CRS is playing.

4.5 Inter-working CRS p. 12

4.5.1 Inter-working between PLMNs p. 12

The CRS service should therefore fulfil the following end user requirements:

When receiving a communication from another PLMN, the called party shall be able to experience the CRS set by the calling party.
When receiving a communication from another PLMN, the called party shall be able to experience the CRS set by the called party.
When roaming to another PLMN, the called party shall be able to experience the CRS set by the called party.
When roaming to another PLMN, the called party shall be able to experience the CRS set by the calling party.
The called party shall be able to experience the CRS set by the calling party who is roaming to another PLMN.

4.5.2 Inter-working between CS and IMS p. 13

The CS and IMS based CRS services should fulfil the following end user requirements:

When receiving a communication from another domain (CS or IMS), the called party shall be able to experience the CRS set by the calling party.
When receiving a communication from another domain (CS or IMS), the called party shall be able to experience the CRS set by the called party.
When receiving a communication from another domain (CS or IMS), the called party should be able to copy the CRS of the calling user as his own CRS. The pre-requisites are that the calling user has enabled CRS sharing, if applicable, for that instance of CRS and that both users are subscribers to the same HPLMN.

The scope of this interoperability may result in a limited service capability.