diff options
author | Neels Hofmeyr <neels@hofmeyr.de> | 2017-09-04 03:27:02 +0200 |
---|---|---|
committer | Neels Hofmeyr <neels@hofmeyr.de> | 2017-09-06 16:25:08 +0200 |
commit | 5282a81323633b26ee79dc6df4ba971067cdc857 (patch) | |
tree | e0523a71b2424e32d51ccf7eb55b00aaa0aff80c /doc | |
parent | 630df7d608579aa7046c9a4e7b170c5acf4383cf (diff) |
drop files unrelated to osmo-bsc
These either remain from openbsc.git or slipped in while applying recent
patches from openbsc.git and do not belong in osmo-bsc.
Empty out contrib: remove things that are either obviously unrelated to
osmo-bsc, or seem old and/or esoteric.
osmoappdesc.py: drop nitb_e1_configs (and some ws)
Change-Id: Ib20064f35e623d99c7d59496a3156e84b8a0d07a
Diffstat (limited to 'doc')
-rw-r--r-- | doc/call-routing.txt | 25 | ||||
-rw-r--r-- | doc/channel_release.txt | 95 | ||||
-rw-r--r-- | doc/examples/osmo-bsc_mgcp/mgcp.cfg | 19 | ||||
-rw-r--r-- | doc/examples/osmo-gbproxy/osmo-gbproxy-legacy.cfg | 44 | ||||
-rw-r--r-- | doc/examples/osmo-gbproxy/osmo-gbproxy.cfg | 25 | ||||
-rw-r--r-- | doc/examples/osmo-gtphub/gtphub-example.txt | 90 | ||||
-rw-r--r-- | doc/examples/osmo-gtphub/osmo-gtphub-1iface.cfg | 25 | ||||
-rw-r--r-- | doc/examples/osmo-gtphub/osmo-gtphub.cfg | 25 | ||||
-rw-r--r-- | doc/examples/osmo-msc/osmo-msc.cfg | 19 | ||||
-rw-r--r-- | doc/examples/osmo-sgsn/osmo-sgsn-accept-all.cfg | 27 | ||||
-rw-r--r-- | doc/examples/osmo-sgsn/osmo-sgsn.cfg | 29 | ||||
-rw-r--r-- | doc/gsm-hopping.txt | 54 | ||||
-rw-r--r-- | doc/ipa-sccp.txt | 94 | ||||
-rw-r--r-- | doc/oml-interface.txt | 22 | ||||
-rw-r--r-- | doc/osmo-nitb-data_structures.dot | 33 | ||||
-rw-r--r-- | doc/paging.txt | 48 |
16 files changed, 0 insertions, 674 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/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/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-gbproxy/osmo-gbproxy-legacy.cfg b/doc/examples/osmo-gbproxy/osmo-gbproxy-legacy.cfg deleted file mode 100644 index 15fd74a2b..000000000 --- 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 0c3917a3e..000000000 --- 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 9c65f925f..000000000 --- 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 3913d2c3c..000000000 --- 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 0dc415047..000000000 --- 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 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/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/examples/osmo-sgsn/osmo-sgsn.cfg b/doc/examples/osmo-sgsn/osmo-sgsn.cfg deleted file mode 100644 index 06f035f1b..000000000 --- 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 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/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. |