drop files unrelated to osmo-sgsn

These either remain from openbsc.git or slipped in while applying recent
patches from openbsc.git and do not belong in osmo-sgsn.

Change-Id: Ie9dc7514c3850010d0e9b3ab716b4f4e8d83594f

16 files changed, 0 insertions, 882 deletions

diff --git a/doc/BS11-OML.txt b/doc/BS11-OML.txt
deleted file mode 100644
index e5c3299c9..000000000
--- a/doc/BS11-OML.txt
+++ /dev/null
@@ -1,31 +0,0 @@
-The Siemens BS-11 supports the following additional GSM 12.21 OML operations:
-
-
-CREATE OBJECT
-
-abis_om_fom_hdr.obj_class can be 
-A3:
-A5: ALCO, BBSIG, CCLK, GPSU, LI, PA
-A8: EnvaBTSE
-A9: BPORT
-
-the abis_om_obj_inst.trx_nr field indicates the index of object, whereas the
-abis_om_fom_hdr.bts_nr indicates the type of the object.
-
-enum abis_bs11_objtype {
-	BS11_OBJ_ALCO		= 0x01,
-	BS11_OBJ_BBSIG		= 0x02,	/* obj_class: 0,1 */
-	BS11_OBJ_TRX1		= 0x03,	/* only DEACTIVATE TRX1 */
-	BS11_OBJ_CCLK		= 0x04,
-	BS11_OBJ_GPSU		= 0x06,
-	BS11_OBJ_LI		= 0x07,
-	BS11_OBJ_PA		= 0x09,	/* obj_class: 0, 1*/
-};
-
-In case of CREATE ENVABTSE, the abis_om_obj_inst.trx_nr indicates the EnvaBTSEx
-number.
-
-In case of A9 (CREAETE BPORT), the abis_om_obj_inst.bts_nr indicates which BPORT
-shall be used.
-
-
diff --git a/doc/call-routing.txt b/doc/call-routing.txt
deleted file mode 100644
index 3402f9e33..000000000
--- a/doc/call-routing.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-Call routing in OpenBSC
-
-Flow of events:
-
- # MO call initiated by MS, CHANNEL RQD, IMMEDIATE ASSIGN
- # MS sends CC SETUP message, we assume already on TCH/H FACCH
- # OpenBSC does a subscriber lookup based on the target extension
-  * If a subscriber is found:
-   # send CALL PROCEEDING message to MO
-   # page the MT subscriber and ask itI to ask for TCH/H
-   # once paging completes, we have the TCH/H for the MT end
-   # send SETUP to MT
-   # receive CALL CONFIRMED from MT
-   # set-up the TRAU mux mapping between the E1 subslots for both TCH/H
-   # receive ALERTING from MT, route ALERTING to MO
-   # receive CONNECT from MT, confirm to MT with CONNECT_ACK
-   # send a CONNECT message to MO, receive CONNECT_ACK from MO
- * If subscriber is not found:
-  # send RELEASE COMPLETE with apropriate cause to MO (1: unalloacated 3: no route)
-  
-
-
-Thoughts about RR/MM:
-
-* we allocate RR/MM entities on demand, when we need them
diff --git a/doc/channel_release.txt b/doc/channel_release.txt
deleted file mode 100644
index c9cdfebca..000000000
--- a/doc/channel_release.txt
+++ /dev/null
@@ -1,95 +0,0 @@
-
-GSM 04.08 7.1.7 / 9.1.7		RR CHANNEL RELESE
-
-RSL 08.58 3.4 / ?		RLL Link Release Request
-
-RSL 08.58 4.6 / 8.4.5		DEACTivate SACCH
-	* Deactivate SACCH according to Channel Release Proc 04.08
-	* to be sent after RR CHANNEL RELEASE is sent to MS
-
-RSL 08.58 4.7 / 8.4.14		RF CHANnel RELease
-	* tells the BTS to release a radio channel
-	* "when an activated radio channel is no longer needed"
-	* BTS responds with RF CHANnel RELease ACKnowledge
-
-
-GSM 04.08 3.4.13: RR connection release procedure
-
-* network sends RR CHANNEL RELEASE to MS on the DCCH
-  * start T3109
-  * deactivate SACCH
-* MS disconnects main signalling link (by sending DISC)
-  * all other data links are disconnected by local end link release
-* network receives DISC (BTS sends RLL REL IND to BSC)
-  * stop T3109
-  * start T3111 
-* when T3111 times out, the network can reuse the channls
-* if T3109 times out, the network deactivates the channels 
-  and can reuse them
-  * this probably means simply RF CHANnel RELease
-
-
-== Implementation in OpenBSC ==
-
-There are two possible reasons a gsm_subscriber_connection
-will be released. One is a network failure, the other is
-the completion of an operation/transaction.
-
-=== Failure ===
-The BSC API will call the gsm_04_08.c:gsm0408_clear_request callback
-and the MSC part will release all transactions, operations and such
-and the channels will be released as error case.
-
-=== Success ===
-Every time an 'operation' or 'transaction' is finished msc_release_connection
-will be called and it will determine if the gsm_subscriber_connection can
-be released.
-
-In case it can be released bsc_api.c:gsm0808_clear will be called
-which will release all lchan's associated with the connection. For the
-primary channel a SACH Deactivate will be send with the release
-reason NORMAL RELEASE.
-
-
-bsc_api.c:gsm0808_clear
-	* Release a channel used for handover
-	* Release the primary lchan with normal release, SACH deactivate
-
-chan_alloc.c:lchan_release(chan, sacch_deactivate, reason)
-	* Start the release procedure. It is working in steps with callbacks
-	  coming from the abis_rsl.c code.
-	* Release all SAPI's > 0 as local end (The BTS should send a
-	  REL_CONF a message)
-	* Send SACH Deactivate on SAPI=0 if required.
-	* Start T3109 (stop it when the main signalling link is disconnected)
-	  or when the channel released. On timeout start the error handling.
-	* abis_rsl.c schedules the RSL_MT_RF_CHAN_REL once all SAPI's are
-	  released and after T3111 has timed out or there is an error.
-
-RX of RELease INDication:
-        * Calls internal rsl_handle_release which might release the RF.
-
-RX of RELease CONFirmation:
-        * Calls internal rsl_handle_release which might release the RF.
-
-* RX of RF_CHAN_REL_ACK
-	* call lchan_free()
-
-
-=== Integration with SMS ===
-
-* RX of CP_ERROR or unimplemented MT
-	* trigger trans_free() which will msc_release_connection()
-
-* CP TC1* expired while waiting for CP-ACK
-	* trigger trans_free() which will msc_release_connection()
-
-* RX of RP_ERROR
-	* trigger trans_free() which will msc_release_connection()
-	
-* TX of CP-ACK in MT DELIVER
-	* trigger trans_free() which will msc_release_connection()
-
-* RX of CP-ACK in MO SUBMIT
-	* trigger trans_free() which will msc_release_connection()
-	
diff --git a/doc/e1-data-model.txt b/doc/e1-data-model.txt
deleted file mode 100644
index 509004fe9..000000000
--- a/doc/e1-data-model.txt
+++ /dev/null
@@ -1,172 +0,0 @@
-E1 related data model
-
-This data model describes the physical relationship of the individual
-parts in the network, it is not the logical/protocol side of the GSM
-network.
-
-A BTS is connected to the BSC by some physical link.  It could be an actual
-E1 link, but it could also be abis-over-IP with a mixture of TCP and RTP/UDP.
-
-To further complicate the fact, multiple BTS can share one such pysical
-link.  On a single E1 line, we can easily accomodate up to three BTS with
-two TRX each.
-
-Thus, it is best for OpenBSC to have some kind of abstraction layer.  The BSC's
-view of a BTS connected to it.  We call this 'bts_link'.  A bts_link can be
-* all the TCP and UDP streams of a Abis-over-IP BTS
-* a set of E1 timeslots for OML, RSL and TRAU connections on a E1 link
-* a serial line exclusively used for OML messages (T-Link)
-
-A bts_link can be registered with the OpenBSC core at runtime.
-
-struct trx_link {
-	struct gsm_bts_trx *trx;
-};
-
-struct bts_link {
-	struct gsm_bts *bts;
-	struct trx_link trx_links[NUM_TRX];
-};
-
-Interface from stack to input core:
-======================================================================
-int abis_rsl_sendmsg(struct msgb *msg);
-	send a message through a RSL link to the TRX specified by the caller in
-	msg->trx.
-
-int abis_rsl_rcvmsg(struct msgb *msg);
-	receive a message from a RSL link from the TRX specified by the
-	caller in msg->trx.
-
-int abis_nm_sendmsg(struct msgb *msg);
-	send a message through a OML link to the BTS specified by the caller in
-	msg->trx->bts.  The caller can just use bts->c0 to get the first TRX
-	in a BTS. (OML messages are not really sent to a TRX but to the BTS)
-
-int abis_nm_rcvmsg(struct msgb *msg);
-	receive a message from a OML link from the BTS specified by the caller
-	in msg->trx->bts.  The caller can just use bts->c0 to get the first
-	TRX in a BTS.
-
-int abis_link_event(int event, void *data);
-	signal some event (such as layer 1 connect/disconnect) from the
-	input core to the stack.
-
-int subch_demux_in(mx, const uint8_t *data, int len);
-	receive 'len' bytes from a given E1 timeslot (TRAU frames)
-
-int subchan_mux_out(mx, uint8_t *data, int len);
-	obtain 'len' bytes of output data to be sent on E1 timeslot
-
-Intrface by Input Core for Input Plugins
-======================================================================
-
-int btslink_register_plugin();
-
-
-Configuration for the E1 input module
-======================================================================
-
-BTS
-	BTS number
-	number of TRX
-	OML link
-		E1 line number
-		timeslot number
-		[subslot number]
-		SAPI
-		TEI
-	for each TRX
-		RSL link
-			E1 line number
-			timeslot number
-			[subslot number]
-			SAPI
-			TEI
-		for each TS
-			E1 line number
-			timeslot number
-			subslot number
-
-
-E1 input module data model
-======================================================================
-
-
-enum e1inp_sign_type {
-	E1INP_SIGN_NONE,
-	E1INP_SIGN_OML,
-	E1INP_SIGN_RSL,
-};
-
-struct e1inp_sign_link {
-	/* list of signalling links */
-	struct llist_head list;
-
-	enum e1inp_sign_type type;
-
-	/* trx for msg->trx of received msgs */	
-	struct gsm_bts_trx *trx;
-
-	/* msgb queue of to-be-transmitted msgs */
-	struct llist_head tx_list;
-
-	/* SAPI and TEI on the E1 TS */
-	uint8_t sapi;
-	uint8_t tei;
-}
-
-enum e1inp_ts_type {
-	E1INP_TS_TYPE_NONE,
-	E1INP_TS_TYPE_SIGN,
-	E1INP_TS_TYPE_TRAU,
-};
-
-/* A timeslot in the E1 interface */
-struct e1inp_ts {
-	enum e1inp_ts_type type;
-	struct e1inp_line *line;
-	union {
-		struct {
-			struct llist_head sign_links;
-		} sign;
-		struct {
-			/* subchannel demuxer for frames from E1 */
-			struct subch_demux demux;
-			/* subchannel muxer for frames to E1 */
-			struct subch_mux mux;
-		} trau;
-	};
-	union {
-		struct {
-			/* mISDN driver has one fd for each ts */
-			struct osmo_fd;
-		} misdn;
-	} driver;
-};
-
-struct e1inp_line {
-	unsigned int num;
-	char *name;
-
-	struct e1inp_ts ts[NR_E1_TS];
-
-	char *e1inp_driver;
-	void *driver_data;
-};
-
-/* Call from the Stack: configuration of this TS has changed */
-int e1inp_update_ts(struct e1inp_ts *ts);
-
-/* Receive a packet from the E1 driver */
-int e1inp_rx_ts(struct e1inp_ts *ts, struct msgb *msg,
-		uint8_t tei, uint8_t sapi);
-
-/* Send a packet, callback function in the driver */
-int e1driver_tx_ts(struct e1inp_ts *ts, struct msgb *msg)
-
-
-struct e1inp_driver {
-	const char *name;
-	int (*want_write)(struct e1inp_ts *ts);
-};
diff --git a/doc/examples/osmo-bsc/osmo-bsc.cfg b/doc/examples/osmo-bsc/osmo-bsc.cfg
deleted file mode 100644
index 7c10e9dea..000000000
--- a/doc/examples/osmo-bsc/osmo-bsc.cfg
+++ /dev/null
@@ -1,101 +0,0 @@
-!
-! OsmoBSC (0.9.14+gitr1+3d331c0062bb0c9694dbd4d1eab7adc58138c3ae) configuration saved from vty
-!!
-password foo
-!
-!
-line vty
- no login
-!
-e1_input
- e1_line 0 driver ipa
-network
- network country code 1
- mobile network code 1
- short name OsmoBSC
- long name OsmoBSC
- auth policy closed
- location updating reject cause 13
- encryption a5 0
- neci 1
- paging any use tch 0
- rrlp mode none
- mm info 1
- handover 0
- handover window rxlev averaging 10
- handover window rxqual averaging 1
- handover window rxlev neighbor averaging 10
- handover power budget interval 6
- handover power budget hysteresis 3
- handover maximum distance 9999
- bts 0
-  type nanobts
-  band DCS1800
-  cell_identity 0
-  location_area_code 1
-  training_sequence_code 7
-  base_station_id_code 63
-  ms max power 15
-  cell reselection hysteresis 4
-  rxlev access min 0
-  channel allocator ascending
-  rach tx integer 9
-  rach max transmission 7
-  dtx uplink force
-  dtx downlink
-  ip.access unit_id 0 0
-  oml ip.access stream_id 255 line 0
-  neighbor-list mode manual-si5
-  neighbor-list add arfcn 100
-  neighbor-list add arfcn 200
-  si5 neighbor-list add arfcn 10
-  si5 neighbor-list add arfcn 20
-  gprs mode none
-  trx 0
-   rf_locked 0
-   arfcn 871
-   nominal power 23
-   max_power_red 20
-   rsl e1 tei 0
-   timeslot 0
-    phys_chan_config CCCH+SDCCH4
-    hopping enabled 0
-   timeslot 1
-    phys_chan_config TCH/F
-    hopping enabled 0
-   timeslot 2
-    phys_chan_config TCH/F
-    hopping enabled 0
-   timeslot 3
-    phys_chan_config TCH/F
-    hopping enabled 0
-   timeslot 4
-    phys_chan_config TCH/F
-    hopping enabled 0
-   timeslot 5
-    phys_chan_config TCH/F
-    hopping enabled 0
-   timeslot 6
-    phys_chan_config TCH/F
-    hopping enabled 0
-   timeslot 7
-    phys_chan_config TCH/F
-    hopping enabled 0
-cs7 instance 1
- point-code 3.0.0
- sccp-address bsc_local
-  point-code 3.0.0
- sccp-address msc_remote
-  point-code 1.0.0
-msc
- bsc-addr bsc_local
- msc-addr msc_remote
- ip.access rtp-base 4000
- timeout-ping 20
- timeout-pong 5
- dest 192.168.100.11 6666 0
- access-list-name msc-list
- no access-list-name
-bsc
- no access-list-name
- access-list-name bsc-list
diff --git a/doc/examples/osmo-bsc_mgcp/mgcp.cfg b/doc/examples/osmo-bsc_mgcp/mgcp.cfg
deleted file mode 100644
index 3c43f1feb..000000000
--- a/doc/examples/osmo-bsc_mgcp/mgcp.cfg
+++ /dev/null
@@ -1,19 +0,0 @@
-!
-! MGCP configuration hand edited
-!   !
-password foo
-!
-line vty
- no login
-!
-mgcp
-  !local ip 10.23.24.2
-  !bts ip 10.24.24.1
-  !bind ip 10.23.24.1
-  bind port 2427
-  rtp base 4000
-  rtp force-ptime 20
-  sdp audio payload number 98
-  sdp audio payload name AMR/8000
-  number endpoints 31
-  no rtcp-omit
diff --git a/doc/examples/osmo-bsc_nat/black-list.cfg b/doc/examples/osmo-bsc_nat/black-list.cfg
deleted file mode 100644
index d36179d37..000000000
--- a/doc/examples/osmo-bsc_nat/black-list.cfg
+++ /dev/null
@@ -1 +0,0 @@
-678012512671923:6:6:
diff --git a/doc/examples/osmo-bsc_nat/bscs.cfg b/doc/examples/osmo-bsc_nat/bscs.cfg
deleted file mode 100644
index 176debe42..000000000
--- a/doc/examples/osmo-bsc_nat/bscs.cfg
+++ /dev/null
@@ -1,13 +0,0 @@
-nat
- bsc 0
-  token lol
-  location_area_code 1234
-  description bsc
-  max-endpoints 32
-  paging forbidden 0
- bsc 1
-  token wat
-  location_area_code 5678
-  description bsc
-  max-endpoints 32
-  paging forbidden 0
diff --git a/doc/examples/osmo-bsc_nat/osmo-bsc_nat.cfg b/doc/examples/osmo-bsc_nat/osmo-bsc_nat.cfg
deleted file mode 100644
index e835e068a..000000000
--- a/doc/examples/osmo-bsc_nat/osmo-bsc_nat.cfg
+++ /dev/null
@@ -1,66 +0,0 @@
-!
-! OsmoBSCNAT (0.12.0.266-2daa9) configuration saved from vty
-!!
-!
-log stderr
-  logging filter all 1
-  logging color 1
-  logging timestamp 0
-  logging level all debug
-  logging level rll notice
-  logging level cc notice
-  logging level mm notice
-  logging level rr notice
-  logging level rsl notice
-  logging level nm info
-  logging level mncc notice
-  logging level pag notice
-  logging level meas notice
-  logging level sccp notice
-  logging level msc notice
-  logging level mgcp notice
-  logging level ho notice
-  logging level db notice
-  logging level ref notice
-  logging level gprs debug
-  logging level ns info
-  logging level bssgp debug
-  logging level llc debug
-  logging level sndcp debug
-  logging level nat notice
-  logging level ctrl notice
-  logging level smpp debug
-  logging level lglobal notice
-  logging level llapd notice
-  logging level linp notice
-  logging level lmux notice
-  logging level lmi notice
-  logging level lmib notice
-  logging level lsms notice
-!
-line vty
- no login
-!
-mgcp
-  bind ip 0.0.0.0
-  bind port 2427
-  rtp bts-base 4000
-  rtp net-base 16000
-  rtp ip-dscp 0
-  no rtcp-omit
-  sdp audio-payload number 126
-  sdp audio-payload name AMR/8000
-  loop 0
-  number endpoints 1
-  call-agent ip 127.0.0.1
-  rtp transcoder-base 0
-  transcoder-remote-base 4000
-nat
- msc ip 127.0.0.1
- msc port 5000
- timeout auth 2
- timeout ping 20
- timeout pong 5
- ip-dscp 0
- bscs-config-file bscs.cfg
- access-list bla imsi-allow ^11$
diff --git a/doc/examples/osmo-msc/osmo-msc.cfg b/doc/examples/osmo-msc/osmo-msc.cfg
deleted file mode 100644
index 1b1d19258..000000000
--- a/doc/examples/osmo-msc/osmo-msc.cfg
+++ /dev/null
@@ -1,19 +0,0 @@
-!
-! OsmoMSC configuration saved from vty
-!
-line vty
- no login
-!
-network
- network country code 1
- mobile network code 1
- short name OsmoMSC
- long name OsmoMSC
- auth policy closed
- location updating reject cause 13
- encryption a5 0
- rrlp mode none
- mm info 1
-msc
- mgcpgw remote-ip 10.23.24.1
- assign-tmsi
diff --git a/doc/gsm-hopping.txt b/doc/gsm-hopping.txt
deleted file mode 100644
index c964963c0..000000000
--- a/doc/gsm-hopping.txt
+++ /dev/null
@@ -1,54 +0,0 @@
-according to GSM 05.02:
-
-general parameters from CCCH:
-* CA cell allocation of ARFCN's (System Information / BCCH)
-* FN: TDMA frame number (t1,t2,t3') in SCH
-
-specific parameters from channel assignment:
-* MA: mobile allocation, defines set of ARFCN's, up to 64
-* MAIO: index
-* HSN: hopping sequence generator number (0..64)
-
-
-hopping sequence generation (6.2.3):
-
-uint8_t rntable[114] = {
-	 48,  98,  63,   1,  36,  95,  78, 102,  94,  73,
-	  0,  64,  25,  81,  76,  59, 124,  23, 104, 100,
-	101,  47, 118,  85,  18,  56,  96,  86,  54,   2,
-	 80,  34, 127,  13,   6,  89,  57, 103,  12,  74,
-	 55, 111,  75,  38, 109,  71, 112,  29,  11,  88,
-	 87,  19,   3,  68, 110,  26,  33,  31,   8,  45,
-	 82,  58,  40, 107,  32,   5, 106,  92,  62,  67,
-	 77, 108, 122,  37,  60,  66, 121,  42,  51, 126,
-	117, 114,   4,  90,  43,  52,  53, 113, 120,  72,
-	 16,  49,   7,  79, 119,  61,  22,  84,   9,  97,
-	125,  99,  17, 123
-};
-
-/* mai=0 represents lowest ARFCN in the MA */
-
-
-uint8_t hopping_mai(uint8_t hsn, uint32_t fn, uint8_t maio,
-		     uint8_t t1, uint8_t t2, uint8_t t3_)
-{
-	uint8_t mai;
-
-	if (hsn == 0) /* cyclic hopping */
-		mai = (fn + maio) % n;
-	else {
-		uint32_t m, m_, t_, s;
-
-		m = t2 + rntable[(hsn xor (t1 % 64)) + t3];
-		m_ = m % (2^NBIN);
-		t_ = t3 % (2^NBIN);
-		if (m_ < n then)
-			s = m_;
-		else
-			s = (m_ + t_) % n;
-		mai = (s + maio) % n;
-	}
-
-	return mai;
-}
-
diff --git a/doc/handover.txt b/doc/handover.txt
deleted file mode 100644
index ac19e8725..000000000
--- a/doc/handover.txt
+++ /dev/null
@@ -1,89 +0,0 @@
-Ideas about a handover algorithm
-======================================================================
-
-This is mostly based on the results presented in Chapter 8 of "Performance
-Enhancements in a Frequency Hopping GSM Network" by Thomas Toftegaard Nielsen
-and Joeroen Wigard. 
-
-
-=== Reasons for performing handover ===
-
-Section 2.1.1: Handover used in their CAPACITY simulation:
-
-1) Interference Handover
-
-Average RXLEV is satisfactory high, but average RXQUAL too low indicates
-interference to the channel.  Handover should be made.
-
-2) Bad Quality
-
-Averaged RXQUAL is lower than a threshold
-
-3) Low Level / Signal Strength
-
-Average RXLEV is lower than a threshold
-
-4) Distance Handover
-
-MS is too far away from a cell (measured by TA)
-
-5) Power budget / Better Cell
-
-RX Level of neighbor cell is at least "HO Margin dB" dB better than the
-current serving cell.
-
-=== Ideal parameters for HO algorithm ===
-
-Chapter 8, Section 2.2, Table 24:
-
-Window RXLEV averaging:		10 SACCH frames (no weighting)
-Window RXQUAL averaging:	1 SACCH frame (no averaging)
-Level Threashold:		1 of the last 1 AV-RXLEV values < -110dBm
-Quality Threshold:		3 of the last 4 AV-RXQUAL values >= 5
-Interference Threshold:		1 of the last AV-RXLEV > -85 dBm &
-				3 of the last 4 AV-RXQUAL values >= 5
-Power Budget:			Level of neighbor cell > 3 dB better
-Power Budget Interval:		Every 6 SACCH frames (6 seconds ?!?)
-Distance Handover:		Disabled
-Evaluation rule 1:		RXLEV of the candidate cell a tleast -104 dBm
-Evaluation rule 2:		Level of candidate cell > 3dB better own cell
-Timer Successful HO:		5 SACCH frames
-Timer Unsuccessful HO:		1 SACCH frame
-
-In a non-frequency hopping case, RXQUAL threshold can be decreased to
-RXLEV >= 4
-
-When frequency hopping is enabled, the following additional parameters
-should be introduced:
-
-* No intra-cell handover
-* Use a HO Margin of 2dB
-
-=== Handover Channel Reservation ===
-
-In loaded network, each cell should reserve some channels for handovers,
-rather than using all of them for new call establishment.  This reduces the
-need to drop calls due to failing handovers, at the expense of failing new call
-attempts.
-
-=== Dynamic HO Margin ===
-
-The handover margin (hysteresis) should depend on the RXQUAL. Optimal results
-were achieved with the following settings:
-* RXQUAL <= 4: 9 dB
-* RXQUAL == 5: 6 dB
-* RXQUAL >= 6: 1 dB
-
-
-
-== Actual Handover on a protocol level ==
-
-After the BSC has decided a handover shall be done, it has to
-
-# allocate a channel at the new BTS
-# allocate a handover reference
-# activate the channel on the BTS side using RSL CHANNEL ACTIVATION,
-  indicating the HO reference
-# BTS responds with CHAN ACT ACK, including GSM frame number
-# BSC sends 04.08 HO CMD to MS using old BTS
-
diff --git a/doc/ipa-sccp.txt b/doc/ipa-sccp.txt
deleted file mode 100644
index 5d6719e98..000000000
--- a/doc/ipa-sccp.txt
+++ /dev/null
@@ -1,94 +0,0 @@
-
-IPA SCCP message flow in the BSC
-
-February, 2013		Holger Hans Peter Freyther
-
-CONTENTS
-
-1. SCCP inside the IPA header
-2. Supported SCCP message types
-3. Receiving SCCP messages
-4. Sending SCCP messages
-
-
-1. SCCP inside the IPA header
-
-Many Soft-MSCs implement something that is called SCCP/lite. This means
-that SCCP messages are transported inside a small multiplexing protocol
-over TCP/IP. This is an alternative to a full SIGTRAN implementation.
-
-The multiplexing protocol is the same as used with the sysmoBTS and the
-ip.access nanoBTS. It is a three byte header with two bytes for the length
-in network byte order and one byte for the type. The type to be used for
-SCCP is 0xFD.
-
-	struct ipa_header {
-		uint16_t length_in_network_order;
-		uint8_t  type;
-	} __attribute__((packed));
-
-
-
-2. Supported SCCP message types
-
-To implement GSM 08.08 only a subset of SCCP messages need to be implemented.
-For transporting paging and reset messages SCCP UDT messages are used. For
-the connections with a Mobile Station (MS) a SCCP connection is opened. This
-means that the SCCP CR, SCCP CC, SCCP CREF, SCCP RLC, SCCP RLSD, SCCP DT1
-and SCCP IT messages are supported.
-
-
-3. Receiving SCCP UDT messages
-
-This is an illustration of the flow of messages. The IPA multiplexing protocol
-is used for various protocols. This means there is a central place where the
-multiplexing stream terminates. The stream is terminated in the osmo_bsc_msc.c
-file and the ipaccess_a_fd_cb method. For SCCP messages the SCCP dispatching
-sccp_system_incoming method is called. This function is implemented in the
-libosmo-sccp library.
-
-To receive UDT messages osmo_bsc_sccp.c:osmo_bsc_sccp_init is using the
-sccp_set_read function to register a callback for UDT messages. The callback
-is msc_sccp_read and it is calling bsc_handle_udt that is implemented in the
-osmo_bsc_bssap.c. This function will handle the GSM 08.08 BSSAP messages.
-Currently only the reset acknowledge and the paging messages are handled.
-
-The BSC currently does not accept incoming SCCP messages and is only opening
-SCCP connections to the MSC. When opening a connection the callbacks for state
-changes (connection confirmed, released, release complete) are set and a routine
-for handling incoming data. This registration is done in the osmo_bsc_sccp.c
-file and the bsc_create_new_connection method. The name of the callback is
-msc_outgoing_sccp_data and this will call bsc_handle_dt1 that is implemented
-in the osmo_bsc_bssap.c file. This will forward the messages to the right
-Mobile Station (MS).
-
-
-4. Sending SCCP messages
-
-There are three parts to sending that will be explained below. The first part
-is to send an entire SCCP frame (which includes the GSM 08.08 data) to the
-MSC. This is done by first registering the low level sending. sccp_system_init
-is called with the function that is responsible for sending a message. The
-msc_sccp_write_ipa will call the msc_queue_write function with the data and
-the right MSC connection. Below the msc_queue_write the IPA header will be
-prepended to the msg and then send to the MSC.
-
-The BSC supports multiple different A-link connections, the decision to pick
-the right MSC is done in this method. It is either done via the SCCP connection
-or the ctx pointer.
-
-When the BSC is starting a BSS RESET message will be sent to the MSC. The reset
-is created in osmo_bsc_msc.c:initialize_if_needed and sccp_write is called with
-the GSM 08.08 data and the connection to use. The libosmo-sccp library will
-embed it into a SCCP UDT message and call the msc_sccp_write_ipa method.
-
-When a new SCCP connection is to be created the bsc_create_new_connection
-in the osmo_bsc_sccp.c file. The sccp_connection_socket method will create
-the context for a SCCP connection. The state and data callback will be used
-to be notified about data and changes. Once the connection is configured the
-bsc_open_connection will be called that will ask the libosmo-sccp library to
-create a SCCP CR message using the sccp_connection_connect method. For active
-connections the sccp_connection_write method will be called.
-
-
-
diff --git a/doc/oml-interface.txt b/doc/oml-interface.txt
deleted file mode 100644
index 02bead77a..000000000
--- a/doc/oml-interface.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-oml interface design notes
-
-problems:
-
-* there is no way how to tag a command sent to the BTS, with the response
-  having the same tag to identify the originator of the command
-* therefore, we can have e.g. both the BSC and the OML interface send a
-  SET ATTRIBUTE message, where the responses would end up at the wrong
-  query.
-* The BTS has 10s to ACK/NACK a command. We do not run any timers.
-
-the only possible solutions i can imagine:
-* have some kind of exclusive locking, where the OML interface gets blocked
-  from the BSC and is exclusively assigned to the OML console until all commands
-  of the OML console have terminated.  This can either be done explicitly
-  dynamically or on demand
-
-* use the OML interface synchronously, i.e. always wait for the response from
-  the BTS before
-
-* unilateral / unsolicited messages need to be broadcasted to both the BSC and
-  the OML console
diff --git a/doc/osmo-nitb-data_structures.dot b/doc/osmo-nitb-data_structures.dot
deleted file mode 100644
index 81955e8b9..000000000
--- a/doc/osmo-nitb-data_structures.dot
+++ /dev/null
@@ -1,33 +0,0 @@
-digraph G {
-	net [label="gsm_network"]
-	bts [label="gsm_bts"]
-	trx [label="gsm_bts_trx"]
-	ts [label="gsm_bts_trx_ts"]
-	lchan [label="gsm_lchan"]
-	sub [label="gsm_subscriber"]
-	subcon [label="gsm_subscriber_conn"]
-	sccpcon [label="osmo_bsc_sccp_con"]
-	subgrp [label="gsm_subscriber_group"]
-
-	net -> bts
-	bts -> trx
-	trx -> ts
-	ts -> lchan
-
-	lchan -> ts
-	ts -> trx
-	trx -> bts
-	bts -> net
-
-	lchan -> subcon
-
-	subcon -> sub
-	subcon -> sccpcon
-	subcon -> lchan
-	subcon -> lchan [label="ho_lchan"]
-	subcon -> bts
-	subcon -> lchan [label="secondary_lchan"]
-
-	sub -> subgrp
-	subgrp -> net
-}
diff --git a/doc/paging.txt b/doc/paging.txt
deleted file mode 100644
index c597c22b4..000000000
--- a/doc/paging.txt
+++ /dev/null
@@ -1,48 +0,0 @@
-
-GSM Paging implementation in OpenBSC
-
-== Code structure ==
-
-The code is implemented in the libbsc/paging.c file. The external
-interface is documented/specified in the include/openbsc/paging.h
-header file. The code is used by the NITB and BSC application.
-
-
-== Implementation ==
-
-Paging can be initiated in two ways. The standard way is to page by
-LAC. Each BTS has its own list/queue of outstanding paging operation.
-When a subscriber is paged one "struct paging_request" per BTS will
-be allocated and added to the tail of the list. The BTS is supposed
-to be configured to not repeat the paging.
-
-A paging_request will remain in the queue until a paging response or at
-the expiry of the T3113. Every 500 milliseconds a RSL paging command is
-send to the BTS. The 500 milliseconds is a throttling to not crash the
-ip.access nanoBTS. Once one paging_request has been handled it will be
-put at the end of the queue/list and the available slots for the BTS
-will be decreased.
-
-The available slots will be updated based on the paging load information
-element of the CCCH Load indication. If no paging slots are considered
-to be available and no load indication is sent a timer is started. The
-current timeout is 500 milliseconds and at the expiry of the timer the
-available slots will be set to 20.
-
-OpenBSC has the " paging free <-1-1024>" configuration option. In case
-there are less free channels than required no paging request will be
-sent to the BTS. Instead it will be attempted to send the paging request
-at the next timeout (500 milliseconds).
-
-== Limitation ==
-
-The paging throughput could be higher but this has lead to crashes on the
-ip.access nanoBTS in the past.
-
-== Configuration ==
-
-=== ip.access nanoBTS ===
-
-The current CCCH Load indication threshold is 10% and the period is 1 second.
-The code can be found inside the src/libbsc/bts_ipaccess_nanobts.c inside the
-nanobts_attr_bts array.