Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x
Top   in Index   Prev   Next

TS 22.220
Service Requirements for HNB and HeNB

V18.0.1 (PDF)  2024/03  29 p.
V17.0.0  2022/03  29 p.
V16.0.0  2020/06  29 p.
V15.0.0  2018/09  29 p.
V14.0.0  2017/03  28 p.
V13.0.0  2016/01  27 p.
V12.0.0  2014/10  27 p.
V11.6.0  2012/09  27 p.
V10.10.0  2012/09  26 p.
V9.10.0  2012/09  24 p.
Rapporteur:
Dr. Swetina, Joerg
NEC Europe Ltd

Content for  TS 22.220  Word version:  18.0.1

Here   Top

 

0  Introductionp. 5

In Rel-8, 3GPP has specified the basic functionalities for the support of Home Node B (HNB) and Home eNodeB (HeNB). The requirements for these basic functionalities were captured in TS 22.011.
From Rel-9 onward, it has been agreed to consolidate all the requirements from Rel-8 and further requirements for HNB and HeNB in a new TS, which is this specification.

1  Scopep. 6

This specification defines the service requirements for the basic functionalities for the support of Home NodeB (HNB) and Home eNodeB (HeNB) – jointly referred to as H(e)NB – and the further functionalities that will enable the mobile operators to provide more advanced services as well as improving the user experience.

2  Referencesp. 6

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]  Void
[3]
TS 22.246: "Multimedia Broadcast/Multicast Service (MBMS) user services; Stage 1".
[4]
TS 22.101: "Service Aspects; Service Principles".
[5]
TR-069 Amendment 2: "CPE WAN Management Protocol v1.1, Broadband Forum", viewable at http://www.broadband-forum.org/technical/download/TR-069Amendment2.pdf
[6]
TS 25.304: "User Equipment (UE) procedures in idle mode and procedures for cell reselection in connected mode".
[7]
TS 36.304: "Evolved Universal Terrestrial Radio Access (E-UTRA); User Equipment (UE) procedures in idle mode".
[8]
TS 22.115: "Service aspects; Charging and billing".
[9]
TS 22.268: "Public Warning System (PWS) requirements".
[10]
TS 22.011: "Service accessibility".
[11]
TS 31.115: "Secured packet structure for (Universal) Subscriber Identity Mobule (U)SIM Toolkit applications".
[12]
TS 31.116: "Remote APDU Structure for (U)SIM Toolkit applications".
Up

3  Definitions, symbols and abbreviationsp. 6

3.1  Definitionsp. 6

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.
Closed access mode:
H(e)NB provides services only to its associated CSG members.
Home based network:
An IP based network in the same premises as, and is connected to, the H(e)NB.
Hybrid access mode:
H(e)NB provides services to its associated CSG members and to non-CSG members.
Open access mode:
H(e)NB operates as a normal NodeB or eNodeB.
HNB:
A HNB is a Customer-premises equipment that connects a 3GPP UE over UTRAN wireless air interface to a mobile operator's network using a broadband IP backhaul.
HeNB:
A HeNB is a Customer-premises equipment that connects a 3GPP UE over EUTRAN wireless air interface to a mobile operator's network using a broadband IP backhaul.
H(e)NB Gateway:
H(e)NB Gateway is a mobile operator's equipment (usually physically located on mobile operator premises) through which the H(e)NB gets access to mobile operator's core network.
H(e)NB Hosting Party:
A H(e)NB Hosting Party has a contractual relationship with the operator, related to the provision of access to the operator's network via one or more H(e)NBs.
H(e)NB Subsystem:
A H(e)NB Subsystem consists of the H(e)NB and the H(e)NB Gateway.
Up

3.2  Abbreviationsp. 7

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.
CSG
Closed Subscriber Group
HNB
Home NodeB
HeNB
Home eNodeB
H(e)NB
HNB and HeNB

4  Generalp. 7

4.1  Descriptionp. 7

Access to 3G and evolved 3G (EPS) services may be provided via UTRAN or E-UTRAN cellular base stations belonging to e.g. domestic, business, commercial enterprises. This type of access may be provided by the PLMN by means of HNB and HeNB (jointly referred to as H(e)NB). The H(e)NB provides services either only to a Closed Subscriber Group (CSG) or to other mobile subscribers too. The H(e)NB is connected to the mobile operator core network using IP via any suitable access technology.

