Project

General

Profile

Feature #4574

Femtocell choice in 2020/06

Added by copslock about 1 month ago. Updated about 10 hours ago.

Status:
New
Priority:
Low
Assignee:
-
Target version:
-
Start date:
06/01/2020
Due date:
% Done:

0%

Spec Reference:

Description

Recently the AT&T had shutdown its UMTS femto system,thus,result in the Cisco femtocells that operated in their network are widely available on eBay or Amazon platform,it turned out to be the DPH-151/153/154 microcell,But as the Harald noticed,these units are communicated through the Cisco URSL protocal,which is the evolution of the current 2G RSL signaling,and possible someone can add UMTS patch to it.So far it's the best available femtocell rather than the ip.access one.

brkagg-2002 .pdf View brkagg-2002 .pdf 2.03 MB Cisco femto architecture 2009 copslock, 06/02/2020 02:46 PM
att_microcell.png View att_microcell.png 1.19 MB copslock, 06/17/2020 09:06 AM
femto_new.jpg View femto_new.jpg 1.89 MB Jarobar, 07/04/2020 12:15 PM
4205
4216

History

#1 Updated by laforge about 1 month ago

AFAICT, URSL was originally developed by ip.access for the early version of their "oyster3g" femtocells. Cisco had later acquired/licensed that from ip.access. At least for the ip.access oyster3g, only early firmware versions were USRL, later on they moved to standard Iuh. maybe the same is true for the cisco devices you are looking at?

In any case, USRL is a completely different protocol, so if you wanted to support it, you would have to write a IuCS+IuPS to USRL converter. Given that URSL uses no RANAP, this is likely a much more complex task than the comparatively simple osmo-hnbgw.

#2 Updated by copslock about 1 month ago

laforge wrote:

AFAICT, URSL was originally developed by ip.access for the early version of their "oyster3g" femtocells. Cisco had later acquired/licensed that from ip.access. At least for the ip.access oyster3g, only early firmware versions were USRL, later on they moved to standard Iuh. maybe the same is true for the cisco devices you are looking at?

In any case, USRL is a completely different protocol, so if you wanted to support it, you would have to write a IuCS+IuPS to USRL converter. Given that URSL uses no RANAP, this is likely a much more complex task than the comparatively simple osmo-hnbgw.

Thank you for reply,Harald,had you tried to reverse-engineering these models before?As far as I know the presentation of Cisco in 2009 showed that it used the URSL stack,but in the later the ASR5000 PPTs showed it seems like support the standard Iuh interface.But don't know whether if these femtocells using the newer Iuh interface.The AT&T may had some modification.There is only one way to verify that,I have just ordered some units from eBay to find this out,if it's based on standard IuH interface,It will be much better choice than the long-disappered ip.access nano3g femotocells.By the way,I'm thinking about the support of ethernet-CPRI RRHs which is much more widely available than the eNodeBs and very chip.don't know whether if its fast enough for x86 to process those real-time I/Q data.

#3 Updated by laforge about 1 month ago

On Tue, Jun 02, 2020 at 02:46:49PM +0000, copslock [REDMINE] wrote:

Thank you for reply,Harald,had you tried to reverse-engineering these models before?

I once played with an Oyster3G, found out some details about URSL and then gave up, as
it's simply too far away from 3GPP stanards.

As far as I know the presentation of Cisco in 2009 showed that it used the URSL stack,but in the later the ASR5000 PPTs showed it seems like support the standard Iuh interface.But don't know whether if these femtocells using the newer Iuh interface.

I guess unless you find different software versions for your specific cell, it is impossible to know.

The AT&T may had some modification.There is only one way to verify that,I have just ordered some units from eBay to find this out,if it's based on standard IuH interface,It will be much better choice than the long-disappered ip.access nano3g femotocells.By the way,

I'm thinking about the support of ethernet-CPRI RRHs which is much
more widely available than the eNodeBs and very chip.

The problem is mainly:
  • you have to design build a CPRI physical interface card (FGPA, gateware, host drivers, ...)
  • you have to reverse engineer the proprietary, verdor/product-specific Command+Control

don't know whether if its fast enough for x86 to process those real-time I/Q data.

For sure it is possible, look at what Amarisoft is doing. It's not open
source, but they do have CPRI interface board and complete eNB / gNB in
x86 software.

#4 Updated by copslock about 1 month ago

laforge wrote:

On Tue, Jun 02, 2020 at 02:46:49PM +0000, copslock [REDMINE] wrote:

Thank you for reply,Harald,had you tried to reverse-engineering these models before?

I once played with an Oyster3G, found out some details about URSL and then gave up, as
it's simply too far away from 3GPP stanards.

As far as I know the presentation of Cisco in 2009 showed that it used the URSL stack,but in the later the ASR5000 PPTs showed it seems like support the standard Iuh interface.But don't know whether if these femtocells using the newer Iuh interface.

I guess unless you find different software versions for your specific cell, it is impossible to know.

The AT&T may had some modification.There is only one way to verify that,I have just ordered some units from eBay to find this out,if it's based on standard IuH interface,It will be much better choice than the long-disappered ip.access nano3g femotocells.By the way,

I'm thinking about the support of ethernet-CPRI RRHs which is much
more widely available than the eNodeBs and very chip.

