Fix some typos

Fix typos and common misspellings in code comments and in the manual.

Change-Id: I46fc9d424620c77ae9ccf78b58081bd303386d7c

11 files changed, 21 insertions, 21 deletions

diff --git a/doc/e1-data-model.txt b/doc/e1-data-model.txt
index 509004fe9..06f9f305b 100644
--- a/doc/e1-data-model.txt
+++ b/doc/e1-data-model.txt
@@ -8,7 +8,7 @@ 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
+link.  On a single E1 line, we can easily accommodate up to three BTS with
 two TRX each.
 
 Thus, it is best for OpenBSC to have some kind of abstraction layer.  The BSC's
diff --git a/doc/handover.txt b/doc/handover.txt
index ac19e8725..c5fc33115 100644
--- a/doc/handover.txt
+++ b/doc/handover.txt
@@ -38,7 +38,7 @@ 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
+Level Threshold:		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
diff --git a/doc/manuals/aoip-mgw-options.adoc b/doc/manuals/aoip-mgw-options.adoc
index f69309334..124c03fda 100644
--- a/doc/manuals/aoip-mgw-options.adoc
+++ b/doc/manuals/aoip-mgw-options.adoc
@@ -54,7 +54,7 @@ interoperable A-over-IP (AoIP) interface shall look like.
 
 As more modern MSCs at operators tend to favor implementing 3GPP AoIP
 rather than the proprietary SCCPlite based A interface, it becomes
-neccessary for OsmoBSC to support this.
+necessary for OsmoBSC to support this.
 
 At the same time, for compatibility reasons, the classic SCCPlite
 support shall be kept, if possible with reasonable effort.
diff --git a/doc/manuals/chapters/counters_generated.adoc b/doc/manuals/chapters/counters_generated.adoc
index 65f4ca40b..f668865fd 100644
--- a/doc/manuals/chapters/counters_generated.adoc
+++ b/doc/manuals/chapters/counters_generated.adoc
@@ -22,7 +22,7 @@ These counters and their description based on OsmoBSC 1.4.0.84-3f1f8 (OsmoBSC).
 | codec:fr | <<bts_codec:fr>> | Count the usage of FR codec by channel mode requested.
 | codec:hr | <<bts_codec:hr>> | Count the usage of HR codec by channel mode requested.
 | paging:attempted | <<bts_paging:attempted>> | Paging attempts for a subscriber.
-| paging:already | <<bts_paging:already>> | Paging attempts ignored as subsciber was already being paged.
+| paging:already | <<bts_paging:already>> | Paging attempts ignored as subscriber was already being paged.
 | paging:responded | <<bts_paging:responded>> | Paging attempts with successful paging response.
 | paging:expired | <<bts_paging:expired>> | Paging Request expired because of timeout T3113.
 | chan_act:total | <<bts_chan_act:total>> | Total number of Channel Activations.
@@ -48,7 +48,7 @@ These counters and their description based on OsmoBSC 1.4.0.84-3f1f8 (OsmoBSC).
 | codec:fr | <<bts_codec:fr>> | Count the usage of FR codec by channel mode requested.
 | codec:hr | <<bts_codec:hr>> | Count the usage of HR codec by channel mode requested.
 | paging:attempted | <<bts_paging:attempted>> | Paging attempts for a subscriber.
-| paging:already | <<bts_paging:already>> | Paging attempts ignored as subsciber was already being paged.
+| paging:already | <<bts_paging:already>> | Paging attempts ignored as subscriber was already being paged.
 | paging:responded | <<bts_paging:responded>> | Paging attempts with successful paging response.
 | paging:expired | <<bts_paging:expired>> | Paging Request expired because of timeout T3113.
 | chan_act:total | <<bts_chan_act:total>> | Total number of Channel Activations.
@@ -74,7 +74,7 @@ These counters and their description based on OsmoBSC 1.4.0.84-3f1f8 (OsmoBSC).
 | codec:fr | <<bts_codec:fr>> | Count the usage of FR codec by channel mode requested.
 | codec:hr | <<bts_codec:hr>> | Count the usage of HR codec by channel mode requested.
 | paging:attempted | <<bts_paging:attempted>> | Paging attempts for a subscriber.
-| paging:already | <<bts_paging:already>> | Paging attempts ignored as subsciber was already being paged.
+| paging:already | <<bts_paging:already>> | Paging attempts ignored as subscriber was already being paged.
 | paging:responded | <<bts_paging:responded>> | Paging attempts with successful paging response.
 | paging:expired | <<bts_paging:expired>> | Paging Request expired because of timeout T3113.
 | chan_act:total | <<bts_chan_act:total>> | Total number of Channel Activations.
@@ -105,14 +105,14 @@ These counters and their description based on OsmoBSC 1.4.0.84-3f1f8 (OsmoBSC).
 | assignment:no_channel | <<bsc_assignment:no_channel>> | Failure to allocate lchan for Assignment.
 | assignment:timeout | <<bsc_assignment:timeout>> | Assignment timed out.
 | assignment:failed | <<bsc_assignment:failed>> | Received Assignment Failure message.