5  Common requirements for Home NodeB / Home eNodeBp. 7

5.1  HNB and HeNB Installation, identification and location requirementsp. 7

 
  • H(e)NB shall have a unique equipment identity.
  • All the H(e)NBs serving the same CSG share the same unique (within the PLMN) identity called CSG Identity.
  • It shall be possible to support at least 125 million CSG Identities within a PLMN of an operator.
  • The radio transmitter of a H(e)NB shall not be activated until configured and authorised by the operator.
  • When installing, provisioning, configuring or re-configuring an H(e)NB the operator shall be able to:
    • verify the H(e)NB's identity.
    • obtain the geographical location of the H(e)NB.
  • The operator shall be able to determine that the H(e)NB is installed and operated in accordance with all relevant regulatory requirements.
  • The operator shall be able to configure the settings of the H(e)NB. In the case where the H(e)NB has detrimental impact on the spectrum usage, the H(e)NB can be set to out-of-service by the operator.
  • Installation and activation of a new H(e)NB shall require no reconfiguration of the operator's network.
  • The impact of H(e)NB on the core network should be minimised.
Up

5.2  OA&M Requirementsp. 8

 
  • H(e)NB shall support the automatic discovery of an operator's management platform.
  • It shall be possible to make use of the operator's management platform to carry out OA&M functions for H(e)NB. The management connection between H(e)NB and the operator's management platform shall be end-to-end secure.
  • H(e)NB shall support OA&M procedures which allow the operator to remotely configure the H(e)NB, deploy software upgrades, detect and report changes in RF conditions and perform general OA&M tasks. The OA&M procedures shall be as closely aligned as possible with those that are commonly used in broadband access networks such as defined in TR-069 Amendment 2 [5].
  • If the connection between H(e)NB and the rest of the operator network is out of service, then it shall be possible within an operator's defined time period for the H(e)NB to deactivate the air-interface.
  • When the H(e)NB Hosting Party authentication is required by the MNO, the H(e)NB shall not activate the air-interface unless the authentication of the H(e)NB Hosting Party has been performed successfully.
Up

5.3  Access Control requirementsp. 8

5.3.1  Generalp. 8

 
  • Subject to operator and H(e)NB Hosting Party agreement, the operator shall be able to configure the H(e)NB with open, hybrid or closed access mode.
  • When the H(e)NB is configured for open access mode, it shall be possible for the H(e)NB to provide services to subscribers of any PLMN, subject to roaming agreement.
  • When the H(e)NB is configured for hybrid access mode, it shall be possible for the H(e)NB to provide services to:
    • its associated CSG members, and
    • subscribers of any PLMN not belonging to its associated CSG, subject to roaming agreement.
  • When the H(e)NB is configured for closed access mode, only users that belong to its associated CSG shall be able to obtain services.
  • CSG members may include subscriber of any PLMN subject to roaming agreement, defined as HPLMN CSG Roaming.
  • The VPLMN may support VPLMN Autonomous CSG Roaming by providing CSG membership to the roaming subscriber without exchanging any CSG specific information with the HPLMN. The VPLMN shall disable VPLMN Autonomous CSG Roaming on a per HPLMN basis if requested by the home operator.
  • The CSG membership granted to the subscriber during his stay in the VPLMN may be retained by the VPLMN (e.g. in case the subscriber moves to another PLMN and subsequently returns to the VPLMN).
Up

