doc/users-guide: further wording suggestions generated using llm

llm instructions: "The following reStructuredText file is part of the
INET Framework for OMNeT++. At places where it addresses the user
as 'you', change it to neutral, e.g. to passive voice or 'one' as subject.
Keep all markup and line breaks intact as much as possible!
Lines starting with '..' are comments, do not touch them!"

doc/src/users-guide/ch-80211.rst

@@ -67,16 +67,16 @@ the standard, IEEE 802.11-2012 Part 11: Wireless LAN Medium Access Control (MAC)
 and Physical Layer (PHY) Specifications.
 
 The :ned:`Ieee80211Mac` performs transmission of frames according to the
-CSMA/CA protocol. It receives data and management frames from the upper
-layers, and transmits them.
+CSMA/CA protocol. Data and management frames are received from the upper
+layers and transmitted using the :ned:`Ieee80211Radio`.
 
-The :ned:`Ieee80211Mac` was designed to be modular to facilitate
-experimenting with new policies, features, and algorithms within the MAC
-layer. Users can easily replace individual components with their own
+The :ned:`Ieee80211Mac` was designed with modularity in mind to facilitate
+experimentation with new policies, features, and algorithms within the MAC
+layer. Individual components can be easily replaced with custom
 implementations. Policies, which are most likely to be experimented with,
 are extracted into their own modules.
 
-The new model also separates the following components in the 802.11 standard
+The new model also separates the following components from the 802.11 standard
 into modules:
 
 -  Coordination function: :ned:`Dcf`, :ned:`Hcf`. The coordination functions
@@ -135,7 +135,7 @@ into modules:
      higher layers, waiting for transmission unchanged.
 
 -  :ned:`InProgressFrames`: This modules is a queue containing frames waiting
-     for transmission already processed by the MAC data service.
+     for transmission that have been processed by the MAC data service.
 
 -  TX/RX (:ned:`Tx`, :ned:`Rx`). Responsible for simple frame
    transmission/reception.
@@ -155,7 +155,7 @@ The MAC model has the following replaceable built-in policy submodules by defaul
 .. , with the default modules in parentheses:
 
 -  ACK policy (e.g. :ned:`OriginatorAckPolicy`, :ned:`RecipientAckPolicy`):