-| assignment:error | <<bsc_assignment:error>> | Assigment failed for other reason.
+| assignment:error | <<bsc_assignment:error>> | Assignment failed for other reason.
 | handover:attempted | <<bsc_handover:attempted>> | Intra-BSC handover attempts.
 | handover:completed | <<bsc_handover:completed>> | Intra-BSC handover completed.
 | handover:stopped | <<bsc_handover:stopped>> | Connection ended during HO.
 | handover:no_channel | <<bsc_handover:no_channel>> | Failure to allocate lchan for HO.
 | handover:timeout | <<bsc_handover:timeout>> | Handover timed out.
 | handover:failed | <<bsc_handover:failed>> | Received Handover Fail messages.
-| handover:error | <<bsc_handover:error>> | Re-assigment failed for other reason.
+| handover:error | <<bsc_handover:error>> | Re-assignment failed for other reason.
 | interbsc_ho_out:attempted | <<bsc_interbsc_ho_out:attempted>> | Attempts to handover to remote BSS.
 | interbsc_ho_out:completed | <<bsc_interbsc_ho_out:completed>> | Handover to remote BSS completed.
 | interbsc_ho_out:stopped | <<bsc_interbsc_ho_out:stopped>> | Connection ended during HO.
diff --git a/doc/manuals/chapters/handover.adoc b/doc/manuals/chapters/handover.adoc
index bb99751d3..d9805f78c 100644
--- a/doc/manuals/chapters/handover.adoc
+++ b/doc/manuals/chapters/handover.adoc
@@ -61,7 +61,7 @@ specific BSIC that it reported measurements for.
 
 The BSC is the point of decision whether to do handover or not. This can be a
 hugely complex combination of heuristics, knowledge of cell load and codec
-capabilites. The most important indicator for handover though is: does an MS
+capabilities. The most important indicator for handover though is: does an MS
 report a neighbor with a better signal than the current cell? See
 <<intra_bsc_ho_dot>>.
 
diff --git a/doc/manuals/chapters/osmux_bsc.adoc b/doc/manuals/chapters/osmux_bsc.adoc
index c9f387b20..0a11d17bf 100644
--- a/doc/manuals/chapters/osmux_bsc.adoc
+++ b/doc/manuals/chapters/osmux_bsc.adoc
@@ -33,7 +33,7 @@ command presented above:
   up. If _BSSMAP Assign Request_ from MSC contains _Osmux CID_ IE,
   {program-name} will instruct its MGW to set up an Osmux connection on the
   CN-side of the MGCP endpoint, and will provide the MSC with its _recvCID_
-  through the extension IE _Osmux CID_ appened to the _BSSMAP Assign Complete_
+  through the extension IE _Osmux CID_ appended to the _BSSMAP Assign Complete_
   message. On the other hand, if _BSSMAP Assign Request_ doesn't contain an
   _Osmux CID_ IE, {program-name} will instruct its MGW to set up a regular RTP
   connection on the CN-side of the MGCP endpoint.
diff --git a/doc/manuals/message-sequences/mo_call-abis_a.msc b/doc/manuals/message-sequences/mo_call-abis_a.msc
index 4597ab126..ba7f0aa18 100644
--- a/doc/manuals/message-sequences/mo_call-abis_a.msc
+++ b/doc/manuals/message-sequences/mo_call-abis_a.msc
@@ -107,7 +107,7 @@ linecolor="green"];
 	...;
 	bsc <- m_sc	[label="SCCP DT1 (BSSMAP CLEAR CMD)"];
 	bsc -> bsc 	[label="GSCON_EV_A_CLEAR_CMD", textcolor="red", linecolor="red"];
-	---		[label="BSC must release terrestrial resoures before reporting CLEAR COMPLETE"];
+	---		[label="BSC must release terrestrial resources before reporting CLEAR COMPLETE"];
 	mgw <- bsc	[label="MGCP DLCX rtpbridge/2@mgw", textcolor="blue", linecolor="blue"];
 	mgw box mgw	[label="Release MSC-facing local RTP port (3000)", textcolor="blue", linecolor="blue"];
 	mgw -> bsc	[label="MGCP DLCX rtpbridge/2@mgw OK", textcolor="blue", linecolor="blue"];
diff --git a/doc/manuals/mgw/classic-bsc.msc b/doc/manuals/mgw/classic-bsc.msc
index 56d288997..97b65131e 100644
--- a/doc/manuals/mgw/classic-bsc.msc
+++ b/doc/manuals/mgw/classic-bsc.msc
@@ -1,5 +1,5 @@
 # MO Call on a classic E1 Abis BTS with classic E1 A BSC