5.3.2  Closed Subscriber Groupp. 9

 
  • The CSG manager shall be able, under the operator supervision, to add, remove and view CSG membership
  • For each subscriber, the network maintains a single CSG list containing the CSG identities that the subscriber is allowed to use.
  • The UE shall contain a list of allowed CSG identities (Allowed CSG List). It shall be possible to store the Allowed CSG List in the USIM. When available, the list on the USIM shall be used. It shall be possible for both, the operator and the UE, to modify the Allowed CSG List.
  • The UE shall allow the user to introduce new CSGs to the Allowed CSG List by means of manual CSG selection only.
  • The UE shall maintain an operator-controlled list of allowed CSG identities (Operator CSG list). It shall be possible to store the Operator CSG list in the USIM. When available, the list on the USIM shall be used. It shall be possible for the operator to modify the Operator CSG List.
  • The two lists are maintained independently from each other. A change in the Operator CSG list shall not trigger the UE to modify the Allowed CSG list to reflect such change automatically.
  • Except during manual CSG selection, all CSG cells belonging to a CSG identity not included in the Allowed CSG List or Operator CSG list shall be considered not suitable by the UE ("not suitable" as specified in TS 25.304 and TS 36.304).
  • Each CSG identity shall be associated to a subscriber group which identifies the subscribers allowed to access the CSG.
  • When the subscriber group is updated, the affected UE shall be informed accordingly.
  • For temporary members, it shall be possible to limit the period of time during which the subscriber is considered a member of a CSG (granted access rights). It shall be possible to configure a time period for each temporary member.
  • The time period shall be configurable by the CSG manager and/or the operator operating the CSG and shall span from 1 decihour to several days. Unlimited membership to the CSG is allowed.
  • When a CSG is no longer considered available to provide services, except for emergency calls (i.e. due to time period expiry or removal of the CSG membership), it shall be possible to continue the established communication in another cell not belonging to this CSG.
  • In hybrid access mode when services cannot be provided to a CSG member due to a shortage of H(e)NB resources it shall be possible to continue the established communication of non-CSG members in another cell.
  • In hybrid access mode, to minimise the impact on CSG members from established communication of non-CSG members, it shall be possible for the network to allow the data rate of established PS communication of non-CSG members to be reduced.
Up

5.4  Display requirementsp. 10

5.4.1  CSG Typep. 10

The CSG Type is an indicator provided by the UE that is configured by the operator.
  • It shall be possible for the operator to associate a CSG identity in the UE's Allowed CSG List or the Operator CSG List with a CSG Type. Therefore, it is possible that a CSG identity stored in different UEs may either be associated with the same CSG Type or with different CSG Types.
  • When a UE camps on a cell with a CSG identity that is part of the UE's Allowed CSG List and or the Operator CSG List has an associated CSG Type, a UE that has a display capability shall provide the user with the associated CSG Type. A UE that does not have a display capability may provide the CSG Type by other means, e.g. voice notification.
  • If the CSG Type for a CSG identity has not been configured in the UE, the UE may provide the HNB Name instead. In this case, the user is notified that the UE is providing the HNB Name rather than CSG Type.
  • It shall be possible to store the CSG Type in the USIM. As an option, the CSG Type may be stored in the ME. If the CSG Type is present in the USIM, a CSG Type stored in the ME shall be ignored. If the CSG Type is present in the Operator CSG list, a CSG Type present in the Allowed CSG list shall be ignored.
  • The CSG Type shall be stored in text and/or graphical format. When the CSG Type has a text component, the CSG Type text length shall not exceed 12 characters in any language.
Up

5.4.2  HNB Namep. 10

HNB Name is a common name referring to HNB/HeNB as defined in TR 21.905.
  • It shall be possible for a CSG cell and for a hybrid cell to broadcast a HNB Name in free text format. The UE may display the HNB Name when camping on the cell where it is broadcasted. The HNB Name, if broadcasted or stored in the UE, shall be available to the user during manual CSG selection. The HNB Name shall be configurable by the operator or the H(e)NB Hosting Party at the discretion of the operator.
  • The HNB Name length shall not exceed 48x8 bits.
  • If available and depending on operator preferences a HNB Name may be stored together with the associated CSG Identity in the UE's Operator CSG List.
  • If available and depending on operator preferences a HNB Name may be stored together with the associated CSG Identity in the UE's Allowed CSG List.
  • A HNB Name present in the Operator CSG list shall take precedence over a HNB Name present in the Allowed CSG list, which in turn shall take precedence over the broadcasted HNB Name.
Up

5.5  Mobility Aspects for Home NodeB and Home eNodeBp. 11

5.5.1  PLMN selectionp. 11

The standard automatic and manual network selection procedures are used to register a UE on a PLMN via a H(e)NB.

