E1 based BTS use TRAU muxer to decode TRAU frames. After changing
channel from one timeslot to another (due to handover or assignment),
the TRAU muxer must be updated. The call reference of the call is
disconnected from the old channel and connected to the new channel.
---
openbsc/include/openbsc/gsm_data.h | 14 ++++++++++++++
openbsc/include/openbsc/trau_mux.h | 3 +++
openbsc/src/libbsc/bsc_api.c | 5 +++++
openbsc/src/libbsc/handover_logic.c | 7 +++++--
openbsc/src/libmsc/gsm_04_08.c | 19 ++++++++++++++++---
openbsc/src/libtrau/trau_mux.c | 18 ++++++++++++++++++
6 files changed, 61 insertions(+), 5 deletions(-)
diff --git a/openbsc/include/openbsc/gsm_data.h b/openbsc/include/openbsc/gsm_data.h
index 7c3ca84..41fe328 100644
--- a/openbsc/include/openbsc/gsm_data.h
+++ b/openbsc/include/openbsc/gsm_data.h
@@ -382,6 +382,20 @@ static inline int is_nokia_bts(struct gsm_bts *bts)
return 0;
}
+static inline int is_e1_bts(struct gsm_bts *bts)
+{
+ switch (bts->type) {
+ case GSM_BTS_TYPE_BS11:
+ case GSM_BTS_TYPE_RBS2000:
+ case GSM_BTS_TYPE_NOKIA_SITE:
+ return 1;
+ default:
+ break;
+ }
+
+ return 0;
+}
+
enum gsm_auth_policy gsm_auth_policy_parse(const char *arg);
const char *gsm_auth_policy_name(enum gsm_auth_policy policy);
diff --git a/openbsc/include/openbsc/trau_mux.h b/openbsc/include/openbsc/trau_mux.h
index 3de50f7..d211d8d 100644
--- a/openbsc/include/openbsc/trau_mux.h
+++ b/openbsc/include/openbsc/trau_mux.h
@@ -51,6 +51,9 @@ int trau_recv_lchan(struct gsm_lchan *lchan, uint32_t callref);
/* send trau from application */
int trau_send_frame(struct gsm_lchan *lchan, struct gsm_data_frame *frame);
+/* switch trau muxer to new lchan */
+int switch_trau_mux(struct gsm_lchan *old_lchan, struct gsm_lchan *new_lchan);
+
/* callback invoked if we receive TRAU frames */
int subch_cb(struct subch_demux *dmx, int ch, uint8_t *data, int len, void *_priv);
diff --git a/openbsc/src/libbsc/bsc_api.c b/openbsc/src/libbsc/bsc_api.c
index 86d2493..e567038 100644
--- a/openbsc/src/libbsc/bsc_api.c
+++ b/openbsc/src/libbsc/bsc_api.c
@@ -31,6 +31,7 @@
#include <openbsc/handover.h>
#include <openbsc/debug.h>
#include <openbsc/gsm_04_08.h>
+#include <openbsc/trau_mux.h>
#include <osmocom/gsm/protocol/gsm_08_08.h>
@@ -419,6 +420,10 @@ static void handle_ass_compl(struct gsm_subscriber_connection *conn,
return;
}
+ /* switch TRAU muxer for E1 based BTS from one channel to another */
+ if (is_e1_bts(conn->bts))
+ switch_trau_mux(conn->lchan, conn->secondary_lchan);
+
/* swap channels */
osmo_timer_del(&conn->T10);
diff --git a/openbsc/src/libbsc/handover_logic.c b/openbsc/src/libbsc/handover_logic.c
index 9cf26af..36a758b 100644
--- a/openbsc/src/libbsc/handover_logic.c
+++ b/openbsc/src/libbsc/handover_logic.c
@@ -39,6 +39,7 @@
#include <openbsc/signal.h>
#include <osmocom/core/talloc.h>
#include <openbsc/transaction.h>
+#include <openbsc/trau_mux.h>
struct bsc_handover {
struct llist_head list;
@@ -264,6 +265,10 @@ static int ho_gsm48_ho_compl(struct gsm_lchan *new_lchan)
osmo_timer_del(&ho->T3103);
+ /* switch TRAU muxer for E1 based BTS from one channel to another */
+ if (is_e1_bts(new_lchan->conn->bts))
+ switch_trau_mux(ho->old_lchan, new_lchan);
+
/* Replace the ho lchan with the primary one */
if (ho->old_lchan != new_lchan->conn->lchan)
LOGP(DHO, LOGL_ERROR, "Primary lchan changed during handover.\n");
@@ -278,8 +283,6 @@ static int ho_gsm48_ho_compl(struct gsm_lchan *new_lchan)
rsl_lchan_set_state(ho->old_lchan, LCHAN_S_INACTIVE);
lchan_release(ho->old_lchan, 0, RSL_REL_LOCAL_END);
- /* do something to re-route the actual speech frames ! */
-
llist_del(&ho->list);
talloc_free(ho);
diff --git a/openbsc/src/libmsc/gsm_04_08.c b/openbsc/src/libmsc/gsm_04_08.c
index 0c6b100..bc4a9c3 100644
--- a/openbsc/src/libmsc/gsm_04_08.c
+++ b/openbsc/src/libmsc/gsm_04_08.c
@@ -1648,6 +1648,9 @@ static int tch_recv_mncc(struct gsm_network *net, uint32_t callref, int enable)
lchan = trans->conn->lchan;
bts = lchan->ts->trx->bts;
+ /* store receive state */
+ trans->tch_recv = enable;
+
switch (bts->type) {
case GSM_BTS_TYPE_NANOBTS:
case GSM_BTS_TYPE_OSMO_SYSMO:
@@ -1655,10 +1658,12 @@ static int tch_recv_mncc(struct gsm_network *net, uint32_t callref, int enable)
LOGP(DCC, LOGL_ERROR, "Error: RTP proxy is disabled\n");
return -EINVAL;
}
- /* in case, we don't have a RTP socket yet, we note this
- * in the transaction and try later */
+ /* In case, we don't have a RTP socket to the BTS yet, the BTS
+ * will not be connected to our RTP proxy and the socket will
+ * not be assigned to the application interface. This method
+ * will be called again, once the audio socket is created and
+ * connected. */
if (!lchan->abis_ip.rtp_socket) {
- trans->tch_recv = enable;
DEBUGP(DCC, "queue tch_recv_mncc request (%d)\n", enable);
return 0;
}
@@ -1677,6 +1682,14 @@ static int tch_recv_mncc(struct gsm_network *net, uint32_t callref, int enable)
case GSM_BTS_TYPE_BS11:
case GSM_BTS_TYPE_RBS2000:
case GSM_BTS_TYPE_NOKIA_SITE:
+ /* In case we don't have a TCH with correct mode, the TRAU muxer
+ * will not be asigned to the application interface. This is
+ * performed by switch_trau_mux() after successful handover or
+ * assignment. */
+ if (lchan->tch_mode == GSM48_CMODE_SIGN) {
+ DEBUGP(DCC, "queue tch_recv_mncc request (%d)\n", enable);
+ return 0;
+ }
if (enable)
return trau_recv_lchan(lchan, callref);
return trau_mux_unmap(NULL, callref);
diff --git a/openbsc/src/libtrau/trau_mux.c b/openbsc/src/libtrau/trau_mux.c
index c9d77cf..7b9bac0 100644
--- a/openbsc/src/libtrau/trau_mux.c
+++ b/openbsc/src/libtrau/trau_mux.c
@@ -31,6 +31,7 @@
#include <osmocom/core/talloc.h>
#include <openbsc/trau_upqueue.h>
#include <osmocom/core/crcgen.h>
+#include <openbsc/transaction.h>
/* this corresponds to the bit-lengths of the individual codec
* parameters as indicated in Table 1.1 of TS 06.10 */
@@ -518,3 +519,20 @@ int trau_send_frame(struct gsm_lchan *lchan, struct gsm_data_frame *frame)
return subchan_mux_enqueue(mx, dst_e1_ss->e1_ts_ss, trau_bits_out,
TRAU_FRAME_BITS);
}
+
+/* switch trau muxer to new lchan */
+int switch_trau_mux(struct gsm_lchan *old_lchan, struct gsm_lchan *new_lchan)
+{
+ struct gsm_network *net = old_lchan->ts->trx->bts->network;
+ struct gsm_trans *trans;
+
+ /* look up transaction with TCH frame receive enabled */
+ llist_for_each_entry(trans, &net->trans_list, entry) {
+ if (trans->conn && trans->conn->lchan == old_lchan && trans->tch_recv) {
+ /* switch */
+ trau_recv_lchan(new_lchan, trans->callref);
+ }
+ }
+
+ return 0;
+}
--
1.8.1.5
--------------080108050203060401030404--
The implementation of for_each_line is based on strtok() and skips
any sequence of CR and LF. Thus empty lines are never detected. There
exists code which tests for an empty line to detect the beginning of
the SDP part which is dead code currently (the parser works
nevertheless due to other reasons). So the semantics of this macro
have been misunderstood at least once.
This patch renames the macro to reflect the semantics more precisely.
Sponsored-by: On-Waves ehf
---
openbsc/src/libmgcp/mgcp_protocol.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/openbsc/src/libmgcp/mgcp_protocol.c b/openbsc/src/libmgcp/mgcp_protocol.c
index 7096495..c040ab1 100644
--- a/openbsc/src/libmgcp/mgcp_protocol.c
+++ b/openbsc/src/libmgcp/mgcp_protocol.c
@@ -36,7 +36,7 @@
#include <openbsc/mgcp.h>
#include <openbsc/mgcp_internal.h>
-#define for_each_line(line, save) \
+#define for_each_non_empty_line(line, save) \
for (line = strtok_r(NULL, "\r\n", &save); line;\
line = strtok_r(NULL, "\r\n", &save))
@@ -527,7 +527,7 @@ static struct msgb *handle_create_con(struct mgcp_parse_data *p)
return create_err_response(NULL, 510, "CRCX", p->trans);
/* parse CallID C: and LocalParameters L: */
- for_each_line(line, p->save) {
+ for_each_non_empty_line(line, p->save) {
switch (line[0]) {
case 'L':
local_options = (const char *) line + 3;
@@ -652,7 +652,7 @@ static struct msgb *handle_modify_con(struct mgcp_parse_data *p)
return create_err_response(endp, 400, "MDCX", p->trans);
}
- for_each_line(line, p->save) {
+ for_each_non_empty_line(line, p->save) {
switch (line[0]) {
case 'C': {
if (verify_call_id(endp, line + 3) != 0)
@@ -771,7 +771,7 @@ static struct msgb *handle_delete_con(struct mgcp_parse_data *p)
return create_err_response(endp, 400, "DLCX", p->trans);
}
- for_each_line(line, p->save) {
+ for_each_non_empty_line(line, p->save) {
switch (line[0]) {
case 'C':
if (verify_call_id(endp, line + 3) != 0)
@@ -873,7 +873,7 @@ static struct msgb *handle_noti_req(struct mgcp_parse_data *p)
if (p->found != 0)
return create_err_response(NULL, 400, "RQNT", p->trans);
- for_each_line(line, p->save) {
+ for_each_non_empty_line(line, p->save) {
switch (line[0]) {
case 'S':
tone = extract_tone(line);
@@ -1218,7 +1218,7 @@ int mgcp_parse_stats(struct msgb *msg, uint32_t *ps, uint32_t *os,
return -1;
/* this can only parse the message that is created above... */
- for_each_line(line, save) {
+ for_each_non_empty_line(line, save) {
switch (line[0]) {
case 'P':
rc = sscanf(line, "P: PS=%u, OS=%u, PR=%u, OR=%u, PL=%d, JI=%u",
--
1.7.9.5
Hello,
I'm working on producing a graphic which shows Osmocom projects that
can be used in a production GSM network, along with related projects
that are used together with these. I'd also like to show these in the
context of legacy networks, e.g. with existing BSC and MSC etc.
First, I need to be sure I have the complete list:
— Osmocom
* BSC (or much more): OpenBSC (osmo-bsc or NITB)
* BTS: OsmoBTS + sysmoBTS or osmo-trx/UmTRX in Fairwaves solution
* PCU: osmo-pcu
* SGSN: OsmoSGSN
* GGSN: OpenGGSN
* ??: cellmgr_ng (what would be the best use cases to show? E.g. as in
bsc_nat diagram)
* ??: bsc_nat (show as in diagram on wiki? Perhaps with fewer elements...)
* ??: osmo-gbproxy
Not sure about the status of osmocom-lcs?
— Ecosystem (supporting projects)
* Linux Call Router
* FreeSWITCH
* Telscale SS7 card (for interfacing with legacy networks)
— Legacy
* nanoBTS and others
* BSC
* MSC
* ... ?
The idea would be to try and show as many use cases as is reasonably
possible and without making the graphic a mess.
I'd appreciate any comments and suggestions folks may have.
Cheers,
Andrew
--
Andrew Back
http://carrierdetect.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hey there,
I have come across a nanoBTS 165AU but since is used and not tested from the previous owner, I guess it has set a static IP.
After turned on is booting (RED light) and then remains (ORANGE not flashing) even if the eth is connected to the router.
At the moment I am trying with ipaccess-find and BtsInstaller to find in on my LAN .
Unfortunately it is not answering and is not even getting an IP from the router by the DHCP daemon.
Two possibilities, I have thought:
- - an hw/sw issue;
- - a Static IP is set.
Supposing that is the 2nd possibility, I was thinking:
- - to change private class of my LAN, to see if it changes something;
- - to make an hard reset of the bts.
Do you know if it possible to reset in someway?
Ever happened this issue to you guys?
Suggestions or insults are welcome.
Thanks in advance.
Cheers,
Luca
P.S.: I don't recall exactly, but one time I heard that is possible to reset by short-circuiting some pins of the LAN/48VDC eth connector. Is it right?!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
iQIcBAEBAgAGBQJSE682AAoJEPLE1Qsi6ZiTuKkQAJaYGFTgMF5XlWuZuCI1eSvU
lVCvpdB+fDRY7o6iut3y0fGlS1ZOIS8X93c7/T0XKUvSJaZ2ARIGjqi81A4XlkAK
pdFvBNPKixYATYZYhP3nIggC1QGK9fuWQSUKVEGgnswsXt0VaJKdEwgn0CX7ttku
uoh6FM3vtp30drB4t9oe0bW9M9qzGz6yyw+8asaqQBs8bafOHm4+S4kJsN6lYmPU
wY/s8ctzqZerNI0MwBVASZCFldsyWe0NuduquYZlwg4god996srFNkVQL+o9nrmF
vmPb896DTsCdivwqs+UyaZOgp1mKxjtfco275pVATG4qSAgz/JYQBxWK6fWQr+Zv
PIzQvFLME1kh/29nUihxw93mzju5Rz1naTosx5+Fs7jPjCFocqD5Var3hkU4iu78
kNALJNx6UGOdfbqcInO30ltSm21HH1QBJnIoZf6MblELvHcvHbBNyPB8zM13suoS
y3/oD/wcXefQaMaSa5HFc30ydJHBWS+adNlVp3fdYYArZaVkFxaVjJx8fW1juPVx
54aco5j7/tZD5tfg9FCOTHqmAiOVDqjs7nZrOpsRdkdPJHq2uHbGmHGqyhZlVWNv
B+9/eiOdQyKZ5R+3vvRrmhBe9g2a28xtRI7N8KxwCov0wbA6R0h8l2UtGza6NTcn
EUdW3ptIWP216tSFdVTs
=9Ctc
-----END PGP SIGNATURE-----
Hi,
I am working on my Diploma thesis , which topic is GPRS Emulation software. This project is based on your OsmoBTS project . The idea is to delete/replace the hw-related primitives and features and redirect the whole traffic to the osmocomBB with modifications – this is the work of my colleague .
1st point: My intention is to implement gprs part only. I have analyzed the BTS codes(especially Master, Jolly/l1sap_parts and Jolly/Trx ), i dont know which one will be most suitable to use, but I think the jolly/trx or jolly/l1sap_parts common part will be probably best choise . It implements more common functions in l1sap interface compared to the Master code . Am I right ?
2nd point: I have analyzed the common code, and it is look like the main logic of the PCU(from the BTS side) is implemented in pcu_sock.c and l1sap.c , where the l1sap implements the message parsing and sending to the l1_if of the BTS , and also initializes gsmtap messages . So what I want to do is to create another socket application to connect with osmocomBB(with additional gprs implementation) , which will send/receive the BTS messages from l1sap through our custom "l1 interface" to the osmocomBB phone("how simple") . The PCU part looks, that would not need any intervention. What do you think ?
The hardest part will be to achieve , the application will be able to run witout HW (in the case of TRX branch , the bts will be able to connect to "transmiter" ). Since i am now standing on the crossroad, i need advice to make the right discision . Any suggestions and comments are highly appreciated.
Best Regards,
Dominik Tamaskovic
Hi list
I'm hacking a protocol that runs inside Huawei SCP, in between USAU
(signaling gateway within IN) and SCP node itself.
There is a small file at my disposal (few megs), to study. Unfortunately
there is no way to run a trace at the other side of USAU in parallel, so
need to guess about fields.
Here is the typical IDP found with my guestimations
000000a7 - packet length
0000feab - packet ID
00a1 - length of remained portion
1000 - (***) protocol type, 0x1000 is similar to CAMEL, other protocols are
{0100,0200,0300,0400,0500,0600,1000,1200,1300,1400,1500,1700}
01d6f100 - transaction ID
01d6f100
01ff - msg type and direction, 01FF - IDP, where FF means that it goes from
gsmSCP to gsmSCP, response is 0100
0000010000000000 - something unknown, some messages may have non-zero
values here
8c - length
30 81 - tag+len, something like IDP args
89 8001 01
82 08 84 90 xxxxxxxxxxxx - A pty, MSISDN
83 08 84 13 xxxxxxxxxxxx - B pty, MSISDN
85 01 0a
88 04 00000000
8a 04 84 13 xxxx - E.164 country code
bb 05 80038090a3
9c 01 0c
9f32 08 xxxxxxxxxxxxxxxx - IMSI (A)
bf33 02 8000
bf34 - a tag that assumes no length/value
22 02 0159
80 08 1000000000000000
81 08 91 xxxxxxxxxxxxxxx - GT of MSC(ssf)
a3 09 8007 xxxxxxxxxxxxxx location number ?
bf35 03 830111
9f36 05 207a77c430
9f37 08 91 xxxxxxxxxxxxxx - GT of MSC(ssf)
9f39 08 xxxxxxxxxxxxxxxx - some number in unknown format (neither
E.164 nor E.212)
a-pty MSISDN may be alternatively coded with 9F38 tag
The most tricky thing is to decode another protocol types (marked with ***
above) that are not so obvious
My final goal is to decode both CAP portion and amount of credit available
Is there anybody who faced similar task or who can provide additional
traces.. or can even make some traces?
An ideal case is to perform SS7 and USAU trace in parallel.
Or even has some papers on this topic
Regards,
Dmitri Soloviev