The CCNL service enables the originating party, encountering a terminating party who is not registered, to have the communication completed without having to make a new communication attempt when the terminating party registers again.
When the originating party requests the CCNL service, the network will monitor for the terminating party registering again.
As a service provider option only originating parties who are listed in the terminating party's whitelist are allowed to request the CCNL service.
When the terminating party registers again, then the network will wait a short time in order to allow the terminating party to originate a communication. If no communication is originated by the terminating party within this time, then the network will automatically recall the originating party. As a service provider option the terminating user's acceptance of the CCNL request shall be required before the originating party will be recalled. When the originating party accepts the CCNL recall, then the network will automatically generate a CCNL call to the terminating party.
When the terminating party is busy or not logged-in upon arrival of the CCNL call, the original CCNL request shall retain its position in the queue, and the remaining period in which the CCNL request remains valid shall not be changed by this event.
During CCNL recall, information shall be provided which indicates a CCNL recall. The information provided in the original communication attempt shall be included in the CCNL recall.
CCNL requests in the CCNL queue of the terminating party shall only be processed if there are no communications waiting. In other situations there is no impact between the CW and the CCNL service.
The following Completion of Communications services are defined: Completion of Communications to Busy Subscriber (CCBS), Completion of Communications on No Reply (CCNR) and Completion of Communications on Not Logged-in (CCNL)
A user can be both an originating party and a terminating party simultaneously, i.e. that user can have activated CC services and have CC requests outstanding whilst at the same time that user can be the destination of CC requests from other users.
CC requests against the same terminating party shall be queued in the same queue.
If a user receives a CCNL recall (i.e. as originating party) while that user's queue as terminating party is being processed, then the CCNL recall shall take priority over the handling of that user's queue. The handling of CCNL requests activated by this user (i.e. as originating party) shall have priority over the handling of CC requests activated by other users on this user (i.e. as terminating party).
If one of the user's CCNL requests can be processed, then this user shall be given a CCNL recall or a notification. The served user's terminating party idle guard timer, if running, shall be cancelled. The processing of CCBS or CCNR requests shall be according to the requirements of the CCBS or CCNR supplementary services.
If the network checks for identical requests in the user's queue, the check shall include CCNL, CCNR and CCBS requests.
If an originating party has a CCBS or CCNR recall pending on arrival of a CCNL recall, this should be treated in the same way as in the case where the originating party is CCNL busy. In this case, the CCNL request shall be suspended until user A becomes neither busy nor CCNL busy.
For CFU activated by user B before user A requests CCNL:
If user B has activated CFU, and the forwarded communication results in a communication completion on not logged-in condition at user C, user A shall be informed that CCNL is possible at user C. If user A activates CCNL and subsequently activates CFU, the CCNL recall shall be given to user A.
As a network option, in case of a diversion at user B, user A shall not be informed that CCNL is possible.
For CFU activated by user B after user A requests CCNL on user B:
If user B activates CFU after user A has activated CCNL on user B, then the CCNL request shall be cancelled and a notification "CCNL cancelled" shall be sent to the user A.
As a network option, the CCNL request shall be suspended until user B deactivates CFU. If the service duration timer e2Apires before user B deactivates CFU, the CCNL request shall be cancelled.
For CFB activated by user B before user A requests CCNL:
If user B has activated the communication forwarding busy service and is busy, and the forwarded communication results in a call-completion on not logged-in condition at user C, user A shall be informed that CCNL is possible at user C.
As a network option, in case of a diversion at user B, user A shall not be informed that CCNL is possible.
For CFB activated by user B after user A requests CCNL on user B:
If user B activates the communication forwarding busy service after user A has activated the CCNL service on user B, the communication forwarding busy service shall not be invoked for the CCNL communication.
For CFNR activated by user B before user A requests CCNL:
If user B has activated the communication forwarding on no reply service and does not answer the communication, and the forwarded communication results in a communication-completion on not logged-incondition at user C, user A shall be informed that CCNL is possible at user C.
As a network option, in case of a diversion at user B, user A shall not be informed that CCNL is possible.
For CFNR activated by user B after user A requests CCNL on user B:
If user B activates the communication forwarding on no reply service after user A has activated CCNL on user B, then the CCNL request shall be cancelled and a notification "CCNL cancelled" shall be sent to the user A.
As a network option, the CCNL request shall be suspended until user B deactivates CFNR. If the service duration timer e2Apires before user B deactivates CFNR, the CCNL request shall be cancelled.
For CFNL activated by user B before user A requests CCNL:
If user B has activated the communication forwarding not registered service and is not logged in, and the forwarded communication results in a communication completion on not logged-in condition at user C, user A shall be informed that CCNL is possible at user C.
As a network option, user A shall be informed that CCNL at user B is possible.
For CFNL activated by user B after user A requests CCNL on user B:
If user B activates the communication forwarding not registered service after user A has activated the communication forwarding on not logged-in service on user B, a CCNL communication from user A which encounters a not logged in condition at user B shall be treated as follows:
the procedures of CCNL shall be applied; or
the communication shall be forwarded as a normal communication.
If a communication to the called user B is deflected to user C by the CD service and results in a communication completion on not logged-in condition at user C, user A shall be informed that CCNL is possible at user C. A CCNL recall shall not be deflected.
Provision, Withdrawal, Registration, Erasure, Activation, Deactivation and Invocation shall be as defined in ITU-T Recommendation I.210 [5].
Users shall be able to register, activate, deactivate, withdraw, interrogate and reconfigure IMS supplementary services via the UE, or web portals.
The Multimedia Telephony Service shall provide a consistent service experience to the user for mobile initiated USSD operations in MMI mode and reserved for HPLMN use, according to TS 22.090.
The Multimedia Telephony Service shall be able to play network announcements or tones to the subscriber at any time during a session.
If there is an appropriate bilateral agreement, the home network shall be able to instruct the visited network to play a network announcement or tone to the subscriber at any time during a session.
When the UE locally renders the supervisory tones, the UE should follow the procedure indicated in Annex A.2 applicable for the home operator network of the UE in particular within a mobile network. The UE shall not locally render tones to indicate diversion or queueing of calls.
Some IMS supplementary services (e.g. communication session barring) can be offered to a user with the subscription option of authorization to control the service. When this option is selected, every action (related to that IMS supplementary service), such as registration, erasure, activation or deactivation is performed by the user with concurrent authentication.
For IMS supplementary services requiring authorization by user authentication, the service experience for the user shall be consistent with the procedures defined in TS 22.030 for password based supplementary service management.
Each IMS supplementary service which requires authorization to control this service may be offered with the subscription option authorized control of the IMS supplementary service. The values of this option may be:
The IMS Multimedia Telephony with Enhanced Voice should fulfill the following requirements:.
IMS Multimedia Telephony with Enhanced Voice should allow for significantly improved quality of user experience compared to IMS Multimedia Telephony with pre-Rel-12 voice services.
It should be possible to achieve significantly better service quality than is possible with both Rel-11 3GPP narrowband and wideband voice services.
IMS Multimedia Telephony with Enhanced Voice should be deployable in an efficient manner.
IMS Multimedia Telephony with Enhanced Voice should efficiently use the transmission resource access and transport networks. It should also allow possibility to implement the new services on low-cost devices and network equipment with limited computational resource. With regard to transmission efficiency, it should exceed that of the pre-Rel-12 3GPP wideband voice service.
Transcoding should be avoided as much as possible. If transcoding cannot be avoided, voice conversational quality degradation should be as limited as possible.
The best possible quality should be delivered to all participants in conference calls.