5.5.2  Idle-mode operationp. 11

In addition to normal cell reselection procedures, the following requirements apply:
  • It shall be possible to support idle mode mobility between a H(e)NB cell and other cells and between H(e)NB cells.
  • A UE in idle mode shall prefer to select a cell whose CSG Identity is in the UE's Allowed CSG List or in the Operator CSG list, when the cell reselection criteria has been met.
  • The cell reselection procedure should not result in excessive power consumption in the UE.
Up

5.5.3  Connected mode operationp. 11

 
  • It shall be possible to support service continuity, including handover, between a H(e)NB cell and other cells and between H(e)NB cells. This includes H(e)NB cells in residential and enterprise environment.
  • For operational and deployment purposes, handovers between a H(e)NB cell and other cells and between H(e)NB cells should not significantly increase mobility related signalling.
  • Data session(s) may be terminated by the network after the UE leaves the H(e)NB coverage area on a per UE basis (e.g. based on subscriber tariff change).
Up

5.5.4  Manual CSG selectionp. 11

The user shall be able to request the UE to perform a scan for available CSGs. When such request is received the UE shall perform a scan of available CSGs, their CSG Identities and their HNB Names. In the UE display, the available CSGs shall be represented by their associated HNB Names and PLMN Name(s). If the HNB Name is not available, the CSG Identity shall be displayed instead.
An indication shall be given to the user as to which of the available CSGs is contained in the Allowed CSG List or Operator CSG list. The available CSGs shall be displayed in the following order:
  • The CSGs, whose CSG Identities are contained in the Allowed CSG list.
  • The CSGs, whose CSG Identities are contained in the Operator CSG List.
  • Any other CSG, whose CSG Identity is not included in the Allowed CSG List or the Operator CSG list.
The HPLMN shall configure, on a PLMN basis, the UE to display the available CSGs so that either:
  • all CSGs are displayed, or
  • only CSGs in the Operator CSG List are displayed.
By default, the UE shall display all available CSGs for any PLMN, unless the UE has been configured by the HPLMN, for a specific PLMN, to display only CSGs in the Operator CSG List that are available.
When the user selects an entry in the list, the UE shall reselect any of the available cells with the CSG chosen by the user.
The UE shall attempt to register to the PLMN.
If the registration attempt is accepted, the UE shall add the CSG identity to the Allowed CSG list unless the cell is a hybrid cell or the identity is already present in the list.
If the registration attempt is accepted and the UE is allowed to add the CSG identity to the Allowed CSG list then the UE may add the broadcasted HNB Name to the Allowed CSG list.
If the registration attempt is rejected and the CSG entry is in the Allowed CSG list, that CSG and the associated HNB Name shall be removed from the Allowed CSG list.
In addition, when the user manually selects a CSG in a PLMN, which is different from the last registered PLMN, the following behaviour applies:
  • The UE shall enter into Manual PLMN Selection state.
  • The UE shall attempt to register to the PLMN. This PLMN shall not be stored as the Last Registered PLMN.
  • When the UE is no longer in the service area of the CSG the UE shall return to the previous PLMN Selection state.
Up

5.6  Services supportp. 12

5.6.1  Generalp. 12

 
  • Subject to availability of network resources there shall be no difference in the user experience when using the PLMN provided services via H(e)NB or via NodeB/eNodeB (NB/eNB).
  • Depending on operator preferences and in compliance with regulatory requirements ETWS and PWS [9] shall be supported.
  • Any additional registration and paging load as a result of H(e)NB deployment shall be minimized.
  • Deployment of H(e)NBs and NB/eNBs on the same spectrum should not degrade the performance of UEs receiving service from NB/eNBs.
  • Deployment of H(e)NBs and NB/eNBs on the same spectrum should not degrade the NB/eNB's coverage and capacity.
Up

5.6.2  Emergency servicesp. 12

 
  • Subject to local regulatory requirements, H(e)NB shall support emergency calls, as specified in TS 22.101.
  • It shall be possible for the operator to provide location information of the UE attempting an emergency call over a H(e)NB. The location information shall be sufficiently accurate to comply with the regulatory requirements that apply to the area where the H(e)NB is deployed.

