The present invention relates to management of access points connected to a mobile network, and to management of femtocell access points.
With increasing demand of broadband and wireless broadband traffic (e.g. multimedia, video) over Internet, home and office users are fast be-coming important target customers for wireless operators and solution providers. The devices typically are installed to the customers' premises by the customers themselves. The customers' existing broadband internet connections (such as DSL or cable) may be used as backhaul connections to the service provider's network and the devices are powered from the customers' electricity sockets.
As the femtocells are installed indoors they will allow service providers to extend service coverage indoors, especially where access would otherwise be limited or unavailable. People living in rural areas can use them in to gain better coverage. Femtocells will also give some additional network capacity due to the small cell size and reduce the load of the macrocells. On the other hand they will also use the same radio resources as macrocells and interfere the macro layer as any other base stations. There are also numerous other challenges in implementing an efficient solution.
The femtocell incorporates the functionality of a typical base station but extends it to allow a simpler, self contained deployment. An example is the 3rd Generation Partnership Project (3GPP) Femto system but the concept is applicable to all standards.
The home base station installation is done by the customers most of whom are non-technical people. The installation process must be straightforward and automatic. Even then the operator needs to have some means of technical support just to tell which wires are plugged where. There might be different device types connecting either to Ethernet or with an integrated DSL or cable modem (this connection may be referred to as a backhaul connection). When plugged into the customer's electric outlet and internet connection, the home base station needs to first determine the correct settings for the backhaul connection. Preferably DHCP or some other means of automatic negotiation is used to get the IP and DNS settings. When these settings are set and a secure backhaul connection is working between a secure gateway and the home base station, the home base station needs to be authenticated by a secure network gateway and/or some specific authentication entity on the network side.
An authentication of a home base station may be based on an identity received from the home base station. However, there may be alternative identities that the home base station may use for authentication, e.g. depending on the authentication performed. For example, the home base station may be primarily authenticated by a Device Authentication wherein a device identity (ID) of the home base station is used. It is a mutual authentication between the home base station device and the operator's network. Each home base station is provided with a unique device identity.
Alternatively or following to the device authentication, the home base station may be authenticated by a user authentication wherein a user identity (ID), such as IMSI (International Mobile Subscriber Identity) is used. An example of a user authentication is a Hosting Party Authentication. The Hosting Party of the home base station means the party who is hosting the home base station and has a contractual relationship with the PLMN operator. The hosting party of the home base station will typically be the “lead” user in a household, but could be e.g. the corporate IT manager in an enterprise context. For this purpose, the home base station may support identification and authentication of the hosting party by means of a Subscriber Identity Module (SIM) or a Universal SIM (USIM). The USIM/SIM card may be used in a home base station device similar to a mobile phone. In both the device authentication and the user/hosting party authentication a secure connection or tunnel is established between the home base station and the security gateway in case of a successful authentication.
When the home base station is functioning as a part of the network, a home base station management system is used to remotely change configurations, perform software updates and manage the general Operations, Administration and Management (OAM) tasks, such as monitoring for faults and performance. After a successful authentication, the home base station management system sends the configuration data to the home base station and manages the base station over a secured management connection. In the case the management system is inside the network operator's core network, the secure management connection may be using the secure connection between the security gateway and the home base station. In that case no mutual OAM authentication may be performed between the home base station and the management system but the management system relies on the authentication performed by the security gateway. In other words, if the identity of the home base station is sent to the management system via the security gateway, then the management system may trust that a device authentication and/or hosting party authentication were successful and that the received identity can be accepted and the configuration data can be sent. The received identity can be e.g. the device ID, the IMSI, both or another unique ID. However, the management system may not be able to unambiguously derive which identity for the home base station is used for OAM after performing successful authentication. Moreover, part of the configuration data is subscriber/user related when a USIM/SIM card is used, and this USIM/SIM card can be used in any home base station device. Here the problem is, no matter which identity is used, from the OAM point of view how to obtain the correct configuration data for one home base station. Furthermore, the configuration data which are related to user and USIM/SIM card maybe stored on the device and not on the SIM/USIM card and HP Authentication process doesn't check whether the USIM/SIM card is plugged into the same device or a physically different device.
An object of the present invention is to provide a more effective management of configuration data for femtocell access points. The object of the invention is achieved by a method and apparatuses recited in the independent claims. Embodiments of the invention are disclosed in the dependent claims.
An aspect of the invention is a method for managing femto access points in a femto management system of a mobile communications network, comprising storing configuration data for a plurality of femto access points connected to the mobile communications network,
classifying the configuration data into device-related configuration data, which are indexed by device identity, and into subscriber/user-related configuration data, which are indexed by subscriber/user identity,
setting up, after a successful authentication of a femto access point to the mobile communications network, a binding relationship between a device identity of a device part of the authenticated femto access point and a subscriber/user identity of a subscriber identity module inserted into the device part of the femto access point,
According to a further aspect of the invention the method comprises
In the following the invention will be described in greater detail by means of exemplary embodiments with reference to the attached drawings, in which
In the following the invention is described with exemplary embodiments in which the 3GPP Femto system is used but the invention is not intended to be limited to the 3GPP Femto. To the contrary, Femto related topics are widely and deeply discussed in different standardization organizations, e.g. Femto Forum, Broadband Forum, 3GPP, WiMAX Forum and so on. The management principles according to the present invention can be used for all other Femto related technologies, e.g. WiMAX Femto system, LTE Femto system, Femto/Self Organising Network (SON), etc., as a general solution to bind a femto access point device and a subscriber identity module, such as an USIM/SIM card.
The term femto access point (FAP), or “Femtocell” in general, as used herein refers to any femto related access point, such as any Fixed Access Point, Home Base station, Home Node B, etc.
Typically, femto access point is a small-scale cellular base station designed specifically for indoor coverage. As such, it may communicate to the user's mobile handset over the standard-based radio interface using licensed spectrum and further connects to the mobile network infrastructure over the fixed broadband connection.
The 3rd Generation Partnership Project (3GPP) is setting the standards on the 3G Femto. 3GPP standards introduce new network elements, such as the Home NodeB (HNB) or Home eNodeB (HeNB), and the Home NodeB Gateway (HNB-GW) or the Home eNodeB Gateway (HeNB-GW), and a new interface (Iu-h, S1) between them. Also logical elements Security Gateway (SecGW) and HNB Management System (HMS) or HeNB Management System (HeMS) are specified. Access to 3G and evolved packet system (EPS) services may be provided via UTRAN or E-UTRAN home base stations. In case of UTRAN, names HNB, HNB-GW, and HMS are typically used, whereas in case of E-UTRAN, names HeNB, HeNB-GW, and HeMS are typically used. For simplicity of the description, these network elements of the two access types are jointly referred to as H(e)NB, H(e)NB-GW, and H(e)MS herein.
The Iu-h is the interface between the HNB and HNB-GW. The Iu-h interface may be tunneled over the residential internet connection of the customer and over the public internet. In other words, the backhaul link used between HNB and SecGW provides a secure tunnel carrying both the user plane data and the control plane data that are transmitted between the HNB and network elements in the core network. The Iu-h interface provides transport for the control and user plane messages. RANAP user adaptation (RUA) is used over Iu-h to provide transparent transfer for the RANAP messages and another control plane protocol called the Home NodeB Application Protocol (HNBAP) is as well introduced. HNBAP is used to carry the HNB specific control information between the HNB and HNB-GW. Transparent transport is also provided for the Iu user plane protocol layer, which is terminated at the core network, not at the HNB-GW. All this may be carried over an encrypted IPsec tunnel. It should be noted that for the LTE the H(e)NB uses S1 interface and not Iu-h, The Security Gateway (SecGW) is a logical element which can be physically implemented separately or as an integrated solution with the HNB-GW. The SecGW may terminate the IPSec tunnels for TR-069 and Iu-h protocols and act as a firewall between the operator's core network elements and the public internet. The SecGW represents operator's core network to perform mutual authentication with HNB and it provides access to HMS and HNB-GW. The Home NodeB Management System, i.e. HMS, may use an interface based on the TR-069 standards widely used in DSL modem and DVB set-top-box management and updates. The management system may send the configuration data to the HNB and help the HNB in HNB-GW and SecGW discovery. It may also initiate HNB software updates and perform HNB location verification. The interface between the H(e)NB and the H(e)MS is TR-069. The H(e)MS may comprise a TR-069 manager and a file server. The TR069 manager implements the Auto-Configuration Server function as defined in TR-069 standard and performs CM, FM and PM functionalities to the H(e)NB. The file server may be used for file upload or download, as instructed by TR-069 manager. The H(e)MS is referred to as ACS (Automated Configuration Server) by some organisations, such as Femto Forum and Broadband Forum.
The H(e)NB architecture and the elements differ from the standard UTRAN and E-UTRAN configuration, and so does their functionality too. The things usually handled by the NodeB are now divided between the HNB and HNB-GW. The functional split between the devices is specified in the Release 8 TS 25.467 which specifies the UTRAN architecture.
Because the H(e)NB itself is the part which actually contains the radio and is located near the user, it has main responsibility on radio resource and RAB management tasks. The H(e)NB is in charge of the admission control and together with the CN it manages the RAB establishments, modifications and releases. Security functions on the air interface, like ciphering, are also managed by the H(e)NB with CN managing the key.
Several types of interfaces have been specified between H(e)NB and H(e)MS.
As specified, TR-069 protocol is used between H(e)NB and H(e)MS to support management functionalities, i.e. TR-069 will be reused for 3G Femto and LTE Femto. Furthermore, TR-069 is also applicable to WiMAX Femto and may be used by further Femto technologies as well.
Furthermore, as one of the requirement, H(e)NB architecture allows to operate the H(e)MS inside the operator's core network (i.e. TR-069 CWMP based connection using the IPSec tunnel between SecGW and H(e)NB) or outside the operator's core network (i.e. TR-069 CWMP based connection between H(e)NB and H(e)MS using the Internet).
As noted above, the H(e)NB may be authenticated by the SecGW based on a globally unique and permanent H(e)NB identity. In the latest version of TS 22.220, H(e)NB Hosting Party concept is introduced which means that HP has a contractual relationship with the operator. Accordingly, in the latest version of TS 33.320, Hosting Party (HP) Authentication has been specified, which means that the H(e)NB may support identification and authentication of the H(e)NB Hosting Party by means of a USIM/SIM application. HP Authentication is optionally supported by operators, i.e. certificate-based Device Authentication may optionally be followed with an EAP-AKA-based Hosting Party Authentication exchange between H(e)NB and the AAA (Authentication, Authorization and Accounting) server. The HSS (Home Subscriber Server) stores the subscription data and authentication information of the H(e)NBs. The AAA server authenticates the hosting party based on the authentication information retrieved from the HSS when hosting party authentication is per-formed. Both Device Authentication and Hosting Party Authentication use IKEv2 protocol to establish the IPSec tunnel between H(e)NB and SecGW in case of successful authentication. Furthermore, the USIM/SIM card can be used in any femto device similar to a mobile phone. The different authentication options and the different alternative identities raise problems in the OAM point of view. Examples of these problems will be explained referring to
No binding between the H(e)NB device and the USIM/SIM card means that the HP Authentication process used to establish the IPSec tunnel between SecGW and H(e)NB does not check if the USIM/SIM card is plugged into the same H(e)NB device or a physically different H(e)NB device. It is also not checked if an USIM/SIM card is plugged out and replaced by a card of another user who belongs to the same Operator Network. As a result, the OAM Management System (H(e)MS) is not able to configure the H(e)NB properly when Hosting Party authentication is used.
According to a first aspect of the present invention the configuration data stored in the H(e)MS is classified into two types: a) Device-related configuration data, which are indexed by DeviceID; and b) Subscriber/User-related configuration data, which are indexed by IMSI (steps 41 and 42 in
Embodiments of the present invention provide a simple method to setup/re-setup the binding relationship between USIM/SIM card and femto device on the H(e)MS even if the relationship is changed. The binding is used to generate a definition for the common subset between device features and subscribed features. Only combination of both allows providing correct configuration. There is no need to distinguish whether the data are stored in the SIM/USIM or in the device part. When a USIM/SIM card is used for a different device, only a part of configuration data (i.e. subscriber-related data) needs to be reconfigured on the H(e)NB. The H(e)NB identity can be DeviceID or IMSI or the combination of DeviceID and IMSI, which are all possible to femto system.
Furthermore, besides the above identity definition, the H(e)NB identity could be any ID used for OAM (e.g. MAC address). Which kind of H(e)NB identity is used in each specific mobile network is decided by the network operator. A device identity as defined in TR-069 consists of following information: Manufacturer, OUI, ProductClass and Serial Number. The combination of OUI, ProductClass and Serial Number may be considered as a unique Id. In the case of HP authentication it is also possible to use a simplified index, e.g. OUI and Product Class to identify the device related config data. However, the present invention is not limited to a use of any unique ID. To the contrary, the above-mentioned DeviceID, IMSI and combination of both can be replaced with any unique ID (e.g. MAC address) used to identify the device or the USIM for management tasks.
OAM procedures where aspects of the present invention are applied are now illustrated referring to
In the following, an exemplary scenario is illustrated wherein the H(e)MS receives the H(e)NB identity after a successful Hosting Party authentication (step 43 in
In embodiments of the invention the H(e)MS may start a reconfiguration via a factory reset or via a configuration procedure as defined in TS 32.583/TS 32.593. The binding of IMSI and DeviceID at the H(e)MS may be stored permanently or on a temporary basis. “Temporary” storing may mean that the configuration data are stored for the bound IMSI and DeviceID, and if a change of the USIM/SIM at a H(e)NB device is detected, the associated configuration may be deleted at the H(e)MS directly or according to rules defined by the Network Operator. As mentioned above, in embodiments where the H(e)NB does not detect or report in operation an USIM/SIM change, the binding check may need to be performed with every TR-069 session establishment. If the H(e)NB reboots the H(e)NB after an USIM/SIM change, the binding check may be limited to a TR-069 session establishment with an RPC method inform and event >>boot<<. If the H(e)NB reports an USIM/SIM change, the binding check may be performed only after the H(e)MS receives the Inform message that reports the USIM/SIM change.
The techniques described herein may be implemented by various means so that an apparatus implementing one or more functions bf a corresponding mobile entity described with an embodiment comprises not only prior art means, but also means for implementing the one or more functions of a corresponding apparatus described with an embodiment and it may comprise separate means for each separate function, or means may be configured to perform two or more functions. For example, these techniques may be implemented in hardware (one or more apparatuses), firmware (one or more apparatuses), software (one or more modules), or combinations thereof. For a firmware or software, implementation can be through modules (e.g., procedures, functions, and so on) that perform the functions described herein. The software codes may be stored in any suitable, processor/computer-readable data storage medium(s) or memory unit(s) or article(s) of manufacture and executed by one or more processors/computers. The data storage medium or the memory unit may be implemented within the processor/computer or external to the processor/computer, in which case it can be communicatively coupled to the processor/computer via various means as is known in the art.
While particular example embodiments according to the invention have been illustrated and described above, it will be clear that the invention can take a variety of forms and embodiments within the spirit and scope of the appended claims.
Filing Document | Filing Date | Country | Kind | 371c Date |
---|---|---|---|---|
PCT/CN2009/001496 | 12/18/2009 | WO | 00 | 7/23/2012 |
Publishing Document | Publishing Date | Country | Kind |
---|---|---|---|
WO2011/072429 | 6/23/2011 | WO | A |
Number | Name | Date | Kind |
---|---|---|---|
7990912 | Nix et al. | Aug 2011 | B2 |
20050117554 | Bleckert et al. | Jun 2005 | A1 |
20080220779 | Bose | Sep 2008 | A1 |
20090047945 | Zhang et al. | Feb 2009 | A1 |
20090061924 | Morrill et al. | Mar 2009 | A1 |
20090129349 | Osborn | May 2009 | A1 |
20090286512 | Huber et al. | Nov 2009 | A1 |
20100016022 | Liu et al. | Jan 2010 | A1 |
20100304712 | Sweeney et al. | Dec 2010 | A1 |
20110124361 | Hosono et al. | May 2011 | A1 |
20110207461 | Lundqvist et al. | Aug 2011 | A1 |
20110292890 | Kulkarni et al. | Dec 2011 | A1 |
20120028629 | Liu et al. | Feb 2012 | A1 |
20120208504 | Song et al. | Aug 2012 | A1 |
20120252423 | Brisebois et al. | Oct 2012 | A1 |
20120264418 | Lee et al. | Oct 2012 | A1 |
Number | Date | Country |
---|---|---|
1625908 | Jun 2005 | CN |
WO 0217665 | Feb 2002 | WO |
WO 2009106790 | Sep 2009 | WO |
Entry |
---|
3GPPS 2.220 V9.1.1, “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Service Requirements for Home NodeBs and Home eNodeBs (Release 9)”, Jun. 2009, pp. 1-22. |
3GPP TS 33.320 V1.0.0, “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3GPP Security Aspect of Home NodeB and Home eNodeB; Release 9”, Sep. 2009, pp. 1-29. |
3GPP TS 32.583 V9.0.0, “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication Management; Home Node B (HNB) Operations, Administration, Maintenance and Provisioning (OAM&P); Procedure Flows for Type 1 Interface HNB to HNB Management System (HMS) (Release 9)”, Jun. 2009, pp. 1-21. |
3GPPS TS 32.593 V1.0.0, “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication Management; Home eNode B (HeNB) Operations, Administration, Maintenance and Provisioning (OAM&P); Procedure Flows for Type 1 Interface HeNB to HeNB Management System (Release 9)”, Sep. 2009, pp. 1-19. |
International Search Report and Written Opinion corresponding to International Patent Application No. PCT/CN2009/001496, dated Sep. 23, 2010. |
Number | Date | Country | |
---|---|---|---|
20120282900 A1 | Nov 2012 | US |