Subject: [TICTOC] FW: Adding the Femto Synchronization requirments in requirement document

From: Yaakov Stein <[email-masked]>
Date: Wed, 26 Aug 2009 14:36:50 +0300

From: Xie Lei<mailto:[email-masked]>
To: [email-masked]<mailto:[email-masked]>
Sent: Wednesday, August 26, 2009 9:50 AM
Subject: [TICTOC] Adding the Femto Synchronization requirments in requirement document

Dear All
As the agreement in IETF75# meeting, we decide to add the femto synchronization requirements in requirement document. After checking the requirement document, i think, the best way is to add a new section as following:

3.2.1 Cellular Backhauling of Femtocells

Femtocell application may use a portion of the public and private network infrastructure to provide connectivity and backhaul service between the femtocell device and gateway. The use of a public network facility implies that some level of network security is necessary, as compared to the scenarios presented in Section 3.1.1.x which assumed that the connectivity and backhaul service is done over a private network (eg., see Note (2)), typically for macrocell application. In addition the number of femtocell devices can easily extend to hundreds of thousands, much higher than the number of macrocells. The following requirements should be considered for femtocell deployments:

 1.  The use of IPSec links in the public network could degrade the transport of synchronization message and its performance. In order to reduce the impact to synchronization when traversing secured links, it is possible to leave some of the synchronization message unprotected. Caution should take place on the use of IPSec and synchronization performance
 2.  Synchronization messages traversing Network Address Translation (NAT) functions need to be considered in order to guarantee proper connectivity between a Clock Server and the femtocell device
 3.  Scalability aspects (large number of femtocells), bandwidth consumption of synchronization messages and the placement of clock servers are to be considered as the network architecture is developed.
Please give your comments on these words, Thanks

Best Regards
Rock

---

From: "Stefano Ruffini" <[email-masked]>
Date: Fri, 28 Aug 2009 13:20:32 +0200

Hi Yaakov, 
 
I would suggests few updates to your proposals also based on some comments that were made in Stockholm on this subject:
 
1. The femtocells application can be based on one of the technologies already mentioned in 3.1.1 (and in fact the 250 ppb requirement which is related to home base stations, which is the way 3GPP calls the femtocell,  is already mentioned in this section).
 In order to avoid misunderstanding,  the new section  could be called 3.1.2, "Specific aspects related to Femtocells application". 
Some rephrasing in the introductory text might also be needed (e.g. remove "presented in Section 3.1.1.x " as scenarios that assume private network).
The Notes related to "Private Networks" could be updated as follows:
Note 2: assumes a private network, (this may not be true in case of femtocells)
 
2. The first point on IPSEC is based on still quite vague considerations (no real study or test has been presented on this topic showing the actual degradation). I would suggest to be more generic ,  for instance saying that the impacts on performances due to IPSEC are under study.
 
3. Regarding alternative solution to IPSEC perhaps rather than refer to "secure links" (which in case needs to be clarified), it seems more appropriate to refer to existing solutions (e.g. built in authentication)
 
The above comments would results in updating the text as follows:
"
 
3.1 Cellular Backhauling
...
3.1.1 Cellular Backhauling Requirements
.....
 
3.1.2 Specific aspects related to the Femtocells application

Femtocell application may use a portion of the public and private network infrastructure to provide connectivity and backhaul service between the femtocell device and gateway. The use of a public network facility implies that some level of network security is necessary, as compared to the scenarios which assume that the connectivity and backhaul service is done over a private network (eg., see Note (2)), typically for macrocell application. In addition the number of femtocell devices can easily extend to hundreds of thousands, much higher than the number of macrocells. The following requirements should be considered for femtocell deployments:

1.	The impact of the use of IPSec links in the public network on the transport of synchronization message and its performance is under study. Alternative means to guarantee that timing messages are securely delivered to the femtocells base stations might be considered (e.g. built in authentication). 
2.	Synchronization messages traversing Network Address Translation (NAT) functions need to be considered in order to guarantee proper connectivity between a Clock Server and the femtocell device 
3.	Scalability aspects (large number of femtocells), bandwidth consumption of synchronization messages and the placement of clock servers are to be considered as the network architecture is developed.