5.6.3  IMS Interworkingp. 12

 
  • The operator can provide CS-to-IMS interworking as specified in the IMS Centralized Services clause of TS 22.101.

5.7  Local IP Access (LIPA)p. 13

5.7.1  Descriptionp. 13

Local IP Access provides access for IP capable UEs connected via a H(e)NB (i.e. using H(e)NB radio access) to other IP capable entities in the same residential/enterprise IP network. Data traffic for Local IP Access is expected to not traverse the mobile operator's network except mobile operator network components in the residential/enterprise premises. Signaling traffic will continue to traverse the mobile operator network. The residential/enterprise IP network itself and the entities within that network are not within the scope of 3GPP standardisation.
Local IP Access via H(e)NB
Up

5.7.2  General requirementsp. 13

A H(e)NB subsystem shall be able to support Local IP Access in order to provide access for IP capable UEs connected via a H(e)NB subsystem (i.e. using H(e)NB radio access) to other IP capable entities in the same residential/enterprise IP network.
  • Simultaneous access from a UE to the mobile operator's core network (e.g. internet, PLMN services) and Local IP Access to a residential/enterprise IP network shall be supported.
  • Subject to regulatory requirements, Local IP Access traffic shall be routable only between the UE, H(e)NB and other entities within the residential/enterprise IP network.
  • A UE shall have a valid subscription with the mobile operator in order to use Local IP Access.
  • A UE shall be able to use Local IP Access in a visited network subject to roaming agreement between mobile operators.
  • The HPLMN shall be able to enable/disable LIPA usage when the UE roams to particular VPLMNs.
  • Local IP Access shall not affect services running in parallel for the same UE.
  • Pre-Rel 10 UEs should be able to use Local IP Access.
  • The user may be notified when a H(e)NB provides access to a residential/enterprise IP network
  • A UE using Local IP Access shall be contactable by another IP endpoint in the same residential/enterprise IP network via Local IP Access.
  • The operator shall be able to configure the network to support connection request from a UE so that a LIPA connection is used when the UE is located within the residential/enterprise IP network, and a regular connection via the Core Network is used otherwise.
  • It shall be possible for a UE to maintain its IP connectivity to the residential/enterprise IP network when moving between H(e)NBs within the same residential/enterprise IP network. Any interruption to this IP connectivity shall be limited to levels comparable to that of the IP connectivity for PLMN services.
  • The mobile operator shall be able to configure the H(e)NB to enable/disable Local IP Access.
  • The mobile operator shall be able to enable/disable Local IP Access per user subscription per CSG.
  • The H(e)NB Hosting Party, within the limits set by the mobile operator, shall be able enable/disable Local IP Access per H(e)NB.
  • The H(e)NB subsystem shall allow the mobile operator to make traffic and signalling performance measurements related to Local IP Access for each user and for the H(e)NB.
  • The H(e)NB subsystem shall allow the mobile operator to collect fault management information related to Local IP Access for each H(e)NB.
  • Local IP Access shall not compromise the security of the mobile operator's network.
Up

5.8  Managed Remote Access to home based networkp. 14

 
  • The H(e)NB may support remote access for a CSG member to the home based network from a UE via a PLMN in order to provide access to IP capable devices connected to the home based network.
  • It shall be possible to restrict the access to the home based network on per-subscriber basis (e.g. some subscribers may have managed access to their home network and others may not).

5.9  Selected IP Traffic Offload (SIPTO) at Local Networksp. 14

