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
Hello All,
We are currently working on providing the support of 11 bit RACH support in osmoPCU as mentioned in Bug #1548 at https://projects.osmocom.org/projects/osmopcu/issues
We have identified impacts to be in osmo-pcu, osmo-bts and osmocore
Main changes identified are
osmo-pcu:
* In file pcuif_proto.h, modify "uint8_t ra" to "uint16_t ra" in struct gsm_pcu_if_rach_ind
* Corresponding function prototypes due to change in data type
* 11 bit RACH handling in bts.cpp
* Changes in encoding.cpp to support immediate assignment with EGPRS allocation
osmocore:
* In file l1sap.h, modify "uint8_t ra" to "uint16_t ra" in structure "struct ph_rach_ind_param"
* Function prototype changes
osmobts:
* Function prototype changes due to change in data type
Please let us know your valuable feedback.
We plan to have a separate branch from master for this development. Please let us know the procedure to do this.
Regards
Prasad
Hello Max,
Though I have not analyzed the missing UL poll response, few of my observations from the pcap file attached is mentioned below
1. There seems to be difference in FN UL versus DL being processed at any given time by the order of approx. 10 FNs, example given below
a. Packet 7174 , FN 1137361 in DL @ 15:33:22.511809393
b. Packet 7190, FN 1137361 in UL @ 15:33:22.559427972
c. From above example difference in time is 48milliseconds or approx.. 10FN duration
2. For processing DL timeslots 2 to 6 at any given DL FN time taken seems to be approx. 3milliseconds, example given below
a. Packet 7174 , FN 1137361 in DL @ 15:33:22.511809393 for TS 2
b. Packet 7178, FN 1137361 in DL @ 15:33:22.514310379 for TS 6
Please let me know if these are known behavior in your integration environment ?
These time variations may have an impact on the poll response behavior from MS as well.
Regards
Saurabh
-----Original Message-----
From: Max [mailto:msuraev@sysmocom.de]
Sent: Thursday, February 25, 2016 3:58 PM
To: osmocom-net-gprs(a)lists.osmocom.org; Saurabh Sharan <Saurabh.Sharan(a)radisys.com>
Subject: PCU scheduling and PACCH timeout question
Hello.
I'm trying to debug issue with current OsmoPCU master when some basebands ignore polling requests.
The debug output from RLCMAC layer and corresponding .pcap files are attached.
The issue appears somewhere after line 112 in debug.log The corresponding packet in pcu.pcapng is 6866
After receiving PACKET_CONTROL_ACK from phone we're trying to schedule polling at FN 1137123 (see packet 6869 in pcap) and than at FN 1137127 (packet 6874) which subsequently fails.
This seems suspiciously close but I have not found in the spec yet if this is legitimate thing to do.
There are several other occurrences like that in both log and pcap.
Have you experienced something like this? Do you have an idea why only some basebands are affected while others work fine?
--
Max Suraev <msuraev(a)sysmocom.de<mailto:msuraev@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
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
Hi
Does this mailinglist also regard openGGSN?
If so do I have some questions. I have problem setting it up correctly.
Does anyone have a configuration file for both ggsn and sgsnemu that works?
Which flags are necessary to use and what should they be set to? I
understand it can differ based on IP addresses and similar, but can someone
please help? I'm using this program for my master thesis.
Regards
Terje Kristoffer H. Skow
Hello All,
We are currently working on providing the support of 11 bit RACH support in osmoPCU as mentioned in Bug #1548 at https://projects.osmocom.org/projects/osmopcu/issues
We have identified impacts to be in osmo-pcu, osmo-bts and osmocore
Main changes identified are
osmo-pcu:
* In file pcuif_proto.h, modify "uint8_t ra" to "uint16_t ra" in struct gsm_pcu_if_rach_ind
* Corresponding function prototypes due to change in data type
* 11 bit RACH handling in bts.cpp
* Changes in encoding.cpp to support immediate assignment with EGPRS allocation
osmocore:
* In file l1sap.h, modify "uint8_t ra" to "uint16_t ra" in structure "struct ph_rach_ind_param"
* Function prototype changes
osmobts:
* Function prototype changes due to change in data type
Please let us know your valuable feedback.
We plan to have a separate branch from master for this development. Please let us know the procedure to do this.
Regards
Prasad
Hello All,
We are currently working on providing the support of 11 bit RACH support in osmoPCU as mentioned in Bug #1548 at https://projects.osmocom.org/projects/osmopcu/issues
We have identified impacts to be in osmo-pcu, osmo-bts and osmocore
Main changes identified are
osmo-pcu:
* In file pcuif_proto.h, modify "uint8_t ra" to "uint16_t ra" in struct gsm_pcu_if_rach_ind
* Corresponding function prototypes due to change in data type
* 11 bit RACH handling in bts.cpp
* Changes in encoding.cpp to support immediate assignment with EGPRS allocation
osmocore:
* In file l1sap.h, modify "uint8_t ra" to "uint16_t ra" in structure "struct ph_rach_ind_param"
* Function prototype changes
osmobts:
* Function prototype changes due to change in data type
Please let us know your valuable feedback.
We plan to have a separate branch from master for this development. Please let us know the procedure to do this.
Regards
Prasad
Hello.
I'm trying to debug issue with current OsmoPCU master when some
basebands ignore polling requests.
The debug output from RLCMAC layer and corresponding .pcap files are
attached to ticket http://projects.osmocom.org/issues/1524
The issue appears somewhere after line 112 in debug.log
The corresponding packet in pcu.pcapng is 6866
After receiving PACKET_CONTROL_ACK from phone we're trying to schedule
polling at FN 1137123 (see packet 6869 in pcap) and than at FN 1137127
(packet 6874) which subsequently fails.
This seems suspiciously close but I have not found in the spec yet if
this is legitimate thing to do.
There are several other occurrences like that in both log and pcap.
Have you experienced something like this? Do you have an idea why only
some basebands are affected while others work fine?
--
Max Suraev <msuraev(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
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
Hello All,
We are currently working on providing the support of FANR in osmoPCU. We are in design phase and will share the design details soon.
Please provide your valuable feedback on the design.
Regards
Saurabh
Hello All,
We would like to provide the information that since Dec-2015 we have been working on adding the EGPRS support in OsmoPCU. We have provided the support for Basic EGPRS feature, details of which explained below.
We would like to make the code available in Public domain so that we receive the feedback from all and upon approval would contribute to the master branch.
Following are the features added:
1) EGPRS MCS 1 to MCS 9 coding scheme support
2) Radio Link Control Block Structure Updates
3) MCS Selection
4) Transmission and reception data flows for MCS1 to MCS9
5) EGPRS incremental redundancy (IR) mode, RLC function
6) EGPRS Window selection
7) RLC Re-segmentation and split block support
8) RLC retransmission based on coding families A, A', B and C
We have taken interim rebase from the master during Jan-2016.
Regards,
Saurabh
Hi everybody,
we have just done the first download of an Internet page using the
current bleeding EDGE development version of the OSMO-PCU. Supported are
MCS-1 to MCS-9 in downlink and MCS-1 to MCS-4 in uplink direction.
The download of 'www.osmocom.org' has been documented in a PCAP file and
can be downloaded from
https://openbsc.osmocom.org/trac/wiki/osmo-pcu
To decode the data blocks, an experimental patch for the gsmtab
dissector is also available from there.
Cheers
Jacob
--
- Jacob Erlbeck <jerlbeck(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
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
From: Daniel Willmann <daniel(a)totalueberwachung.de>
Hello,
it seems PDP context updates was never really used/tested to an Update PDP
context would not go through. The following patches fix that (at least for
gtpv1).
Regards
Daniel
Daniel Willmann (3):
gtp: Pass pdp along when calling gtp_req() in gtp_update_context()
gtp: Make gtp_update_pdp_conf() work for gtp0 and gtp1 connections
gtp: Handle gtpv1 in gtp_update_pdp_conf() correctly
gtp/gtp.c | 162 +++++++++++++++++++++++++++++++++++++++++++++-----------------
1 file changed, 118 insertions(+), 44 deletions(-)
--
2.1.4
--
- Daniel Willmann <dwillmann(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
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte