This Technical Report describes an IMS capable HNB SubSystem (the HNB and the HNB Gateway) as an optional capability of HNB that allows e.g. an operator to offload CS traffic to the IMS. The HNB and HNB Gateway are described in TR 23.830, and the capabilities of these network elements are assumed by this TR. To achieve this and to satisfy the related requirements and use cases captured in TS 22.220, the objective is to investigate the following:

• an architecture to enable IMS capable HNB Subsystem to use the IMS for CS terminals using a corresponding equivalent IMS services (voice service in IMS Multimedia Telephony);
• the impacts of the IMS capable HNB Subsystem to idle mode mobility for all supported UE types (e.g. IMS registration/de-registration);
• service continuity at least in the direction from IMS capable HNB Subsystem to macro network;
• support for pre-Rel 9 CS and IMS UEs when using IMS capable HNB Subsystem.

The TR will analyze solutions for the related architectural issues and capture the conclusions.

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.

The architecture shall permit the following service scenarios to be supported:

• UE using CS procedures for voice originates a voice session through 3G HNB and the IMS Core network.
• UE using CS procedures for voice terminates a voice session through the IMS Core network and 3G HNB.
• UE performs idle mode mobility between 3G HNB and CS macro network.
• Service Continuity performed from HNB to CS macro network of a UE which uses CS procedures for voice.
• IMS supplementary services executed, see TS 22.173, for UE which uses CS procedures (TS 24.008) for voice.
• UE which uses CS procedures for voice originates emergency call through 3G HNB and, based upon operator policy, either the CS Core network or IMS Core network.
• CS services executed which do not have an equivalent in IMS, e.g. CS-Data/Fax, for UE by the CS Core network. In this case the services shall be provided by the CS domain or rejected in case the operator has decided not to support it.
• User performs configuration of supplementary services through 3G HNB from UE using CS procedures.

The architecture of an IMS capable HNB subsystem shall be based on the architecture of a non-IMS capable HNB subsystem as defined in TR 23.830 with the following clarifications and additions:

• It shall be possible to support access to the CS domain based on the architecture specified in TR 23.830. However, it is not mandated for a deployment to support access to the CS domain (as defined in TS 22.220).
• An IMS capable HNB subsystem shall support access to the PS domain based on the architecture specified in TR 23.830. Access to PS domain makes it possible to support the same PS access mobility mechanisms between different CSG cells and between CSG and non-CSG cells as that supported by a non-IMS-capable HNB subsystem.
• The architecture shall enable originated services requested by UEs with CS-specific NAS signalling (i.e. using TS 24.008) to be interworked with and provided by the IP multimedia core network subsystem (IMS). Similarly, the architecture shall enable terminated services in IMS to be delivered to UEs with CS-specific NAS signalling.
• If an IMS capable HNB subsystem provides access to the CS domain, then it shall route user-originated service requests to either CS domain or IMS based on operator policies. The domain selected to service a particular user-originated request shall be transparent to the UE and the user.
• The CS/IMS interworking functionality shall be transparent to UE. Therefore, the UE is not required to know if a HNB is IMS capable or not.
• When a new UE successfully enters into an IMS capable HNB (e.g. it is successfully authenticated and authorized to use this IMS capable HNB), the IMS capable HNB subsystem shall register this UE to IMS. This allows the IMS capable HNB subsystem to provide subsequent UE originated and terminated services (using CS-specific NAS signalling) over IMS.
• For support of CS UEs:
  1. The architecture shall permit a complete offload of the CS Core for services supported in IMS, e.g., basic voice call; other legacy CS services such as Circuit Switched Data/Fax, etc., may still be supported in CS core.
  2. The architecture shall support seamless handover from IMS Capable Home NodeB to macro cellular.
  3. The architecture shall provide protocol interworking between 3GPP SIP (from/toward the IMS Core) and TS 24.008 Call Control (from/toward the UE).
  4. The architecture shall permit service to be provided to inbound roamers.
  5. The architecture should build on the Iu-h approach; that is, it should be possible to migrate from 3G Home NodeB to IMS Capable Home NodeB.
• The architecture shall have minimal impact upon the pre-Rel 9 Core Network.
• The architecture shall satisfy the constraint that IMS is access independent.
• The architecture shall offer the same level of security to the network and to the UE as 3G Home NodeB.
• The architecture shall support the generation of appropriate accounting information for all subscribers served by 3G Home NodeB including the case when the UE moves between macro cellular and 3G Home NodeB.