Hello,
I want to use the local sims having different MNC/MCC for implementing GPRS
using osmocoms with OpenBTS same as I have used them for GSM calls and sms
using only openBTS. But your site
http://openbsc.osmocom.org/trac/wiki/OpenBSC_GPRS says, "it is currently
not possible". As it is long when posted on this site so I want to ask is
it possible *now* to use the local sims? Hope you have understood my
question. Waiting for your reply. Thanks.
Regards,
Saba Arshad
This series of patches supports Incremental redundency for EGPRS DL case.
These patches have been integration tested on Nuran 1.0 for EGPRS MCS 9 support
in DL. And in UL only MCS4 has been tested. The EGPRS testing has been done with
Browsing and Ping in DL with larger packet sizes(1500).
Aravind Sirsikar (4):
Add data structure for MCS change in Retx
Add Accessor functions for MCS change in Retx
Modify DL tbf flow for MCS change in Retx
Add test cases to support MCS change during Retx
src/gprs_coding_scheme.cpp | 36 ++++
src/gprs_coding_scheme.h | 27 ++-
src/gprs_ms.cpp | 5 +
src/gprs_ms.h | 1 +
src/rlc.h | 10 ++
src/tbf_dl.cpp | 41 +++--
tests/tbf/TbfTest.cpp | 224 +++++++++++++++++++++++++
tests/tbf/TbfTest.err | 397 ++++++++++++++++++++++++++++++++++++++++++++
tests/tbf/TbfTest.ok | 9 +
9 files changed, 737 insertions(+), 13 deletions(-)
--
1.7.9.5
Hi Harald,
Can you please let us know the commit version for osmo-pcu which has been verified for EGPRS functionality on Nuran 1.0 hardware.
We have been trying the latest commit 1aa75273025b033d17c1068369a7ba145d5c9f06 which does not work( no uplink data received yet).
Can you provide details of the hardware in which EGPRS functionality has been successfully verified.
Thanks,
Aravind Sirsikar
From: Max <msuraev(a)sysmocom.de>
Define automake variable for configure flags to be used while running
'make distcheck'. This should prevent additional vty tests from running
in readonly distcheck environment. Note: user can still break the build
by overriding this with DISTCHECK_CONFIGURE_FLAGS variable.
---
src/Makefile.am | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/Makefile.am b/src/Makefile.am
index 6428bef..487ef1d 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -19,6 +19,7 @@
#
AM_CPPFLAGS = $(STD_DEFINES_AND_INCLUDES) $(LIBOSMOCORE_CFLAGS) $(LIBOSMOGB_CFLAGS) $(LIBOSMOGSM_CFLAGS)
+AM_DISTCHECK_CONFIGURE_FLAGS="--enable-sysmocom-dsp=no"
if ENABLE_SYSMODSP
AM_CPPFLAGS += -DENABLE_SYSMODSP
--
2.8.1
Hello,
Thanks for your inputs. We are starting integration of NURAN 1.0 for CS , SMS and GPRS/ EGPRS. We would like to know the steps to bring up the board with all software elements .
We understand that osmo-bts/osmo-pcu and osmo-bsc will be cross compiled. As a first step we would like to know the details of cross compilation and tool chain to be used for osmo-bts / osmo-pcu and osmo-bsc .
Also in the test setup described at http://openbsc.osmocom.org/trac , we see that there are third party components like MSC , SGSN and GGSN mentioned. Let us know what components are used for sample integration test setup.
Regards
Prasad
-----Original Message-----
From: osmocom-net-gprs [mailto:osmocom-net-gprs-bounces@lists.osmocom.org] On Behalf Of Neels Hofmeyr
Sent: Monday, March 14, 2016 5:43 AM
To: Prasad Kaup <Prasad.Kaup(a)radisys.com>
Cc: osmocom-net-gprs(a)lists.osmocom.org; Yves Godin <Yves.Godin(a)nutaq.com>
Subject: Re: Regarding integration of NURAN L1 1.0
Hi Prasad,
AFAIK you need the header files with matching version number to your sysmoBTS's firmware version from http://git.sysmocom.de/sysmo-bts/layer1-api/
I'm a bit new on building osmo-bts myself, so I can't yet say precisely which ./configure options you need to pass; but do take a look at
./configure --help
Hope this helps...
~Neels
Hi again.
I'm still having problem really getting the sgsnemu and ggsn to talk to
each other. When I use 127.0.0.1 and 127.0.0.2 as the listen and remote for
the sgsnemu and 127.0.0.2 as listen and 127.0.0.0/24 as network in the ggsn
conf, the sgsnemu says "Received echo response Received create PDP context
response. IP address: 127.0.0.2" and then nothing happens. When using two
computers, one running ggsn and one sgsnemu with the ip-addresses as
192.168.1.14 and 192.168.1.11 respectively, the sgsnemu doesn't seem to get
connented. It prints out "idletime.tv_sec 3, idleTime.tv_usec 0" over and
over, and "Echo Request timed out". The picture attached is from wireshark
on the ggsn computer.
I lookt at the pcap you send and it looks like what I would like for my
setup.
You talk mentioned using symoBTS how much does it cost? And how long is a
delivery for it?
Regards
Terje Skow
2016-03-01 12:56 GMT+01:00 Terje Kristoffer Skow <terjeks(a)stud.ntnu.no>:
> Thank you very much!!
>
> I will have some work getting through this, but I recon I'll have some
> more questions later.
>
> Again thank you
>
> 2016-03-01 12:39 GMT+01:00 Neels Hofmeyr <nhofmeyr(a)sysmocom.de>:
>
>> On Tue, Mar 01, 2016 at 11:12:01AM +0100, Terje Kristoffer Hybbestad Skow
>> wrote:
>> > The "logfile /tmp/foo" did gave an error message saying "unrecognized
>> > option".
>>
>> It seems the logfile option was added on 2014-03-23 with commit
>> 9c0ff4fafe4276396125a52c89d36967566fe08c. It may make sense if you build
>> your osmocom stack from the git sources to benefit from the latest fixes.
>>
>> See http://git.osmocom.org, specifically you'd probably want to clone
>> and build
>>
>> git://git.osmocom.org/libosmocore
>> git://git.osmocom.org/openggsn
>>
>> The build steps being for example
>>
>> autoreconf -fi
>> ./configure
>> make
>> sudo make install
>>
>>
>> > I'm going to look at DNS packets going through a GGSN to try and find
>> ways
>> > to detect DNS tunnels, do you have any recommendations how to do this?
>> > I do not have the time or resources to use real UE's so I hope to
>> simulate
>> > it on a computer using VMs or something like that.
>>
>> > I have looked at this:
>> http://openbsc.osmocom.org/trac/wiki/OpenBSC_GPRS as
>>
>> The BTS is for communicating with a phone over the air interface. Abis and
>> osmo-nitb are used for voice calls only. The SGSN is needed for real
>> networks,
>> you should be fine with the sgsnemu. So all you need is sgsnemu and
>> openggsn.
>>
>> You want to figure out how to use the sgsnemu, starting with a route into
>> the
>> tunnel device that sgsnemu opens up. So you need to look at the 'ip route'
>> commands (if you're on linux). I guess you won't need VMs; granted, it
>> might
>> make it easier to avoid circular routes (to IP addresses that should only
>> be
>> seen on the GGSN side), but certainly not a necessary prerequisite.
>>
>> I tried to ping through the sgsnemu tunnel once but saw, as I mentioned,
>> that
>> the GGSN thwarts GTP messages without a proper context being created
>> first. It
>> shouldn't be too hard, but I haven't investigated further. So you'd want
>> to
>> understand the GTP Ctrl & User messages to setup a PGP context (TEIs and
>> stuff), and figure out how sgsnemu might make your life easier in that
>> regard.
>> You probably want to read ETSI 29.060 to figure out GTP:
>>
>> http://www.etsi.org/deliver/etsi_ts/129000_129099/129060/03.19.00_60/ts_129…
>> You may find attached pcap file interesting (open in wireshark and note
>> that
>> the DNS queries are transmitted over GTP between SGSN and GGSN even though
>> wireshark tends to show only the DNS and src/dest enclosed in the GTP).
>> And again, you may look at
>> http://git.osmocom.org/openbsc/tree/openbsc/tests/gtphub/gtphub_test.c
>> about simplistic code examples of composing a PGP context conversation.
>>
>> If you'd like any more answers to questions you didn't ask ;)
>> just give us a shout...
>>
>> ~Neels
>>
>> --
>> - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
>> =======================================================================
>> * sysmocom - systems for mobile communications GmbH
>> * Alt-Moabit 93
>> * 10559 Berlin, Germany
>> * Sitz / Registered office: Berlin, HRB 134158 B
>> * Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte
>>
>
>
Parameters are added to the structure ph_rach_ind_param to
differentiate the type of RACH received from Layer 1. This is to
further support the 11 bit RACH.
---
include/osmocom/gsm/l1sap.h | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/include/osmocom/gsm/l1sap.h b/include/osmocom/gsm/l1sap.h
index 1af8ba8..d7bd172 100644
--- a/include/osmocom/gsm/l1sap.h
+++ b/include/osmocom/gsm/l1sap.h
@@ -44,12 +44,21 @@ struct ph_rach_req_param {
uint16_t offset; /*!< \brief Timing Offset */
};
+/*! \brief for PH_RA_IND burstType inforamtion */
+enum ph_burst_type {
+ GSM_L1_BURST_TYPE_ACCESS_0 = 4,
+ GSM_L1_BURST_TYPE_ACCESS_1,
+ GSM_L1_BURST_TYPE_ACCESS_2
+};
+
/*! \brief for PH-RANDOM_ACCESS.ind */
struct ph_rach_ind_param {
uint8_t chan_nr; /*!< \brief Channel Number (Like RSL) */
- uint8_t ra; /*!< \brief Random Access */
+ uint16_t ra; /*!< \brief Random Access */
uint8_t acc_delay; /*!< \brief Delay in bit periods */
uint32_t fn; /*!< \brief GSM Frame Number at time of RA */
+ uint8_t is_11bit; /*!< \brief no.of bits in RACH*/
+ enum ph_burst_type burst; /*!< \brief type of burst*/
};
/*! \brief for PH-[UNIT]DATA.{req,ind} | PH-RTS.ind */
--
2.5.0