diff --git a/doc/manuals/aoip-mgw-options.adoc b/doc/manuals/aoip-mgw-options.adoc
index f693093..124c03f 100644
--- a/doc/manuals/aoip-mgw-options.adoc
+++ b/doc/manuals/aoip-mgw-options.adoc
@@ -54,7 +54,7 @@
 
 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 65f4ca4..f668865 100644
--- a/doc/manuals/chapters/counters_generated.adoc
+++ b/doc/manuals/chapters/counters_generated.adoc
@@ -22,7 +22,7 @@
 | 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 @@
 | 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 @@
 | 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 @@
 | 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 bb99751..d9805f7 100644
--- a/doc/manuals/chapters/handover.adoc
+++ b/doc/manuals/chapters/handover.adoc
@@ -61,7 +61,7 @@
 
 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 c9f387b..0a11d17 100644
--- a/doc/manuals/chapters/osmux_bsc.adoc
+++ b/doc/manuals/chapters/osmux_bsc.adoc
@@ -33,7 +33,7 @@
   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 4597ab1..ba7f0aa 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 @@
 	...;
 	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 56d2889..97b6513 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 929f442..e28347a 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 @@
 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 @@
 
 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 @@
 * 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 @@
 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 @@
 
 === 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 @@
 
 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 178e5b5..8401043 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 dbf4080..8696252 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>