The problem is mainly:
  • you have to design build a CPRI physical interface card (FGPA, gateware, host drivers, ...)
  • you have to reverse engineer the proprietary, verdor/product-specific Command+Control

don't know whether if its fast enough for x86 to process those real-time I/Q data.

For sure it is possible, look at what Amarisoft is doing. It's not open
source, but they do have CPRI interface board and complete eNB / gNB in
x86 software.

I mean some RRHs running on the ethernet interface,and possible CPRI data capsulated in ethernet frame,and can we just using the basic PC ethernet card to communicate with the RRH?I think it might have some issue like real-time I/Q data compressing because i saw FPGA-like stuff on its board,but still it at least runs on the ethernet interface

#5 Updated by copslock 18 days ago

laforge wrote:

On Tue, Jun 02, 2020 at 02:46:49PM +0000, copslock [REDMINE] wrote:

Thank you for reply,Harald,had you tried to reverse-engineering these models before?

I once played with an Oyster3G, found out some details about URSL and then gave up, as
it's simply too far away from 3GPP stanards.

As far as I know the presentation of Cisco in 2009 showed that it used the URSL stack,but in the later the ASR5000 PPTs showed it seems like support the standard Iuh interface.But don't know whether if these femtocells using the newer Iuh interface.

I guess unless you find different software versions for your specific cell, it is impossible to know.

The AT&T may had some modification.There is only one way to verify that,I have just ordered some units from eBay to find this out,if it's based on standard IuH interface,It will be much better choice than the long-disappered ip.access nano3g femotocells.By the way,

I'm thinking about the support of ethernet-CPRI RRHs which is much
more widely available than the eNodeBs and very chip.

The problem is mainly:
  • you have to design build a CPRI physical interface card (FGPA, gateware, host drivers, ...)
  • you have to reverse engineer the proprietary, verdor/product-specific Command+Control

don't know whether if its fast enough for x86 to process those real-time I/Q data.

For sure it is possible, look at what Amarisoft is doing. It's not open
source, but they do have CPRI interface board and complete eNB / gNB in
x86 software.

Long wait before the internation package arrive,but i found something interesting,some engs used to work with the AT&T and Cisco has described it

@Small Cell Test and Verification Engineer (contractor) for ip.access/Cisco
ip.access
Jan 2012 – Jun 2012 6 months

Redmond, WA

• Perform End2End testing of the ip.access/Cisco 3G Microcell solution in AT&T’s test bed according to the Test Object List as agreed with the customer;
• This testing was focused around HNB RAN (i.e. MM, Cell_FACH, CSG, HSPA, Admission and Power Control, Multi-RAB, Handover, etc.) and HNB-GW (IP Sec, HNBAP, RUA, HA, Iu-Flex, etc.) validation including related Statistics, KPIs and Alarms.@

What's the "Iu-Flex"???Maybe another some properitary blob again

#6 Updated by copslock 18 days ago

4205

Long wait before the internation package arrive,but i found something interesting,some engs used to work with the AT&T and Cisco has described it

@Small Cell Test and Verification Engineer (contractor) for ip.access/Cisco
ip.access
Jan 2012 – Jun 2012 6 months

Redmond, WA

• Perform End2End testing of the ip.access/Cisco 3G Microcell solution in AT&T’s test bed according to the Test Object List as agreed with the customer;
• This testing was focused around HNB RAN (i.e. MM, Cell_FACH, CSG, HSPA, Admission and Power Control, Multi-RAB, Handover, etc.) and HNB-GW (IP Sec, HNBAP, RUA, HA, Iu-Flex, etc.) validation including related Statistics, KPIs and Alarms.@

What's the "Iu-Flex"???Maybe another some properitary blob again,why ip.access called it "Oyster 3G"

#7 Updated by laforge 18 days ago

On Wed, Jun 17, 2020 at 09:06:53AM +0000, copslock [REDMINE] wrote:

What's the "Iu-Flex"???

As somewhat more dynamic/flexible/scalable way of handling the Iu interface between
RNC/HNBGW and MSC/SGSN. You should find it described in 3GPP specs. Not ip.access specific
at all.

why ip.access called it "Oyster 3G"

Because of the shape of the device? The original nanoBTS for GSM were called "rugby"

#8 Updated by Jarobar about 21 hours ago

4216

Hi
I disassembled the DPH153-AT unit. Caution the device contains anti-tampering jumpers!
I did not know about them. I can not turn it on now, otherwise the flash will be erased. Is the position of the jumpers the same for all units or is it dependent on the MAC / SN?
Would anyone be willing to tell me the correct jumpers position?
My unit is newer version.

#9 Updated by copslock about 10 hours ago

Jarobar wrote:

Hi
I disassembled the DPH153-AT unit. Caution the device contains anti-tampering jumpers!
I did not know about them. I can not turn it on now, otherwise the flash will be erased. Is the position of the jumpers the same for all units or is it dependent on the MAC / SN?

Oh my god,i guess you guys already well-acknowaged that the 151/153 have anti-tamper jumpers,i saw some tips about the jumpers before but i didnt sure whether if its random,i will take another look

Would anyone be willing to tell me the correct jumpers position?
My unit is newer version.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)