This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.
Neels Hofmeyr gerrit-no-reply at lists.osmocom.org
Review at https://gerrit.osmocom.org/3791
prune doc/
Remove files that are obviously unrelated to osmo-bsc or seem outdated.
Change-Id: I464443af7a62b698e4cd0b85e4fa65c921ffc271
---
D doc/call-routing.txt
D doc/channel_release.txt
D doc/examples/osmo-bsc_mgcp/mgcp.cfg
D doc/examples/osmo-gbproxy/osmo-gbproxy-legacy.cfg
D doc/examples/osmo-gbproxy/osmo-gbproxy.cfg
D doc/examples/osmo-gtphub/gtphub-example.txt
D doc/examples/osmo-gtphub/osmo-gtphub-1iface.cfg
D doc/examples/osmo-gtphub/osmo-gtphub.cfg
D doc/examples/osmo-msc/osmo-msc.cfg
D doc/examples/osmo-sgsn/osmo-sgsn-accept-all.cfg
D doc/examples/osmo-sgsn/osmo-sgsn.cfg
D doc/gsm-hopping.txt
D doc/ipa-sccp.txt
D doc/oml-interface.txt
D doc/osmo-nitb-data_structures.dot
D doc/paging.txt
16 files changed, 0 insertions(+), 674 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/osmo-bsc refs/changes/91/3791/1
diff --git a/doc/call-routing.txt b/doc/call-routing.txt
deleted file mode 100644
index 3402f9e..0000000
--- 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 c9cdfeb..0000000
--- 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/examples/osmo-bsc_mgcp/mgcp.cfg b/doc/examples/osmo-bsc_mgcp/mgcp.cfg
deleted file mode 100644
index 3c43f1f..0000000
--- 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-gbproxy/osmo-gbproxy-legacy.cfg b/doc/examples/osmo-gbproxy/osmo-gbproxy-legacy.cfg
deleted file mode 100644
index 15fd74a..0000000
--- a/doc/examples/osmo-gbproxy/osmo-gbproxy-legacy.cfg
+++ /dev/null
@@ -1,44 +0,0 @@
-!
-! OsmoGbProxy (UNKNOWN) configuration saved from vty
-!!
-!
-log stderr
- logging filter all 1
- logging color 1
- logging timestamp 0
- logging level all debug
- logging level gprs debug
- logging level ns info
- logging level bssgp 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
-!
-ns
- nse 666 nsvci 666
- nse 666 remote-role sgsn
-! nse 666 encapsulation framerelay-gre
-! nse 666 remote-ip 172.16.1.70
-! nse 666 fr-dlci 666
- 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-port 23000
-! encapsulation framerelay-gre enabled 1
-gbproxy
- sgsn nsei 666
- core-mobile-country-code 666
- core-mobile-network-code 6
- core-access-point-name none match-imsi ^666066|^66607
- tlli-list max-length 200
diff --git a/doc/examples/osmo-gbproxy/osmo-gbproxy.cfg b/doc/examples/osmo-gbproxy/osmo-gbproxy.cfg
deleted file mode 100644
index 0c3917a..0000000
--- a/doc/examples/osmo-gbproxy/osmo-gbproxy.cfg
+++ /dev/null
@@ -1,25 +0,0 @@
-!
-! Osmocom Gb Proxy (0.9.0.404-6463) configuration saved from vty
-!!
-!
-line vty
- no login
-!
-gbproxy
- sgsn nsei 101
-ns
- nse 101 nsvci 101
- nse 101 remote-role sgsn
- nse 101 encapsulation udp
- nse 101 remote-ip 192.168.100.239
- nse 101 remote-port 7777
- 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 framerelay-gre enabled 0
- encapsulation framerelay-gre local-ip 0.0.0.0
- encapsulation udp local-port 23000
diff --git a/doc/examples/osmo-gtphub/gtphub-example.txt b/doc/examples/osmo-gtphub/gtphub-example.txt
deleted file mode 100644
index 9c65f92..0000000
--- a/doc/examples/osmo-gtphub/gtphub-example.txt
+++ /dev/null
@@ -1,90 +0,0 @@
-Here is a simple setup to test GTPHub operations. The IP addresses picked will
-work well only on a system that creates local addresses (127.0.0.123) on the
-fly (like linux) -- you may pick of course different IP addresses.
-
-Overview of the example setup:
-
- sgsnemu gtphub ggsn
- 127.0.0.1 <--> 127.0.0.3 127.0.0.4 <--> 127.0.0.2
-
-Prerequisites: openggsn.
-
-Have a local directory where you store config files and from which you launch
-the GSNs and the hub (they will store restart counter files in that dir).
-In it, have these config files:
-
-ggsn.conf:
-
- # GGSN local address
- listen 127.0.0.2
-
- # End User Addresses are picked from this range
- net 10.23.42.0/24
-
- pcodns1 8.8.8.8
-
- logfile /tmp/foo
-
-gtphub.conf:
-
- gtphub
- bind-to-sgsns 127.0.0.3
- bind-to-ggsns 127.0.0.4
- ggsn-proxy 127.0.0.2
- end
-
-
-(
-You may omit the ggsn-proxy if GRX ares is working, or if you add the GRX
-address and GGSN IP address to /etc/hosts something like:
-
- 127.0.0.2 internet.mnc070.mcc901.gprs
-
-)
-
-
-Once the config files are in place, start the programs, in separate terminals.
-GGSN and SGSN need to be started with root priviliges to be able to create tun
-interfaces. GTPHub may run as unprivileged user.
-
-The LD_LIBRARY_PATH below may be needed if OpenGGSN installed to /usr/local.
-
-
-1. GGSN:
-
- sudo -s
- cd <your-test-dir>
- LD_LIBRARY_PATH=/usr/local/lib /usr/local/bin/ggsn -f -c ./ggsn.conf
-
-2. GTPHub:
-
- cd <your-test-dir>
- path/to/openbsc/openbsc/src/gprs/osmo-gtphub -c gtphub.conf #-e 1 #for DEBUG level
-
-3. SGSN tests:
-
- sudo -s
- cd <your-test-dir>
- /usr/local/bin/sgsnemu --createif -l 127.0.0.1 -r 127.0.0.3 --imsi 420001214365100 --contexts=3
-
-Add more SGSNs using different IMSIs and local ports (if the same IMSI is used,
-the GGSN will reuse TEIs and tunnels will be discarded automatically):
-
- /usr/local/bin/sgsnemu --createif -l 127.0.0.11 -r 127.0.0.3 --imsi 420001214365300 --contexts=3
-
-This shows the basic setup of GTPHub. Testing internet traffic via sgsnemu
-still needs some effort to announce a mobile subscriber or the like (I have
-used a real BTS, osmo-sgsn and a testing SIM in a web phone, instead).
-
-The core capability of GTPHub is to manage more than two GSNs, e.g. an SGSN
-contacting various GGSNs over the single GTPHub link. You would configure the
-SGSN to use one fixed GGSN (sending to gtphub) and gtphub will resolve the
-GGSNs once it has received the messages. So the SGSN may be behind NAT (add
-"sgsn-use-sender" to gtphub.conf) and communicate to various GGSNs over a
-single link to gtphub.
-
-I hope this helps to get you going.
-Any suggestions/patches are welcome!
-
-~Neels
-
diff --git a/doc/examples/osmo-gtphub/osmo-gtphub-1iface.cfg b/doc/examples/osmo-gtphub/osmo-gtphub-1iface.cfg
deleted file mode 100644
index 3913d2c..0000000
--- a/doc/examples/osmo-gtphub/osmo-gtphub-1iface.cfg
+++ /dev/null
@@ -1,25 +0,0 @@
-!
-! Osmocom gtphub configuration
-!
-! This file is used for VTY tests, referenced by openbsc/osmoappdesc.py
-! For the test, try to use most config commands.
-!
-
-line vty
- no login
-
-gtphub
- ! Local addresses to listen on and send from, both on one interface.
- ! The side towards SGSN uses nonstandard ports.
- bind-to-sgsns ctrl 127.0.0.1 12123 user 127.0.0.1 12153
- ! The GGSN side with standard ports.
- bind-to-ggsns 127.0.0.1
-
- ! Proxy: unconditionally direct all traffic to...
- sgsn-proxy 127.0.0.4
-
- ! Proxy with nonstandard ports or separate IPs:
- ggsn-proxy ctrl 127.0.0.3 2123 user 127.0.0.5 2152
-
- ! Add a name server for GGSN resolution
- grx-dns-add 192.168.0.1
diff --git a/doc/examples/osmo-gtphub/osmo-gtphub.cfg b/doc/examples/osmo-gtphub/osmo-gtphub.cfg
deleted file mode 100644
index 0dc4150..0000000
--- a/doc/examples/osmo-gtphub/osmo-gtphub.cfg
+++ /dev/null
@@ -1,25 +0,0 @@
-!
-! Osmocom gtphub configuration
-!
-
-line vty
- no login
-
-gtphub
- ! Local addresses to listen on and send from, each on standard ports
- ! 2123 and 2152. Setting these addresses is mandatory.
- bind-to-sgsns 127.0.0.1
- bind-to-ggsns 127.0.0.2
-
- ! Local nonstandard ports or separate IPs:
- !bind-to-sgsns ctrl 127.0.0.1 2342 user 127.0.0.1 4223
-
- ! Proxy: unconditionally direct all traffic to...
- !ggsn-proxy 127.0.0.3
- !sgsn-proxy 127.0.0.4
-
- ! Proxy with nonstandard ports or separate IPs:
- !ggsn-proxy ctrl 127.0.0.3 2123 user 127.0.0.5 2152
-
- ! Add a name server for GGSN resolution
- !grx-dns-add 192.168.0.1
diff --git a/doc/examples/osmo-msc/osmo-msc.cfg b/doc/examples/osmo-msc/osmo-msc.cfg
deleted file mode 100644
index 1b1d192..0000000
--- 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/examples/osmo-sgsn/osmo-sgsn-accept-all.cfg b/doc/examples/osmo-sgsn/osmo-sgsn-accept-all.cfg
deleted file mode 100644
index 5e64342..0000000
--- 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/examples/osmo-sgsn/osmo-sgsn.cfg b/doc/examples/osmo-sgsn/osmo-sgsn.cfg
deleted file mode 100644
index 06f035f..0000000
--- a/doc/examples/osmo-sgsn/osmo-sgsn.cfg
+++ /dev/null
@@ -1,29 +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 remote
- gsup remote-ip 127.0.0.1
- gsup remote-port 4222
-!
-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 c964963..0000000
--- 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/ipa-sccp.txt b/doc/ipa-sccp.txt
deleted file mode 100644
index 5d6719e..0000000
--- 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 02bead7..0000000
--- 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 81955e8..0000000
--- 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 c597c22..0000000
--- 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.
--
To view, visit https://gerrit.osmocom.org/3791
To unsubscribe, visit https://gerrit.osmocom.org/settings
Gerrit-MessageType: newchange
Gerrit-Change-Id: I464443af7a62b698e4cd0b85e4fa65c921ffc271
Gerrit-PatchSet: 1
Gerrit-Project: osmo-bsc
Gerrit-Branch: master
Gerrit-Owner: Neels Hofmeyr <nhofmeyr at sysmocom.de>