Internet DRAFT - draft-xie-tictoc-femtocell-analysis

draft-xie-tictoc-femtocell-analysis






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]