drop files unrelated to osmo-msc

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

Empty out contrib: remove things that are either obviously unrelated to
osmo-msc, or seem old and/or esoteric.

Change-Id: I49957769e09eed6d723bf7c3777024b62b3480fd

9 files changed, 0 insertions, 555 deletions

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/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_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-sgsn/osmo-sgsn-accept-all.cfg b/doc/examples/osmo-sgsn/osmo-sgsn-accept-all.cfg
deleted file mode 100644
index 5e6434263..000000000
--- a/doc/examples/osmo-sgsn/osmo-sgsn-accept-all.cfg
+++ /dev/null
@@ -1,27 +0,0 @@
-!
-! Osmocom SGSN configuration
-!
-!
-line vty
- no login
-!
-sgsn
- gtp local-ip 127.0.0.1
- ggsn 0 remote-ip 127.0.0.2
- ggsn 0 gtp-version 1
- auth-policy accept-all
-!
-ns
- timer tns-block 3
- timer tns-block-retries 3
- timer tns-reset 3
- timer tns-reset-retries 3
- timer tns-test 30
- timer tns-alive 3
- timer tns-alive-retries 10
- encapsulation udp local-ip 127.0.0.1
- encapsulation udp local-port 23000
- encapsulation framerelay-gre enabled 0
-!
-bssgp
-!
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/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.