I just picked up this IPAccess model which supports band 2/5 and has the
same housing as the other units on the accelerate3g5 project docs. I've
been pouring over docs and trying a lot of network configurations in my
home lab. I have the login information for the factory reset and can access
the web gui on port 8089 during the reset process, but ssh and telnet DMI
seem to be disabled. I've been fuzzing ports and i've tried static as well
as DHCP for IP addresses.
My thought was that if i point the nano3G to the IP of my osmo-hNodeB
machine that it would at least stimulate the device and maybe i'd see some
log messages in the HNodeB gateway, but so far i haven't seen anything in
the logs. i've also tried abisip-find and that doesn't find anything.
Wireshark shows basic 'who has' Layer 2 messages and also DHCP requests
sent to 0.0.0.0, both from the nano3g. The nano3g does get an ip from my
lab router and i can ping it. The LAN behind that router can also access
the 0.ipaccess ntp server, but again no telnet DMI or ssh so i'm unsure
where to go from here.
Layer 1 seems to show nothing on the uarfcn in the web gui, so it seems
that its not crossing all the right bridges.
I will admit, i haven't run any other osmo network components for the
network, but as far as i was reading the home nodeb and ntp should be the
only things necessary to at least start the process.
Any insight on what to try next would be very helpful. Does anyone have
experience with this model?
thanks
Hi Osmocom,
May I ask if we have similar feature of auto provisioning of subscribers who are trying to camp to the network similar to auth-policy accept-all in osmo-nitb? Is the new version supports also the auto provisioning of subscribers?
Regards,
Justin Mark Repollo
Hello, im Using a default configuration for my osmo-bsc setup using B210. I
managed to get a working amplifier with specifications below.
My question is, what should be the best config that i should use in order
to maximize tge power and range of my amplifier?
What are the best configs for osmo-trx, osmo-bts, and other applications
related to osmo-bsc. Proper settings such as osmotrx tx-attenuation,
nominal power, ms max power and other related configurations that are valid
or matched for my amplifier.
Listed below is my amplifier's specification.
AMPLIFIER SPECS:
band:
uplink 885-915MHz / downlink 930-960MHz
Max output power: downlink 47±1dBm
Max allow input power:
uplink -10dBm / downlink +10dBm
gain:
Uplink 25±2dB
Downlink 28 to 53±1dB
ALC:
Uplink ≥10dB
Downlink ≥10dB
SWR:
Uplink ≤1.5
Downlink ≤1.5
Passband ripple:
Uplink ≤2dB
Downlink ≤2dB
Noise floor:
uplink ≤2dB
third order intermodulation:
Uplink ≤-55dBc@-8dBm/ch/2ch
Downlink ≤-36dBc@2ch
Voltage:
28V
Currency:
≤4.5A
Thanks a lot!
Henry
Hello all,
We trying to bring up set of BTS with virtual Um with different configurations:
1 BTS -> 1 TRX -> 1 MS works fine as expected
1 BTS -> 1 TRX -> 2 MS works fine as well
But I see some unpredictable behaviour when I have
1 BTS -> 2 TRX(872,873) -> 1 MS
MS can attach on one ARFCN (872) but when it tries to attach on 873
looks like PRACH does not reach BTS and I do not see Channel Request
on BSC side.
So, the question is it workable configuration:
Several TRX to 1 MS with different power level to allow MS to choose a
best cell to attach?
I have just one idea: to have several virtphy instances for MS
connected to different UDP ports.
Thank you
Vania
Hi All,
I was again looking at advancing with LCLS support.
I've made a couple of proposals, which at least get it to the stage
where the global call reference it consistent from the A leg to B leg of
a call, with both the internal mncc and external, and therefore
osmo-bsc can make use of either the lcls-mode (mgw|bts)-loop.
The implementation in the osmo-sip-connector doing nothing more than
passing the GCR from leg to leg, but it's more complicated than this.
We need to allow the PBX to have the audio streams until the PBX itself
decides to remove itself from the stream. (as it is you won't even hear
ringback)
I know all this is spec-ed somewhere in LCLS, I'm just not sure
where/how this SIP re-INVITE processing should be implemented, in the
sip conn, or the MSC - which I guess, takes us back again to neels' long
standing proposals for parsing SDP inside the MSC. Maybe it' s time to
get that merged.
Anyway.. I have some time scheduled to try to move this forward towards
a definitive solution, just writing here in case anyone else can help.
Thanks.
k/
