AgeCommit message (Collapse)AuthorFilesLines
2018-12-19LCLS: log config/control updateMax1-2/+6
Change-Id: Iac493014144ca0e5e1a83081e6e01ea7910deac2
2018-12-18LCLS: update parameter representationMax3-21/+15
* use osmo_lcls struct from libosmocore * use enum values instead of magic numbers Change-Id: I5e962d4fbb24bf1fb2398dc13e142a4a3304d858 Related: OS#3659
2018-12-14Add VTY option to avoid sending empty Full BCCH Info for disabled SIPau Espin Pedrol4-6/+50
According to 3GPP TS 08.58 ยง8.5.1 BCCH INFORMATION: "If the Full BCCH information element is not included this indicates that transmission of the indicated SYSTEM INFORMATION message shall be stopped." However, some ipaccess nanoBTS firmware versions are known to not support some SI elements and also to dislike receiving BCCH Information for those SI, even if received with empty BCCH Information meaning they should not be used. Upon receival of this kind of message, nanoBTS sends a Failure Report with following text: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=l2_bch.c:1149 **** ** l2_bch.c#1149:BCHbcchSItypeValid( prim_p->infoType ) ** IPA_SW_FATAL_ERROR ** In task "TRX Proc:L2_BCH" @ (325). **** This kind of issue only appears with some fw versions, since it's known to work fine in other ones, so let's not disable this kind of mesage by default on all BTs of type "nanobts". Instead, add a VTY command that allows disabling this kind of message in order to be able to operate those nanoBTS units. Fixes: OS#3707 Change-Id: Idec1daabc21de4eea5c55edd1dbb0e0775720fc7
2018-12-12bsc: bssap: Set subscr log context during pagingPau Espin Pedrol1-2/+8
Change-Id: I3998a35ff6ea29440882514bbb30cafed66f03fa
2018-12-11bsc: dtap: Set subscr log contextPau Espin Pedrol2-3/+11
Change-Id: I362a7d10f5ca9a95b594f7caafd7ed5b10fd059a
2018-12-11bsc: rsl: Set subscr log context during meas reportPau Espin Pedrol1-3/+9
Change-Id: Idc6af592e870d15491797ae6fcaffaac2b411766
2018-12-11bsc: Set subscr log context during complete_layer3Pau Espin Pedrol1-10/+16
Change-Id: I162a474f711248a3f64a0438967fa6f8a9a3e686
2018-12-11bsc_main: filter_fn: Compare imsi values instead of subscr pointersPau Espin Pedrol1-2/+5
Since we actually want to match by IMSI as specified by filter in VTY. It will allow to match based on other information later. Change-Id: Ia73fd2f38e42396db8f6d2cc6b2c163aa8f67f3f
2018-12-11paging: Properly enclose logging imsi filter scopePau Espin Pedrol1-0/+3
Otherwise all logging is kept enabled after passing through those code paths. Change-Id: I06a977d97e6ffea02ec7402d48410c0e7cc6c155
2018-12-11VTY: Allow logging filter imsi statements for IMSIs we haven't seen yetDaniel Willmann1-2/+8
Limiting the logging filter only to IMSIs that we have as local subscriber doesn't make sense for osmo-bsc since all subscribers are initially unknown. Create a bsc subscriber and enable logging there. This struct will then be used and liked to the gsm_subscr_conn when receiving the Location update. Related: OS#3641 Change-Id: Ia20bdc15565417020205d7b2b06b04a01c03106c
2018-12-11paging: fix whitespacePau Espin Pedrol1-1/+1
Change-Id: I81c4a9f0dbd708df27a485ef764c9524a36d548a
2018-12-09set gscon FSM instances' log level to DEBUGNeels Hofmeyr1-1/+1
Currently, we see all subscribers' FSM transitions on NOTICE level even though the code uses LOGPFSML(LOGL_DEBUG), because LOGPFSML() uses the max loglevel of the passed level and the FSM instance's level. Too noisy! By default, start out all gscon FSM instances on DEBUG level, so it is possible to silence the osmo-bsc log. Individual instances can still be lifted (I presume using the CTRL interface?). Change-Id: Ie021483e93ab174abac51357bcca8895756566c4
2018-12-07handover_fsm: send HANDOVER PERFORMED msg on internal hoPhilipp Maier2-0/+69
When an internal handover is done the specification demands to inform the MSC about the event. - Add sending of BSSMAP HANDOVER PERFORMED msg. Change-Id: If26e5807280e0f75a423b3b04f8e3c698c82a351 Depends: libosmocore I825106858bd89afc9837811b8fed2e8accc82441 Related: OS#3645
2018-12-06gsm_04_08: Free GSM subscr conn if paging response can't be matchedDaniel Willmann1-1/+1
The current idea of calling gscon_release_lchans is not enough because the conn is still present. Insetad pretend we got a disconnect indication from the MSC which will call gscon_release_lchans as well as terminate the conn state machine which will clean up conn state as well. Related: OS#3680 Change-Id: Iccf5f6864ffe238189907c4bb3ea333948621b4c
2018-12-06contrib: fix makedistcheck with disabled systemdOliver Smith1-1/+2
EXTRA_DIST files need to be distributed, no matter if the systemd option is configured or not. Change-Id: Ide5de9383a2a3b957d182dca1187f73dbf1ce982
2018-12-05paging: Add VTY options to calculate T3113 timeout dynamicallyPau Espin Pedrol7-4/+86
The idea is to have a base static value which is set like before "timer t3113 [seconds]", but now have a part of this timeout calculated dynamically based on BTS channel configuration and channel load. This patch only implements initial support to calculate based on channel configuration, but doesn't include code to calculate based on channel load. To implement the later part, we probably need to keep track of BTS paging queues per paging group, which we don't do nowadays. Dynamic calculation is enabled by default, and default static base value is decreased accordingly. This way, in a typical setup were the default 10 seconds were used, now the calculated final value is 11 seconds. That's intended because it was observed experimentally in osmo-gsm-tester with a similar channel setup that sometimes paging response can arrive slightly later than 10 seconds. Related: OS#3680 Change-Id: I4fb2969b690151415038631fb6ad059aa6835c7f
2018-12-05bsc: lchan_fsm: Fix invalid duplicated transitionPau Espin Pedrol1-1/+4
When we enter WAIT_RLL_RTP_RELEASED (lchan_fsm_wait_rll_rtp_released_onenter), we call lchan_do_release() which in turn dispatches LCHAN_RTP_EV_RELEASE to lchan_rtp_fsm.c, which will dispatch back an LCHAN_EV_RTP_RELEASED event, which will be handled by lchan_fsm_wait_rll_rtp_released(), which will change state to WAIT_BEFORE_RF_RELEASE. When going back the stack (return), we are still in lchan_fsm_wait_rll_rtp_released_onenter() which again triggers a change state to WAIT_BEFORE_RF_RELEASE because it checks same conditions than first one. 20181128203727051 DCHAN osmo-bsc/lchan_fsm.c:1388 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{ESTABLISHED}: lchan detaches from conn SUBSCR_CONN(conn3)[0x612000002da0] 20181128203727051 DMSC osmo-bsc/lchan_fsm.c:1391 SUBSCR_CONN(conn3)[0x612000002da0]{CLEARING}: lchan lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0] detaches from conn 20181128203727051 DCHAN osmo-bsc/lchan_fsm.c:1359 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{ESTABLISHED}: state_chg to WAIT_RLL_RTP_RELEASED 20181128203727052 DCHAN osmo-bsc/lchan_fsm.c:959 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{WAIT_RLL_RTP_RELEASED}: (type=TCH_F) SAPI[0] = 1 20181128203727052 DRR osmo-bsc/gsm_04_08_rr.c:254 Sending Channel Release: Chan: Number: 0 Type: 2 20181128203727052 DCHAN osmo-bsc/lchan_fsm.c:945 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x6120000027a0]{ESTABLISHED}: Received Event LCHAN_RTP_EV_RELEASE 20181128203727052 DCHAN osmo-bsc/lchan_rtp_fsm.c:572 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x6120000027a0]{ESTABLISHED}: Terminating (cause = OSMO_FSM_TERM_REGULAR) 20181128203727052 DCHAN osmo-bsc/lchan_rtp_fsm.c:572 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x6120000027a0]{ESTABLISHED}: Removing from parent lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0] 20181128203727052 DCHAN osmo-bsc/lchan_rtp_fsm.c:572 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x6120000027a0]{ESTABLISHED}: Freeing instance 20181128203727052 DCHAN fsm.c:381 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x6120000027a0]{ESTABLISHED}: Deallocated 20181128203727052 DCHAN osmo-bsc/lchan_rtp_fsm.c:572 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{WAIT_RLL_RTP_RELEASED}: Received Event LCHAN_EV_RTP_RELEASED 20181128203727052 DCHAN osmo-bsc/lchan_fsm.c:856 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{WAIT_RLL_RTP_RELEASED}: (type=TCH_F) Still active SAPIs: 0 20181128203727052 DCHAN osmo-bsc/lchan_fsm.c:1011 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{WAIT_RLL_RTP_RELEASED}: state_chg to WAIT_BEFORE_RF_RELEASE 20181128203727052 DRSL osmo-bsc/abis_rsl.c:633 (bts=0,trx=0,ts=6,ss=0) DEACTivate SACCH CMD 20181128203727052 DCHAN osmo-bsc/lchan_fsm.c:986 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{WAIT_BEFORE_RF_RELEASE}: transition to state WAIT_BEFORE_RF_RELEASE not permitted! Change-Id: I5d95bbd8244cc8e9c1cfb6fe0f76148332386a3d
2018-12-05bsc: timeslot_fsm: Handle and ignore tear down of lchan during PDCH DEACTPau Espin Pedrol1-0/+4
lchan sends TS_EV_LCHAN_UNUSED to its parent (ts) during release time. It was experimentally found that it can happen that an lchan can be terminated while waiting for a PDCH DEACT (N)ACK response. The fsm definition actually states that this event can be received in state TS_ST_WAIT_PDCH_DEACT, but it was not handled before and as a result the process aborted due to the default switch case. Change-Id: If61493e7d5449bf2c2de9fd34cdf2410625e92ac
2018-12-05bsc: lchan_fsm: Add missing transition WAIT_TS_READY->WAIT_RLL_RTP_RELEASEDPau Espin Pedrol1-0/+1
20181128193707326 DCHAN osmo-bsc/lchan_rtp_fsm.c:193 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x612000002320]{WAIT_MGW_ENDPOINT_AVAILABLE}: Freeing instance 20181128193707327 DCHAN fsm.c:381 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x612000002320]{WAIT_MGW_ENDPOINT_AVAILABLE}: Deallocated 20181128193707327 DCHAN osmo-bsc/lchan_rtp_fsm.c:193 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{WAIT_TS_READY}: Received Event LCHAN_EV_RTP_RELEASED 20181128193707330 DCHAN osmo-bsc/lchan_fsm.c:1347 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{WAIT_TS_READY}: transition to state WAIT_RLL_RTP_RELEASED not permitted! Change-Id: I43aab5ed8ac369869b191b3b7c938ce4985ab849
2018-12-05bsc: lchan_rtp_fsm: Avoid duplicate LCHAN_EV_RTP_RELEASED eventPau Espin Pedrol1-1/+5
When lchan_rtp_fsm instance is allcoated with osmo_fsm_inst_alloc_child(..., LCHAN_EV_RTP_RELEASED) we already let fsm code to take care of sending that event ito the parent when the fsm is terminated (but only if freeing cause is not OSMO_FSM_TERM_PARENT). The lchan_rtp_fsm cleanup() callback, which is called immediatelly before sending to the parent the event defined during osmo_gsm_install_alloc_child(), currently also sends that same event, which ends up in a duplicated event being sent as shown in log files below. Let's only send the event in cleanup() if we are in the cause=OSMO_FSM_TERM_PARENT scenario, to make sure parent always receives the event, but only once. 20181128193707326 DAS osmo-bsc/assignment_fsm.c:127 assignment(conn4_0-0-6-TCH_F_PDCHasPDCH-0)[0x6120000024a0]{WAIT_LCHAN_ACTIVE}: (bts=0,trx=0,ts=6,ss=0) Assignment failed 20181128193707326 DAS osmo-bsc/assignment_fsm.c:128 assignment(conn4_0-0-6-TCH_F_PDCHasPDCH-0)[0x6120000024a0]{WAIT_LCHAN_ACTIVE}: Terminating (cause = OSMO_FSM_TERM_ERROR) 20181128193707326 DAS osmo-bsc/assignment_fsm.c:128 assignment(conn4_0-0-6-TCH_F_PDCHasPDCH-0)[0x6120000024a0]{WAIT_LCHAN_ACTIVE}: Removing from parent SUBSCR_CONN(conn4)[0x612000002920] 20181128193707326 DCHAN osmo-bsc/lchan_fsm.c:1333 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x612000002320]{WAIT_MGW_ENDPOINT_AVAILABLE}: Received Event LCHAN_RTP_EV_ROLLBACK 20181128193707326 DCHAN osmo-bsc/lchan_rtp_fsm.c:193 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x612000002320]{WAIT_MGW_ENDPOINT_AVAILABLE}: Terminating (cause = OSMO_FSM_TERM_REQUEST) 20181128193707326 DCHAN osmo-bsc/lchan_rtp_fsm.c:193 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x612000002320]{WAIT_MGW_ENDPOINT_AVAILABLE}: Removing from parent lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0] 20181128193707326 DRSL osmo-bsc/mgw_endpoint_fsm.c:441 mgw-endpoint(conn4)[0x6120000021a0]{WAIT_MGW_RESPONSE}: (rtpbridge/*@mgw) CI[0] to-BTS: DLCX :0: notify=NULL 20181128193707326 DRSL osmo-bsc/mgw_endpoint_fsm.c:482 mgw-endpoint(conn4)[0x6120000021a0]{WAIT_MGW_RESPONSE}: (rtpbridge/*@mgw) CI[0] to-BTS: DLCX :0: Scheduling 20181128193707326 DCHAN osmo-bsc/lchan_rtp_fsm.c:742 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{WAIT_TS_READY}: Received Event LCHAN_EV_RTP_RELEASED 20181128193707326 DCHAN osmo-bsc/lchan_rtp_fsm.c:193 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x612000002320]{WAIT_MGW_ENDPOINT_AVAILABLE}: Freeing instance 20181128193707327 DCHAN fsm.c:381 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x612000002320]{WAIT_MGW_ENDPOINT_AVAILABLE}: Deallocated 20181128193707327 DCHAN osmo-bsc/lchan_rtp_fsm.c:193 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{WAIT_TS_READY}: Received Event LCHAN_EV_RTP_RELEASED 20181128193707330 DCHAN osmo-bsc/lchan_fsm.c:1347 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{WAIT_TS_READY}: transition to state WAIT_RLL_RTP_RELEASED not permitted! 20181128193707330 DAS osmo-bsc/assignment_fsm.c:128 assignment(conn4_0-0-6-TCH_F_PDCHasPDCH-0)[0x6120000024a0]{WAIT_LCHAN_ACTIVE}: Freeing instance 20181128193707330 DAS fsm.c:381 assignment(conn4_0-0-6-TCH_F_PDCHasPDCH-0)[0x6120000024a0]{WAIT_LCHAN_ACTIVE}: Deallocated Change-Id: I3e95a21e5a5ec6c35b1ab20b7a642fd7eb81e556
2018-12-05bsc: timeslot_fsm: Fix count in ts_lchans_waitingPau Espin Pedrol1-1/+1
Before this patch, TCH lchans waiting for dynamic TS to switch PDCH->TCH wouldn't be counted. See osmo-bsc I9cedb77d6578597f1febab36c54b2ee427c7a4a2 for similar extensive explanation. Change-Id: I32008859cc23cd2afddd79daae21497d0945fed0
2018-12-05bsc: timeslot_fsm: Fix possible skip of some lchans in ts_terminate_lchan_fsmsPau Espin Pedrol1-1/+1
If TS is in state changing from PDCH->TCH, the TCH lchan provoking the switch would be skipped and not terminated before this patch. See osmo-bsc I9cedb77d6578597f1febab36c54b2ee427c7a4a2 for similar extensive explanation. Change-Id: I9dc2a6e5b15376d049bd2ac5ddfa24340771b5c8
2018-12-05bsc: ts_is_pchan_switching: Return correct IPA dyn TS target_pchanPau Espin Pedrol1-2/+15
Change-Id: Ie438b4efaa9832c44009a92c3df698875f1fa9ae
2018-12-05bsc: timeslot_fsm: Fix ts_is_lchan_waiting_for_pchanPau Espin Pedrol1-3/+5
If ts_is_lchan_waiting_for_pchan() wasn't accounting for TCH lchans waiting for TS to deactive PDCH in order to setup the TS as TCH. Since now TCH lchan is catched by ts_is_lchan_waiting_for_pchan() when TS state is TS_ST_WAIT_PDCH_DEACT, there's no need to check for that case in caller ts_is_pchan_switching(), since it will never hit because the callee returns true in that case now. See osmo-bsc I9cedb77d6578597f1febab36c54b2ee427c7a4a2 for similar extensive explanation. Change-Id: Ib03e5a91438a5b74a04e69f81fab565842b02b66
2018-12-05bsc: timelost_fsm: Remove unneeded set of out variable on failurePau Espin Pedrol1-3/+0
Documentation of the function explicitly states that the out target_pchan param returns the "PCHAN waited for". If we return false, then no PCHAN is being waited for. The 2 callers of this function only use this out param if function returns true, so let's simplify the code. Change-Id: Ib8f9b7e1f584dee885d6823dc043682577572bd8
2018-12-05bsc: Fix lchan iteration for dyn TS during PDCH DeactPau Espin Pedrol1-1/+1
In general PDCH channels are not handled as lchans in BSC (lchan_fsm.c), and so when a TS is in ts->pchan_is=GSM_PCHAN_PDCH, no lchan slot is being used. However, during Dynamic TS PDCH Deactivation being in progress (state WAIT_PDCH_DEACT in timeslot_fsm.c), ts->pchan_is =GSM_PCHAN_PDCH, but an lchan slot of that TS is actually already being used by a TCH lchan: it's the one who initiated the deactivate in order to be able to use the TS. While being in WAIT_PDCH_DEACT state and receiving a PDCH DEACT NACK, ts_fsm_error() was called in order to kill the TS and it was expected that it would kill any lchan using it (or willing to start using it). In order to do that, it calls ts_lchans_dispatch() which in turns iterates over all lchans attached to the TS using ts_for_each_lchan(). However, when the NACK arrived we still had ts->pchan_is=GSM_PCHAN_PDCH, ts_for_each_lchan ends up calling ts_as_pchan_for_each_lchan(GSM_PCHAN_PDCH), which in turns calls pchan_subslots(GSM_PCHAN_PDCH) which returns 0, because we don't manage lchans in that mode as explained in first paragraph. This means in this case ts_for_each_lchan() is actually an empty loop while still any of the TCH channels may be in use, and won't be advertised about the TS entering in a broken state. As a result, the lchan won't be released for a while, only after T23001 expires. Related: OS#3708 Change-Id: I9cedb77d6578597f1febab36c54b2ee427c7a4a2
2018-12-05bsc: Add define for ts_as_pchan_for_each_lchan with ts->pchan_on_initPau Espin Pedrol2-1/+14
It will be used further in follow-up patches. It also provides a place to document its (intricate) logic around it and its possible uses. Change-Id: Ia1d4bdbfca6b9719f54ee609b6bfadf7f3a4bb43
2018-12-05contrib/jenkins.sh: build and publish manualsOliver Smith1-2/+19
Add new environment variables WITH_MANUALS and PUBLISH to control if the manuals should be built and uploaded. Describe all environment vars on top of the file. When WITH_MANUALS is set, install osmo-gsm-manuals like any other dependency and add --enable-manuals to the configure flags (for "make" and "make distcheck"). Add the bin subdir of the installed files to PATH, so osmo-gsm-manuals-check-depends can be used by ./configure. Related: OS#3385 Change-Id: Ief6ce94013612a968183e82abef421f116ed37c3
2018-12-04Fix DISTCHECK_CONFIGURE_FLAGS overrideOliver Smith1-1/+1
Set AM_DISTCHECK_CONFIGURE_FLAGS in Makefile.am instead of DISTCHECK_CONFIGURE_FLAGS. This is the recommended way from the automake manual, as otherwise the flag can't be changed by the user anymore. Related: OS#3718 Change-Id: I38bd2bffa24c5b970aa4a42dcfc8d8766bb96046
2018-12-01osmo_bsc_bssap.c: fix incorrect link_id assignmentVadim Yanitskiy1-1/+1
Every DTAP message coming from the MSC has a header (see struct dtap_header) that contains message type, length, and link ID. The link ID indicates SAPI and channel type of a given message. In dtap_rcvmsg() we allocate a new message buffer and copy the received message into it. The old message buffer is freed by the caller then. The link ID value parsed from DTAP header is usually being stored in the control buffer of a message buffer (i.e. msgb->cb). Due to a mistake, it was stored in the old (to be freed) message, while the new (to be forwarded) message always had link_id = 0x00! This change resolves the problem with sending SMS during a voice call, when MT signalling goes through FACCH, while MO signalling goes through SACCH. Change-Id: I7675e1ce4436fad836778261ac9d446fa8f81483 Related: OS#3716
2018-11-30follow-up: logging tweak for Immediate AssignmentNeels Hofmeyr1-6/+4
follow-up to I9ad094d272254d7aee9b0a676201d4ed8cd727ca because it was merged before fixeria's code review could be incorporated. Change-Id: I474cf1a58d1f00ec5b0ae52bd095a60aad763975
2018-11-29bsc: ts_for_each_lchan: Improve documentationPau Espin Pedrol1-2/+4
Change-Id: Id7c050087c14aae3f01c6d41d21cf861ff53621c
2018-11-29bsc: ts_as_pchan_for_each_lchan: reorder and improve documentationPau Espin Pedrol1-9/+12
It is moved prior to its user in the header file. Change-Id: I59f52401ba37b351ba3848e8e9ffb3b24c259496
2018-11-28bsc: lchan_select: Avoid returning a TCH/H lchan when TCH/F is requestedPau Espin Pedrol1-16/+1
If BTS is configured to have only TCH/F_PDCH and TCH/H and a call is resolved to require TCH/F, don't return the TCH/H which have no use, but instead let it allocate the TCH/F_PDCH. 20181128185013783 DRLL <0000> lchan_select.c:159 (bts=0) lchan_select_by_type(TCH_F) 20181128185013783 DRLL <0000> lchan_select.c:71 looking for lchan TCH/F: (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4,state=IN_USE) is != TCH/F 20181128185013783 DRLL <0000> lchan_select.c:71 looking for lchan TCH/F: (bts=0,trx=0,ts=1,pchan=SDCCH8,state=UNUSED) is != TCH/F 20181128185013783 DRLL <0000> lchan_select.c:71 looking for lchan TCH/F: (bts=0,trx=0,ts=2,pchan=TCH/H,state=UNUSED) is != TCH/F 20181128185013783 DRLL <0000> lchan_select.c:71 looking for lchan TCH/F: (bts=0,trx=0,ts=3,pchan=TCH/H,state=UNUSED) is != TCH/F 20181128185013783 DRLL <0000> lchan_select.c:71 looking for lchan TCH/F: (bts=0,trx=0,ts=4,pchan=TCH/H,state=UNUSED) is != TCH/F 20181128185013783 DRLL <0000> lchan_select.c:71 looking for lchan TCH/F: (bts=0,trx=0,ts=5,pchan=TCH/H,state=UNUSED) is != TCH/F 20181128185013783 DRLL <0000> lchan_select.c:71 looking for lchan TCH/F: (bts=0,trx=0,ts=6,pchan_on_init=TCH/F_PDCH,pchan=PDCH,state=PDCH) is != TCH/F 20181128185013784 DRLL <0000> lchan_select.c:71 looking for lchan TCH/F: (bts=0,trx=0,ts=7,pchan_on_init=TCH/F_PDCH,pchan=PDCH,state=PDCH) is != TCH/F 20181128185013784 DRLL <0000> lchan_select.c:71 looking for lchan TCH/H: (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4,state=IN_USE) is != TCH/H 20181128185013784 DRLL <0000> lchan_select.c:71 looking for lchan TCH/H: (bts=0,trx=0,ts=1,pchan=SDCCH8,state=UNUSED) is != TCH/H 20181128185013784 DRLL <0000> lchan_select.c:86 looking for lchan TCH/H: (bts=0,trx=0,ts=2,pchan=TCH/H,state=UNUSED) ss=0 is available 20181128185013784 DCHAN <0010> lchan_select.c:253 lchan(0-0-2-TCH_H-0)[0x6120000066a0]{UNUSED}: (type=TCH_H) Selected Change-Id: I9a73beb0432fab16d5430e5b40d470694e09b189
2018-11-28cosmetic: bsc: timeslot_fsm: Clean uneeded scope bracketsPau Espin Pedrol1-5/+4
Change-Id: I5140f98e23b8c8d16ce0cca0be66297aaf0b5653
2018-11-27build manuals included from osmo-gsm-manuals.gitOliver Smith8-33/+101
Moved to doc/manuals/, with full commit history, in preceding merge commit. Now incorporate in local the build system. Build with: $ autoreconf -fi $ ./configure --enable-manuals $ make Shared files from osmo-gsm-manuals.git are found automatically if - the repository is checked out in ../osmo-gsm-manuals; or - if it osmo-gsm-manuals was installed with "make install"; or - OSMO_GSM_MANUALS_DIR is set. Related: OS#3385 Change-Id: I92c0f771d4ffc2b0401d26e25cb0b3817e6f95ea
2018-11-27Merge history from osmo-gsm-manuals.gitNeels Hofmeyr35-0/+8016
Change-Id: I9ff481784ba8c6334b1e57b1f64dfc9262e6d0e2
2018-11-27copy NITB's osmobsc-usermanual.adoc to OsmoBSCOliver Smith2-1/+282
Includes from other projects don't work anymore when moving project specific manuals into other repositories. Related: OS#3385 Change-Id: I96933dd4dd6cac159847647f1c642215051a9aad
2018-11-27OsmoBSC: update VTY referenceNeels Hofmeyr1-447/+505
Re-generate bsc_vty_reference.xml from osmo-bsc, including updates to: - handover and neighbor config - SCCP timers - logging Change-Id: Ia9ba8d5eba531b1156de57573ab42517e0c1ca15
2018-11-27OsmoBSC/HLR/MSC: Fix default config file nameDaniel Willmann1-1/+1
Mention that the default is not openbsc.cfg, but osmo-*.cfg Change-Id: I139e6004e28d6f918f31792e634214a6153edd0e
2018-11-27author info: add "former" to Holger's job titleNeels Hofmeyr2-2/+2
It doesn't seem to have an effect on the generated PDFs though. Change-Id: I0556a3f8dafc051f20a3854fc9006edf4ec1a0d3
2018-11-27bsc: handover: mention the need to resend SI for telnet neighbor cfgNeels Hofmeyr1-0/+9
Change-Id: I305ef558b75697015e2532aa7c135f7995662e0d
2018-11-27bsc: handover: clarify default of all-cells-are-neighborsNeels Hofmeyr1-0/+16
Change-Id: I61f877c7a60419132bdd27c1b4e64150c0520751
2018-11-27bsc: document handoverNeels Hofmeyr6-2/+642
Add chapter "Handover", explaining: - intra- and - inter-BSC handover, - HO algorithm 1 and - algorithm 2 - new neighbor configuration Adjust copyright, add revision and add me as author. Change-Id: I7afb3f66c98abda07fc8acc76e00c46091fe55e2
2018-11-27vty-ref: Update URI of docbook 5.0 schemaHarald Welte1-2/+2
... to match the /etc/xml/catalog file on debian (no "www" in hostname) Change-Id: Id9f3579c7f2bc3af13fe30b5268f249b6f59ed0d
2018-11-27OsmoBSC: update VTY referenceNeels Hofmeyr2-3065/+4790
This is the first update since the libosmocore changes to the 'show online-help' generated output. Hence the produced document now benefits from the structural improvements: - not repeating common commands for every node; - using section names that match the VTY prompt. Update bsc_vty_additions.xml to match the new node ID scheme. Change-Id: I0d856563eee88527fda4c6940aa6cea779175aaa
2018-11-27add message sequence chart MS/BTS/BSC/MSC for 3GPP aoIP MO callHarald Welte1-0/+146
Change-Id: I7e41234cfe1483bb73589dc959851a54f9aafa36
2018-11-27common / OsmoBSC: drop unused alink.adocNeels Hofmeyr2-17/+0
Change-Id: Ia3219359be891c161d20eccb7bbcb65af35ef42b
2018-11-27OsmoBSC: update overview to explain both SCCPlite and SCCP/M3UANeels Hofmeyr1-77/+91
Change-Id: I1f105b3febd4f99f4491e217ff1b1d0b28912980
2018-11-27OsmoBSC: add rate counter documentationAlexander Couzens3-0/+82
Change-Id: Ia8711dd4bc9db36a7121552dc067c7afb1051b0a