-   controls what kind of acknowledgment is used per-frame (none, normal,
+   controls the type of acknowledgment used per-frame (none, normal,
    block-ack)
 
 -  RTS/CTS policy (e.g. :ned:`RtsPolicy`, :ned:`CtsPolicy`): determines which
@@ -167,12 +167,12 @@ The MAC model has the following replaceable built-in policy submodules by defaul
    agreements are made
 
 -  MSDU aggregation policy (e.g. :ned:`BasicMsduAggregationPolicy`): controls
-   when and which frames are aggregated into an A-MSDU
+   which frames are aggregated into an A-MSDU and when
 
 -  Fragmentation policy (e.g. :ned:`BasicFragmentationPolicy`): controls when
-   and how fragmentation happens
+   and how fragmentation occurs
 
-.. For example, a lot of these modules are located in the *hcf* submodule of the MAC:
+.. For example, many of these modules are located in the *hcf* submodule of the MAC:
 
    .. figure:: figures/hcf.png
       :align: center
@@ -217,7 +217,7 @@ The management layer has several implementations which differ in their
 role (STA/AP/ad-hoc) and level of detail: :ned:`Ieee80211MgmtAdhoc`,
 :ned:`Ieee80211MgmtAp`, :ned:`Ieee80211MgmtApSimplified`,
 :ned:`Ieee80211MgmtSta`, :ned:`Ieee80211MgmtStaSimplified`. The
-..Simplified ones differ from the others in that they do not model the
+..Simplified ones differ from the others in that they do not simulate the
 scan-authenticate-associate process, so they cannot be used in
 experiments involving handover.
 
@@ -233,10 +233,9 @@ association procedures and reports back the results to the agent.
 
 The agent component is currently only needed with the
 :ned:`Ieee80211MgmtSta` module. The management entities in other NIC
-variants do not have as much freedom as to need an agent to control
-them.
+variants do not have as much freedom and do not require an agent.
 
 :ned:`Ieee80211MgmtSta` requires an :ned:`Ieee80211AgentSta` or a custom
 agent. By modifying or replacing the agent, one can alter the dynamic
-behavior of STAs in the network, for example, implement different
+behavior of STAs in the network, for example, implementing different
 handover strategies.

doc/src/users-guide/ch-802154.rst

@@ -19,22 +19,22 @@ IEEE 802.15.4 is the basis for the :protocol:`ZigBee`, :protocol:`ISA100.11a`,
 :protocol:`Thread` specifications, each of which further extends the standard by
 developing the upper layers that are not defined in IEEE 802.15.4.
 Alternatively, it can be used with :protocol:`6LoWPAN`, the technology used to
-deliver IPv6 over WPANs, to define the upper layers. (Thread is also
+deliver IPv6 over WPANs, in order to define the upper layers. (Thread is also
 6LoWPAN-based.)
 
-The INET Framework contains a basic implementation of the IEEE 802.15.4
-protocol.
+A basic implementation of the IEEE 802.15.4
+protocol is provided by the INET Framework.
 
 .. _ug:sec:802154:network-interfaces:
 
 Network Interfaces
 ------------------
 
-There are two network interfaces that differ in the type of radio:
+Two network interfaces differing in the type of radio are available:
 
-- :ned:`Ieee802154NarrowbandInterface` is for use with narrowband radios
+- :ned:`Ieee802154NarrowbandInterface` is for use with narrowband radios.
 
-- :ned:`Ieee802154UwbIrInterface` is for use with the UWB-IR radio
+- :ned:`Ieee802154UwbIrInterface` is for use with the UWB-IR radio.
 
 In order to create a wireless node with an 802.15.4 interface, use a node type that has a
 wireless interface and set the interface type to the appropriate type. For
@@ -51,21 +51,18 @@ to use 802.15.4 with the following line in the ini file:
 Physical Layer
 --------------
 
-The IEEE 802.15.4 standard defines several alternative PHYs. There are several
-narrowband radios at various frequency bands using various modulation schemes
-(DSSS, O-QPSK, MPSK, GFSK BPSK, etc.), a Direct Sequence ultra-wideband (UWB),
-and one using chirp spread spectrum (CSS).
+The IEEE 802.15.4 standard defines several alternative PHYs. Various frequency bands, modulation schemes (DSSS, O-QPSK, MPSK, GFSK BPSK, etc.), and  narrowband radios are deployed. The standard also includes a Direct Sequence ultra-wideband (UWB) radio and one using chirp spread spectrum (CSS).
 
 INET provides the following radios:
 
 - :ned:`Ieee802154NarrowbandScalarRadio` is currently a partially parameterized
-  version of the APSK radio. Before using this radio, one must check its
-  parameters and make sure that they correspond to the specification of the
-  802.15.4 narrowband PHY to be simulated.
+  version of the APSK radio. Before using this radio, the radio's parameters must be checked
+  and ensure their correspondence to the specification of the
+  narrowband PHY being simulated.
 
 - :ned:`Ieee802154UwbIrRadio` models the 802.14.5 UWB radio.
 
-One must choose a matching medium model, for example
+To match the radios, a relevant medium model should be chosen. For instance,
 :ned:`Ieee802154UwbIrRadioMedium` for :ned:`Ieee802154UwbIrRadio`, and
 :ned:`Ieee802154NarrowbandScalarRadioMedium` for
 :ned:`Ieee802154NarrowbandScalarRadio`.

doc/src/users-guide/ch-adhoc-routing.rst

@@ -8,22 +8,22 @@ Ad Hoc Routing
 Overview
 --------
 
-In ad hoc networks, nodes are not familiar with the topology of their
-networks. Instead, they have to discover it: typically, a new node
-announces its presence and listens for announcements broadcast by its
-neighbors. Each node learns about others nearby and how to reach them,
-and may announce that it too can reach them. The difficulty of routing
-may be compounded by the fact that nodes may be mobile, which results in
-a changing topology.
-
-Ad hoc routing protocols fall into two broad categories: proactive and
-reactive. *Proactive* or *table-driven* protocols maintain fresh lists
-of destinations and their routes by periodically distributing routing
-tables throughout the network. *Reactive* or *on-demand* protocols find
-a route on demand by flooding the network with Route Request packets.
-
-The INET Framework contains the implementation of several ad hoc routing
-protocols including :protocol:`AODV`, :protocol:`DSDV`, :protocol:`DYMO`
+In ad hoc networks, the topology of the network is not known to the nodes.
+Instead, the topology must be discovered. When a new node joins the network,
+it announces its presence and listens for announcements from its neighbors.
+Each node learns about nearby nodes and how to reach them, and it may also
+announce that it can reach other nodes. The task of routing in ad hoc
+networks is complicated by the fact that nodes may be mobile, resulting in a
+changing topology.
+
+There are two types of ad hoc routing protocols: proactive and reactive.
+*Proactive* or *table-driven* protocols maintain up-to-date lists of
+destinations and their routes by periodically distributing routing tables
+throughout the network. *Reactive* or *on-demand* protocols find a route
+on-demand by flooding the network with Route Request packets.
+
+The INET Framework includes the implementation of several ad hoc routing
+protocols, including :protocol:`AODV`, :protocol:`DSDV`, :protocol:`DYMO`,
 and :protocol:`GPSR`.
 
 The easiest way to add routing to an ad hoc network is to use the
@@ -40,16 +40,17 @@ file:
    **.routing.typename = "Gpsr" # as a routing protocol module
 
 There are also NED types called :ned:`AodvRouter`, :ned:`DymoRouter`,
-:ned:`DsdvRouter`, :ned:`GpsrRouter`, which are all :ned:`ManetRouter`’s
-with the routing protocol submodule type set appropriately.
+:ned:`DsdvRouter`, and :ned:`GpsrRouter`. These types are all based on
+:ned:`ManetRouter` and have the routing protocol submodule type set
+appropriately.
 
 .. _ug:sec:adhocrouting:aodv:
 
 AODV
 ----
 
-AODV (Ad hoc On-Demand Distance Vector Routing) is a routing protocol
-for mobile ad hoc networks and other wireless ad hoc networks. It offers
+AODV (Ad hoc On-Demand Distance Vector Routing) is a routing protocol for
+mobile ad hoc networks and other wireless ad hoc networks. It provides
 quick adaptation to dynamic link conditions, low processing and memory
 overhead, low network utilization, and determines unicast routes to
 destinations within the ad hoc network.

doc/src/users-guide/ch-apps.rst

@@ -18,8 +18,8 @@ implement very specific behaviors, and generate corresponding traffic patterns
 based on their specific parameters. These applications are implemented as simple
 modules.
 
-In the second category, applications are more generic. They separate traffic
-generation from the usage of the protocol, :ned:`Udp` or :ned:`Tcp` for example.
+In the second category, applications are more generic. Traffic
+generation is separated from the usage of the protocol, such as :ned:`Udp` or :ned:`Tcp`.
 These applications are implemented as compound modules. They contain separate
 configurable traffic source, traffic sink, and protocol input/output submodules.
 This approach allows building complex traffic patterns by composing queuing
@@ -44,7 +44,7 @@ server model can be kept simple and dumb.
 TcpBasicClientApp
 ~~~~~~~~~~~~~~~~~
 
-Client for a generic request-response style protocol over TCP. May be
+A client for a generic request-response style protocol over TCP. It may be
 used as a rough model of HTTP or FTP users.
 
 The model communicates with the server in sessions. During a session,
@@ -91,15 +91,15 @@ sending the response, while in this model, it is the client.
 TcpSinkApp
 ~~~~~~~~~~
 
-Accepts any number of incoming TCP connections and discards whatever
+This module accepts any number of incoming TCP connections and discards whatever
 arrives on them.
 
 .. _ug:sec:apps:tcpgenericserverapp:
 
 TcpGenericServerApp
 ~~~~~~~~~~~~~~~~~~~
 
-Generic server application for modeling TCP-based request-reply style
+A generic server application for modeling TCP-based request-reply style
 protocols or applications.
 
 The module accepts any number of incoming TCP connections and expects
@@ -124,10 +124,10 @@ also be delayed by a constant time (:par:`echoDelay` parameter).
 TcpSessionApp
 ~~~~~~~~~~~~~
 
-Single-connection TCP application: it opens a connection, sends the
+A single-connection TCP application: it opens a connection, sends the
 given number of bytes, and closes. Sending may be one-off, or may be
-controlled by a “script” which is a series of (time, number of bytes)
-pairs. May act either as client or as server. Compatible with both IPv4
+controlled by a "script" which is a series of (time, number of bytes)
+pairs. It may act either as a client or as a server. Compatible with both IPv4
 and IPv6.
 
 Opening the connection
@@ -136,7 +136,7 @@ Opening the connection
 Depending on the type of opening the connection (active/passive), the
 application may be either a client or a server. In passive mode, the
 application will listen on the given local local port and wait for an
-incoming connection. In active mode, the application will bind to given
+incoming connection. In active mode, the application will bind to the given
 local local address and local port and connect to the given address and
 port. It is possible to use an ephemeral port as a local port.
 
@@ -194,8 +194,8 @@ In this model, the client repeats the following activity between
 4. If the connection is broken, it is noticed after
    :par:`reconnectInterval`, and the connection is reopened
 
-All parameters in the above description are marked as ``volatile``, allowing for using
-distributions to emulate random behavior.
+All parameters in the above description are marked as ``volatile``,
+allowing for using distributions to emulate random behavior.
 
 .. note::
 
@@ -349,13 +349,13 @@ broadcast messages.
 INET also defines several NED functions that can be useful:
 
 -  | ``moduleListByPath("pattern",...)``:
-   | Returns a space-separated list of the modulenames. All modules
+   | Returns a space-separated list of the module names. All modules
      whose full path matches one of the pattern parameters will be
-     included. The patterns may contain wilcards in the same syntax as
+     included. The patterns may contain wildcards in the same syntax as
      in ini files. Example:
 
 -  | ``moduleListByNedType("fully.qualified.ned.type",...)``:
-   | Returns a space-separated list of the modulenames with the given
+   | Returns a space-separated list of the module names with the given
      NED type(s). All modules whose NED type name occurs in the
      parameter list will be included. The NED type name is fully
      qualified. Example:
@@ -369,7 +369,7 @@ Examples:
    **.app[0].destAddresses = moduleListByPath("**.host[*]", "**.fixhost[*]")
    **.app[1].destAddresses = moduleListByNedType("inet.nodes.inet.StandardHost")
 
-The peer can be UdpSink or another UdpBasicBurst.
+The peer can be `UdpSink` or another `UdpBasicBurst`.
 
 Bursts
 ^^^^^^
@@ -417,7 +417,7 @@ network layer only; they do not need transport layer protocols. They can
 be used with both IPv4 and IPv6.
 
 :ned:`IIpvxTrafficGenerator` (prototype) sends IP or IPv6 datagrams to
-the given address at the given :par:`sendInterval`. The
+the given address at the specified :par:`sendInterval`. The
 :par:`sendInterval` parameter can be a constant or a random value (e.g.,
 ``exponential(1)``). If the :par:`destAddresses` parameter contains
 more than one address, one of them is randomly chosen for each packet. An