TICTOC L. Xie Internet-Draft M. Ouellette Intended status: Informational Huawei Technologies Expires: January 6, 2010 July 5, 2009 Femtocell synchronization analysis draft-xie-tictoc-femtocell-analysis-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 6, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Xie & Ouellette Expires January 6, 2010 [Page 1] Internet-Draft Femtocell synchronization July 2009 Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document analyses the aspect of providing synchronization to cellular femtocells. It discusses some challenges that should be considered during the development of TICTOC application requirements and network architecture. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology used in this document . . . . . . . . . . . . . . . 3 3. Femtocell synchronization implementation . . . . . . . . . . . 3 3.1. Synchronization security analysis . . . . . . . . . . . . . 5 3.2. NAT analysis . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. scalability analysis . . . . . . . . . . . . . . . . . . . 7 4. Femtocell synchronization requirements consideration . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Xie & Ouellette Expires January 6, 2010 [Page 2] Internet-Draft Femtocell synchronization July 2009 1. Introduction A femtocell is defined as a base station for deployment in residential market environments and is typically connected to the mobile core network via a public broadband connection (eg., DSL modem, cable modem). There are advantages for a mobile operator in deploying femtocells, with two of them being: 1. Improve cellular network coverage thereby offering higher customer satisfaction. The femtocell extends network coverage and delivers high-quality mobile services inside residential and business buildings. 2. Cost saving to operators, by reducing the macrocell traffic load and offloading it over public broadband connections to the mobile operator!_s core network. This can potentially reduce the cost and complexity of having to deploy higher-capacity links to the macrocell. Just like a typical macrocell (large base station), femtocells (residential base stations) require a certain level of synchronization (frequency or phase/time) on the air interface, predominantly frequency requirements. The 3GPP and Femtocell Forum have produced a set of recommendations dealing with many technical aspects of femtocell environments. This document analyses the aspect of providing network synchronization to femtocells and discusses some challenges that should be considered during the development of TICTOC application requirements and network architecture. This document provides an initial discussion around femtocell synchronization and is by no means exhaustive. 2. Terminology used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Femtocell synchronization implementation The [3GPP.23.830] technical report defines some of the high-level network architecture aspects of a Home NodeB (3G UMTS) and a Home eNodeB (4G LTE). In addition, the Femto Forum organization also provides a network reference model very similar to 3GPP. Both architectures have commonalities as illustrated in Figure 1. Xie & Ouellette Expires January 6, 2010 [Page 3] Internet-Draft Femtocell synchronization July 2009 +-------------+ +--------+ | | | | | Femtocell |--------------|Home GW |<-----+ | | | | | +-------------+ +--------+ | | | /---------------------\ | | | Public Network | | | \---------------------/ | | +------------+ +-------------+ | |Clock Server|---------->| | | +------------+ | | | | Security GW |->---+ +------------+ | | |Femto GW |---------->| | +------------+ +-------------+ Figure 1. Typical Architecture of a Femtocell Network The femtocell network architecture shows that a public network is used to establish the connectivity between the femtocell and core network elements (eg., Security Gateway, Femto Gateway, Clock server, etc.). With respect to sync, the femtocell will therefore see some synchronization messages being transported over the public network (e.g, Internet). This presents a set of unique challenges for operators. One challenge involves the security aspects of such an architecture. In both reference models, the communication between the femtocell and Femto Gateway is secured by a mandatory Security Gateway function. The Security Gateway may be implemented either as a separate physical entity or integrated into other network elements. The security is mandatory since the Gateway and Clock server communicate to the femtocells via a public backhaul broadband connection (also known as the 3GPP iuh interface or Femto Forum Fa interface). The security can be accomplished by instantiating an IPSec tunnel between the Femto gateway and femtocell. Another aspect involves the deployment of femtocells behind residential gateway (Home GW) functionalities, as shown in Figure 1. Xie & Ouellette Expires January 6, 2010 [Page 4] Internet-Draft Femtocell synchronization July 2009 The Home GW provides Internet sharing for home devices, such as laptop, video telephone, network appliances and femtocells. One of the challenges is to define the end-to-end connectivity model between the femtocell and clock server when a function such as network address translation (NAT) is present within the Home GW. NAT is a popular technology for sharing the Internet resources in residential networks. However, NAT breaks the direct connectivity between femtocell and core network elements, in particular with the Clock Server. Therefore, there must be some mechanism put in place to guarantee that synchronization messages between the Clock Server and femtocell are properly exchanged and are not impacted by such functionality. Another aspect involves the scalability and size of the femtocell network. For instance, the femtocell network could easily extend to millions of devices and the offered load of synchronization messages (bandwidth consumption) could become quite large when unicast addressing is used. This could impact the clock server throughput but more importantly could increase the difficultly in capacity planning and placement of clock servers in the network. The use of multicast technologies such as [RFC5501] and [IEEE 802.1aq] currently being developed might present opportunities to considerably reduce the offered load of synchronization messages into the network. 3.1. Synchronization security analysis Normally, a Clock Server is to be located in an independent network (trusted network) and accessed via the Security Gateway. Therefore, the Clock Server typically resides in the private network of the operator and communication between Clock Servers (if there are multiple servers) is typically assumed secured. As Figure 1 showed, the communication between the Clock Server itself and the femtocell is done through a public network but is protected by a Security Gateway (eg., using IPSec). The 3GPP has considered some of the security aspects with respect to synchronization performance. The [3GPP.33.820] report lists the following: 1. it may be possible to leave some of the messages unprotected, but there might be security risks. Care should be taken in considering which messages are protection or not. 2. there may be bandwidth, delay and delay variation problems if all the messages (eg., [IEEE1588]) are to be protected. 3. if delays become excessively long, reliance on internal clock might be important and requires further investigation. Other important points worth noting with respect to security is the large number of femtocells that might have to be served, as well as the additional bandwidth overhead IPSec represents to the offered load (bandwidth consumption) of synchronization messages. Xie & Ouellette Expires January 6, 2010 [Page 5] Internet-Draft Femtocell synchronization July 2009 3.2. NAT analysis In a real implementation, the Femtocell might be co-located or integrated with a residential gateway (Home Gateway). The Femto Forum has defined the Fl interface as the interface that connects the femtocell to the Home Gateway. The Home Gateway might provide functions such as network address translation (NAT) between the devices sitting in the home and the public network. This protects the internal home network, but prevents the direct connection between devices sitting in the home network and devices that are outside (reachable through the public Internet). With respect to synchronization, this could limit the ability of a femtocell to communicate directly to a Clock server. Therefore, some mechanism to handle NAT translation and to guarantee proper flow of synchronization messages should be provided. Figure2 presents a high-level example on how to address such challenge. +-------------+ +--------+ +------------+ +-------------+ | | | | | | | | | Femtocell |----|Home GW |<------>|Security GW |-----|Clock Server | | | | | | | | | +-------------+ +--------+ +------------+ +-------------+ | | | | | | | | | | establish IPSec | | | | Tunnel | | |<--------------|------------------>| | | | | | | | 1 Sync Request | | |---------------|-------------------|------------------>| | | | | | | | | | | 2 Sync Response | | |<--------------|-------------------|-------------------| | | | | | | | | | | 3 message with | | | | time packets | | |<--------------|-------------------|-------------------| | | | | | | | | Figure 2 Establishing synchronization connection through NAT In Figure 2, the Femtocell builds the IPSec tunnel at first, and In IPSec tunnel some information, such as Femtocell's NAT port and public address are exchanged, after that, Femtocell wants to build Xie & Ouellette Expires January 6, 2010 [Page 6] Internet-Draft Femtocell synchronization July 2009 the connection outside the IPSec tunnel for massive number of message with time packets, then a Sync Request message is send to Clock Server with it Femtocell's identify ID, Clock Server checks the ID and send the Sync Response according to the recorded public address and NAT port to the Femtocell and then begins sending the message with time packets. In Figure 2, the femtocell initially builds an IPSec tunnel between the femtocell and Security GW. Information such as the femtocell!_s NAT port and public IP addresses are exchanged. The information is used to build the connectivity between the Clock Server and Femtocell. Once the connectivity is established, the femtocell transmits a Sync Request message to the Clock server with, for instance, the femtocell's identifier ID. The clock server checks the identifier and replies back with a Sync Response according to the recorded public address and NAT port to the Femtocell (the detailed functions of NAT are omitted from this document and the reader is referred to [RFC1631] for more details). The Clock server then proceeds to transmit synchronization messages. 3.3. scalability analysis It is important for the proper deployment of a clock server to be capable of meeting large-scale femtocell environments in a cost- effective manner. The placement of clock servers for instance depends heavily on the network architecture, traffic engineering rules and the number of femtocells a clock server can support. The use of load balancing techniques might be beneficial to help in sync capacity planning but might impact performance. As mentioned above, the use of multicast technologies currently being developed might present opportunities to reduce the bandwidth consumption of synchronization messages and to considerably increase the number of femtocells a server can support. 4. Femtocell synchronization requirements consideration This draft presented some initial challenges related to synchronization in a femtocell environment. The content of this draft and the following summarized points should be considered by TICTOC to help further define the application requirements and network architecture: 1. The use of IPSec links in public networks could degrade the transport of synchronization message and its performance. In order to reduce the impact of security issue in public networks, it is possible to leave some of the synchronization messages unprotected. Caution should take place on the use of IPSec and sync performance. Xie & Ouellette Expires January 6, 2010 [Page 7] Internet-Draft Femtocell synchronization July 2009 2. Synchronization messages traversing Network Address Translation (NAT) functions need to be considered, in order to guarantee proper connectivity between a Clock Server and femtocell. 3. Scalability aspects (large number of femtocells), bandwidth consumption and the placement of clock servers are important as the network architecture is developed. 4. The use of multicast technologies currently being developed might present opportunities to reduce the bandwidth consumption of synchronization messages and to considerably increase the number of femtocells a server can support. 5. Aspects of using multicast and IPSec. 6. Aspects involving the QoS treatment and traffic management of synchronization messages. 7. If TICTOC intends to develop some form of synchronization profile covering mobile backhaul for instance, then the aspects of femtocell should be taken into account. 5. Security Considerations Security in femtocell environments relates to the transport of synchronization messages over a public network (eg., Internet) that contains secured links (eg., IPSec) and the impact it might have on performance. In addition, the security aspects listed in [I-D.rodrigues-lindqvist-tictoc-req] may also be applicable to the femtocell environment. 6. IANA Considerations There have been no IANA considerations so far in this document. 7. Acknowledgments The authors appreciate the valuable work and contribution done to this document by Xu Xiao and Peter Ashwood-Smith. 8. References 8.1. Normative References [RFC1631] Egevang, K. and P. Francis, "The IP Network Address Translator (NAT)", RFC 1631, May 1994. Xie & Ouellette Expires January 6, 2010 [Page 8] Internet-Draft Femtocell synchronization July 2009 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5501] Kamite, Y., Wada, Y., Serbest, Y., Morin, T., and L. Fang, "Requirements for Multicast Support in Virtual Private LAN Services", RFC 5501, March 2009. 8.2. Informative References [3GPP.23.830] 3GPP, "Architecture aspects of Home Node B (HNB) / Home enhanced Node B (HeNB)", 3GPP TR 23.830 0.5.0, June 2009. [3GPP.33.820] 3GPP, "Security of Home Node B (HNB) / Home evolved Node B (HeNB)", 3GPP TR 33.820 8.1.0, June 2009. [I-D.rodrigues-lindqvist-tictoc-req] Rodrigues, S. and K. Lindqvist, "TICTOC Requirement", draft-rodrigues-lindqvist-tictoc-req-02 (work in progress), March 2009. [IEEE 802.1aq] IEEE, "Virtual Bridged Local Area Networks "C Amendment 9: Shortest Path Bridging", Draft 2.0 June 2009. [IEEE1588] IEEE, "Standard for A Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", IEEE Std 1588-2008. Authors' Addresses Lei Xie Huawei Technologies Huawei Building, Xinxi Road No.3 Haidian District, Beijing 100085 P. R. China Phone: +86-10-82836301 Email: xielei57471@huawei.com Xie & Ouellette Expires January 6, 2010 [Page 9] Internet-Draft Femtocell synchronization July 2009 Michel Ouellette Huawei Technologies 411 Legget Drive, 5th Floor Ottawa, Ontario K2K3C9 Canada Phone: +1-613-595-1900 Email: michel.ouellette@huawei.com Xie & Ouellette Expires January 6, 2010 [Page 10]