It shall be possible that a H(e)NB SubSystem supports Selected IP Traffic Offload to provide access for a UE connected via a H(e)NB (i.e. using H(e)NB radio access) to a defined IP network (e.g. the Internet). The following requirements apply to the H(e)NB SubSystem to support Selected IP Traffic Offload at the local residential/enterprise IP network:
  • Selected IP Traffic Offload shall be possible to be done without traversing the mobile operator network, subject to regulatory requirements.
  • The mobile operator and the H(e)NB Hosting Party, within the limits set by the mobile operator, shall be able to enable/disable Selected IP Traffic Offload per H(e)NB.
  • Based on mobile operator SIPTO policies and configured user consent per APN, the network shall be able to offload traffic.
  • The SIPTO policies may be defined per APN or per IP flow:
    • SIPTO policies per APN indicate whether all traffic associated with a specific APN is subject to offload;
    • SIPTO policies per IP flow are routing policies indicating which APN to use for a specific IP flow. The Operator may provide routing policies to the UE that assist the UE in routing the IP flows towards an appropriate APN. This is applicable for UE regardless of whether or not it has established IP connectivity to the local enterprise/residential network.
  • The mobile operator shall be able to configure the SIPTO policies either statically or dynamically.
  • Simultaneous connectivity from the UE to the mobile operator's core network and to a defined IP network (e.g. the Internet) via a fixed residential/enterprise IP network using SIPTO shall be supported.
  • Simultaneous access from the UE to PLMN services and to fixed services via a fixed residential/enterprise IP network using SIPTO shall be supported.
Requirements that are common with Selected IP Traffic Offload in the mobile operator networkcan be found in section 4.3.5 in [4].
Up

5.10  UICC and H(e)NBp. 15

Optionally, the H(e)NB may support identification and authentication of the H(e)NB Hosting Party by means of a UICC-based application.
This application may also contain information for the initial provisioning (e.g. the O&M system contact).
If the H(e)NB supports the H(e)NB Hosting Party application,
  • The H(e)NB shall support the use of the operator's UICC application management platform to configure the Hosting Party application.
  • The UICC application shall be able to acquire the geographical location of the H(e)NB.
Up

5.11Void

6  Requirements for Home NodeBp. 15

6.1  Access Controlp. 15

 
  • It shall be possible to control access (i.e. accept and reject connection requests) of pre-Release 8 UEs.
  • The operation of a HNB shall not adversely impact the performances of a pre-Release 8 UEs operating in the area where the HNB is active and vice versa.
  • The total bandwidth from the HNB towards the network for 4 simultaneous TS11 or TS12, including signalling and overhead, shall not exceed 200 kbps

6.2Void

7  Requirements for Home eNodeBp. 16

8  Quality of Servicep. 16

8.1  Generalp. 16

 
  • Subject to agreement between the mobile operator and the broadband access provider, it shall be possible to request resources from the broadband IP backhaul for the QoS treatment for sessions traversing the H(e)NB subsystem.

8.2  Admission Controlp. 16

 
  • The network shall be able to perform admission control based on the available H(e)NB backhaul resource.
  • The network shall be able to set different criteria for admission network control in a hybrid cell for CSG and non-CSG members.

9  Security and privacyp. 16

9.1  Generalp. 16

 
  • The use of H(e)NB shall not compromise the security of any PLMN or broadband access network.

9.2  Security Requirementsp. 16

 
  • The H(e)NB shall provide a high level of security, equivalent or better than Rel-8 3GPP systems.
  • Security policy shall be under the control of the H(e)NB network operator.
  • The H(e)NB shall not impact the security of the UE.

9.3  Privacyp. 16

 
  • The H(e)NB shall not compromise user privacy for UEs that are using the H(e)NB, including communication confidentiality, location privacy and identity protection.

10  Charging Aspectsp. 17

A  Use casesp. 18