3.1.3 Cellular Backhaul Requirements Summary
...
"
 
Best Regards
Stefano
 
________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of Yaakov Stein
Sent: mercoledì 26 agosto 2009 13.37
To: [email-masked]
Subject: [TICTOC] FW: Adding the Femto Synchronization requirments in requirement document

From: Xie Lei <mailto:[email-masked]>  

To: [email-masked] 

  

Dear All

 

Best Regards

Rock

---

From: Yaakov Stein <[email-masked]>
Date: Mon, 31 Aug 2009 14:07:09 +0300

Stefano

I like your idea of treating femtocells by adding a new subsection.

Note that while the Iuh interface indeed has important security considerations,
the Iub interface is also almost always encrypted. In any case, the important issue
here is to note the security requirements.

The middlebox issue is an important one, which needs to be noted.

There will also be different scalability concerns, as a FGW needs to handle
many more femtocells than an RNC needs to handle NodeBs.

Y(J)S

From: Stefano Ruffini [mailto:[email-masked]]
Sent: Friday, August 28, 2009 14:21
To: Yaakov Stein; [email-masked]
Subject: RE: [TICTOC] FW: Adding the Femto Synchronization requirments in requirement document

Hi Yaakov,

3.1 Cellular Backhauling
...

Best Regards
Stefano

Dear All

Best Regards
Rock

---

From: Danny Mayer <[email-masked]>
Date: Mon, 31 Aug 2009 22:44:24 -0400

Yaakov Stein wrote:
> *From:* Xie Lei <mailto:[email-masked]>
> 
> *To:* [email-masked] <mailto:[email-masked]>
> 
> *Sent:* Wednesday, August 26, 2009 9:50 AM
> 
> *Subject:* [TICTOC] Adding the Femto Synchronization requirments in
> requirement document
> 
>  
> 
>  
> 
> Dear All
> 
> As the agreement in IETF75# meeting, we decide to add the femto
> synchronization requirements in requirement document. After checking the
> requirement document, i think, the best way is to add a new section as
> following:
> 
> Femtocell application may use a portion of the public and private
> network infrastructure to provide connectivity and backhaul service
> between the femtocell device and gateway. The use of a public network
> facility implies that some level of network security is necessary, as
> compared to the scenarios presented in Section 3.1.1.x which assumed
> that the connectivity and backhaul service is done over a private
> network (eg., see Note (2)), typically for macrocell application. In
> addition the number of femtocell devices can easily extend to hundreds
> of thousands, much higher than the number of macrocells. The following
> requirements should be considered for femtocell deployments:
> 
>    1. The use of IPSec links in the public network could degrade the
>       transport of synchronization message and its performance. In order
>       to reduce the impact to synchronization when traversing secured
>       links, it is possible to leave some of the synchronization message
>       unprotected. Caution should take place on the use of IPSec and
>       synchronization performance

The use of IPSec *will* degrade any NTP packet and I don't expect that
any TICTOC packet will be able to do better over IPSec. There is also
the issue of the security part requiring each end to have accurate time
in the first place defeats the purpose of this.

>    2. Synchronization messages traversing Network Address Translation
>       (NAT) functions need to be considered in order to guarantee proper
>       connectivity between a Clock Server and the femtocell device

NAT destroys the capability of any possibility of verifying the IP
address of the sender. You need to disallow NAT devices or provide
another way of passing the packets through the device.

>    3. Scalability aspects (large number of femtocells), bandwidth
>       consumption of synchronization messages and the placement of clock
>       servers are to be considered as the network architecture is
>       developed.
> 

NTP seems to have no problens with scalability so I cannot imagine what
new issue would arise that what be any different.

Danny

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.