-# not actually supported by OsmoBSC (nor planned), for refrence only
+# not actually supported by OsmoBSC (nor planned), for reference only
 msc {
 	hscale=2;
 	ms [label="MS"], bts [label="E1 BTS"], bsc[label="OsmoBSC"], trau[label="TRAU"], m_sc[label="MSC"]; 
diff --git a/doc/manuals/osmux-reference.adoc b/doc/manuals/osmux-reference.adoc
index 929f44203..e28347a3f 100644
--- a/doc/manuals/osmux-reference.adoc
+++ b/doc/manuals/osmux-reference.adoc
@@ -5,7 +5,7 @@
 
 In case of satellite based GSM systems, the transmission cost on the back-haul
 is relatively expensive. The billing for such SAT uplink is usually done in a
-pay-per-byte basis. Thus, reducing the amount of bytes transfered would
+pay-per-byte basis. Thus, reducing the amount of bytes transferred would
 significantly reduce the cost of such uplinks. In such environment, even
 seemingly small protocol optimizations, eg. message batching and trunking, can
 result in significant cost reduction.
@@ -93,7 +93,7 @@ layer 4 protocols are suitable for this application. We detail the reasons
 why:
 
 * TCP is a streaming protocol aimed at maximizing the throughput of a stream
-  withing the constraints of the underlying transport layer.  This feature is
+  within the constraints of the underlying transport layer.  This feature is
   not really required for the low-bandwidth and low-pps GSM signalling.
   Moreover, TCP is stream oriented and does not conserve message boundaries.
   As such, the IPA header has to serve as a boundary between messages in the
@@ -114,7 +114,7 @@ good as TCP does) packet loss and copes with packet re-ordering.
 
 LAPD has a very small header (3-5 octets) compared to TCPs 20 bytes.  Even if
 LAPD is put inside UDP, the combination of 11 to 13 octets still saves a
-noticable number of bytes per packet. Moreover, LAPD has been modified for less
+noticeable number of bytes per packet. Moreover, LAPD has been modified for less
 reliable interfaces such as the GSM Um interface (LAPDm), as well as for the
 use in satellite systems (LAPsat in ETSI GMR).
 
@@ -136,7 +136,7 @@ The following FT values are assigned:
 * FT == 2: Dummy
 * FT == 3: Reserved for Fture Use
 
-There can be any number of OSmux messages batched up in one underlaying packet.
+There can be any number of OSmux messages batched up in one underlying packet.
 In this case, the multiple OSmux messages are simply concatenated, i.e. the
 OSmux header control octet directly follows the last octet of the payload of the
 previous OSmux message.
@@ -224,7 +224,7 @@ need to have independent timestamp and sequence numbers (related to a 8kHz
 clock) as specified in AMR-RTP.
 
 AMR Codec Mode Request (AMR-FT): 4 bits::
-This is a mapping from te AMR FT field (Frame type index) in RFC3267 Section
+This is a mapping from the AMR FT field (Frame type index) in RFC3267 Section
 4.3.2. The length of each codec frame needs to be determined from this field. It
 is thus guaranteed that all frames for a specific stream in an OSmux batch are
 of the same AMR type.
@@ -356,7 +356,7 @@ msc {
 
 === Batching
 
-Following chart shows how batching with a factor of 3 works. To easilly
+Following chart shows how batching with a factor of 3 works. To easily
 illustrate batching, only uplink and one concurrent call is considered.
 
 It can be seen how 3 RTP packets from MSa arrive to the BSC from the BTS. The
@@ -559,7 +559,7 @@ more concurrent calls.
 
 A batching factor of 8 provides very little improvement with regards to batching
 4 messages. Still, we risk to degrade user experience. Thus, we consider a
-batching factor of 3 and 4 is adecuate.
+batching factor of 3 and 4 is adequate.
 
 == Other proposed follow-up works
 
diff --git a/doc/manuals/vty/bsc_vty_reference.xml b/doc/manuals/vty/bsc_vty_reference.xml
index 178e5b573..84010436e 100644
--- a/doc/manuals/vty/bsc_vty_reference.xml
+++ b/doc/manuals/vty/bsc_vty_reference.xml
@@ -1336,7 +1336,7 @@
         <param name='&lt;0-255&gt;' doc='BTS Number' />
         <param name='smscb-command' doc='SMS Cell Broadcast' />
         <param name='normal' doc='Normal (one-shot) SMSCB Message; sent once over Abis+Um' />
-        <param name='schedule' doc='Schedule (one-shot) SMSCB Messag; sent once over Abis+Um' />
+        <param name='schedule' doc='Schedule (one-shot) SMSCB Message; sent once over Abis+Um' />
         <param name='default' doc='Default (repeating) SMSCB Message; sent once over Abis, unlimited ovrer Um' />
         <param name='&lt;1-4&gt;' doc='Last Valid Block' />
         <param name='HEXSTRING' doc='Hex Encoded SMSCB message (up to 88 octets)' />
diff --git a/doc/manuals/vty/libbsc_vty_additions.xml b/doc/manuals/vty/libbsc_vty_additions.xml
index dbf408014..869625235 100644
--- a/doc/manuals/vty/libbsc_vty_additions.xml
+++ b/doc/manuals/vty/libbsc_vty_additions.xml
@@ -118,7 +118,7 @@
         <description>
 	  The periodic location updating interval determines how often
 	  the MS will periodically perform a LOCATION UPDATE procedure,
-	  despite not having actuall changed location.  The value is
+	  despite not having actually changed location.  The value is
 	  specified in minutes.
 	</description>
       </command>