These use cases do not imply any requirement beyond that which is contained in the normative part of this TS.
Usecase-1: H(e)NB Mobility
User A connects to the H(e)NB via mobile device. User A should be able to move around within the H(e)NB coverage in the home or enterprise. User should also be able to invoke additional services based on user policy and operator policy.
Usecase-2: H(e)NB Guest Users
User A and User B are subscribers of Operator 1 and Operator 2 respectively. User A visits User B in his home and User B allows User A to use H(e)NB in User B's home. User A should be able to access all the services he is subscribed to from Operator 1 based on the policies set by User B and operator 2. Operator 1 and Operator 2 have roaming agreement.
Usecase-3: HNB/HeNB - NB/eNB Handovers
User A subcribes to cellular services of Operator 1 and is authorised to access a HNB/HeNB from same or other operator. User A starts service in the H(e)NB coverage and continues moving into a cellular network. Similarly User A starts service in cellular network and continues moving into H(e)NB coverage. User A does not see any impact on services due to mobility in both cases.
Usecase-4: Access to Home based services
User A connects to the H(e)NB via mobile device. User A should be able to access home based services (e.g. local digital media servers and digital media players) from the mobile device. Other users may access the home based services subject to H(e)NB Hosting Party policies.
Usecase-5: Media Transfer
User A connects to the H(e)NB via mobile device. User A starts viewing video streaming service on the mobile device. User A then wants to continue viewing the video on a different screen for better viewing. User A should be able to transfer the session to a high-definition TV or PC connected via broadband connection. User A should also be able to transfer the session from the TV or PC to a mobile device and continue the session in the H(e)NB coverage and also in the cellular network.
Usecase-6: IMS capable HNB used for coverage purposes
In this scenario, the reason for an operator to introduce IMS capable HNB is to offload voice traffic from his existing CS core network to IMS. However, as in this scenario the usage of 'legacy' services (e.g. CS Fax) is still assumed - only the utilization of network resources is to be changed - it is requested that IMS capable HNB provides all the services/ capabilities that are provided through regular Node B from the beginning.
Usecase-7: IMS capable HNB for a new business model
This scenario starts with a view that HNB is located in the user's residence and the UE is the preferred equipment to interact with home services/ applications. New business can be expected there. In this scenario, some of the CS services/ capabilities that are provided through regular Node B might not be needed or might be provided in a later step if the operator could instead offer attractive new services under IMS capable HNB only.
Usecase-8: IMS capable HNB for Green field operator
This scenario expects new players to get into the mobile market. In this scenario, they would aim to deploy cost efficient and future proof infrastructure, i.e. no CS domain but IMS/PS domain only, regardless of whether or not UEs have IMS client on them.
Usecase-9: Hybrid access mode
In order to improve the coverage in a shopping mall, H(e)NBs are deployed. The shopping mall owner may have been provided a special deal by the network operator where the employees of the shopping mall will get preferential charging rates and priority access when accessing services via these H(e)NBs. In exchange, the shopping mall owner allows the public to use the H(e)NBs to access the normal network operator services. The H(e)NB Hosting Party should not need to manage the public access and the public should not need to do anything special in order to get services on the H(e)NB.
Use case-10: Open access mode
Typically to enhance coverage or capacity of an operator's public network, for example in railway stations, airports, stadiums, etc, taking benefit of the H(e)NBs additional functionality (e.g. uncoordinated deployment).
Usecase-11: HNB interacts with Home network
User A connects with his UE (possibly a pre-Rel 9 UE) to the HNB with IMS Interworking and Local IP Access to the home network capabilities. The home network accommodates home network devices (Intercom, Door lock, Network radio, Photo server, etc.) and the HNB. User A should be able to communicate with a visitor at Intercom via the mobile device.
Usecase-12: HNB interacts with IP-PABX
User A connects with his UE (possibly a pre-Rel 9 UE) to a HNB with IMS Interworking and Local IP Access to the home network capabilities at an office. The HNB might be deployed and interconnect with an enterprise extension telephone system (e.g. SIP based PABX). User A should be able to make/receive an extension call to/from fixed line UE under SIP based PABX. In addition, User A with the mobile device and User B with computers should be able to access a common groupware server at the office and share the same information such as schedule, emails, etc.
Usecase-13: Electronic customer guide in shopping centre, using Local IP access
A department store or shopping centre provides electronic shopping guide. When user A enters into a shopping centre where a shopping centre H(e)NB is installed, an invitation indication shows up on his mobile device which he accepts. This allows him access to the centre's H(e)NB. Subsequently, he accesses the centre's customer service server, which is only accessible through the H(e)NB where he uploads his shopping list. The customer service server responds a list of sale items of similar nature. He accepts or declines the various choices and the final shopping list is downloaded to his UE. While user A is waiting, User A watches free TV show or advertisement provided through the H(e)NB for the shop customer. While in the shopping centre the user has simultaneous access to operator's and local shopping centre services.
Usecase-14: Local IP Access
The user has the subscription through home operator H. The user is served by the home operator H. The UE obtains IP connectivity in both a local gateway to obtain local connectivity for IMS services (e.g. as in local IP access or for enterprise scenarios with call to other terminals in the PABX area) and to a home gateway (as in normal connectivity for IMS services). For IMS sessions to be routed to e.g. remote terminals, the traffic is sent through the connectivity with the home gateway, whereas for IMS session that can be routed locally (e.g. based on local phone number), the traffic is sent through the connectivity with the local gateway through the local IP access. Whether the UE routes a specific IMS session through the local access or the home gateway can be controlled on a per session basis. Also, the UE may obtain local connectivity by default (e.g. based on static configuration by the operator) or dynamically based on indication by the IMS server.
Usecase-15:
Subscriber A from Network A owns HNB/HeNB A because of no macro network coverage .
Guest user B from Network B visits subscriber A's house. Subscriber A wants to allow guest user B access to HNB/HeNB A while the guest user B is visiting.
Usecase-16:
Corporation A has sites in country A, B and C.
Corporation A has employees from country A and B.
Employees in country A are from Operator AA and AB.
Employees in country B are from Operator B.
Corporation A has HNB/HeNB in country A from Operator AA and country B from Operator B.
Employees from country A and B are allowed access to HNB/HeNBs in country A and B.
Usecase-17: Content-sharing services in the residential IP network
During a trip to the zoo Alice has taken several pictures and has recorded a video clip on her UE. After returning home her UE connects to the H(e)NB in the home and accesses the residential IP network. The local devices (video, printer, ..) are automatically discovered by the UE. Alice views the videos on her video player, prints photos on her printer, uploads her media onto media server, and downloads media for her next outing.
Up

B  Clarification of H(e)NB Access Modesp. 21

Table B.1 illustrates the different H(e)NB Access Modes and what access is allowed for UEs of any release depending on whether the UE is allowed access to the CSG.
In Table B.1 "Access" means "Access to services".
"Preferential access" means the user will get preferential access to the cell.
H(e)NB Access Mode
Open Closed Hybrid
UE allowed access to CSGAccessAccessPreferential Access
UE not allowed access to CSGAccessNo AccessAccess
 
Up

C  Overview of identifiers and names.p. 22

item used for associated with permanently stored in distribution method displayed to user comment
H(e)NB equipment identity administrative purposesH(e)NB (physical entity)H(e)NB

administration database of the operator
O&M proceduresNOnot known to UE, therefore not useable by UE to identify a H(e)NB
CSG identity automatic and manual CSG selection

access control to CSG cells
a CSG, i.e. a group of users (UEs). One or More H(e)NBs (CSG cells)H(e)NB administration database of the operator Allowed CSG List in the UE if user (UE) is member of CSG (USIM entry takes precedence over ME) provided by O&M to H(e)NBs provided by home PLMN to UEs (the Home PLMN and Visited PLMN should synchronize this information ) Provided to the UE by OMA DM when stored in the ME, Provided to the UE by OTA when stored in the USIM Provided to UE via manual CSG selection broadcasted by H(e)NB YES, if HNB Name is not availableA CSG identity is unique within a PLMN. In the UE a CSG ID, together with a network identifier, identifies a CSG globally uniquely.
HNB name (optional) for supporting (ease of use) manual CSG selection, displaying a "friendly" name to the userCSG identity (relationship: m CSG ID : n HNB names)H(e)NB

administration database of the operator

UE
Provided by O&M to H(e)NBs

Optionally stored by user in UE

broadcasted by H(e)NB
YES during manual selection, OPTIONAL during normal operation. (USIM entry takes precedence over broadcast and ME) If a HNB name is stored in the UE it needs to be associated with a CSG identity. Initial configuration in the UE may be done by the operator (e.g. at point of sale). Later, a HNB name is implicitly associated to the current CSG identity by the UE when the user stores the HNB name
CSG Type for additional information (on e.g. billing mode) to the user when camping on a CSG cell (i.e. after CSG has been selected)CSG identity (relationship: n  CSG ID : 1  CSG Type)administration database of the operator

UE
provided by initial UE configuration, OTA and device management to UEsYES, if CSG is in Allowed CSG List. (USIM entry takes precedence over ME)UE needs to associate a CSG Type with a CSG identity

Association done by operator (the Home PLMN and Visited PLMN should synchronize this information)
Up

$  Change historyp. 24


Up   Top