diff --git a/docs/imsi-pseudo-spec.adoc b/docs/imsi-pseudo-spec.adoc
index 39ccac8..54030a5 100644
--- a/docs/imsi-pseudo-spec.adoc
+++ b/docs/imsi-pseudo-spec.adoc
@@ -4,58 +4,96 @@
 
 === Protecting the IMSI on the Radio Interface is Desirable
 
-A long-standing issue in the 3GPP specifications is, that mobile phones and
+A long-standing issue in the 3GPP specifications for cellular mobile
+communications starting from 2G (GSM) is, that mobile phones and
 other mobile equipment (ME) have to send the International Mobile Subscriber
-Identity (IMSI) unencrypted over the air. Each IMSI is a unique identifier for
-the subscriber. Therefore most people can be uniquely identified by recording
-the IMSI that their ME is sending.  The 3GPP specifications provide means for
-implementations to send the IMSI less often by using the Temporary Mobile
-Subscriber Identity (TMSI) where possible.
+Identity (IMSI) unencrypted over the air.  Each IMSI is a unique identifier for
+the subscriber. Therefore, most people can be uniquely identified by recording
+the IMSI that their ME is sending.
 
-But this is not enough. So-called IMSI catchers were invented and are used to
-not only record IMSIs when they have to be sent. But also to force ME to send
-their IMSI by imitating a Base Transceiver Station (BTS). IMSI catchers have
-become small and affordable, even criminals actors without much budget can use
-them to track anybody with a mobile phone.
+The 3GPP specifications provide means for implementations to send the
+IMSI less often by using the Temporary Mobile Subscriber Identity (TMSI)
+where possible.  However, the decision on when to use IMSI or TMSI is
+entirely on the networks side, without any control by the ME or even the
+subscriber.
+
+This leads to a variety of attacks on subscriber location privacy, including
+the use of passive air-interface sniffing as well as false base station
+attacks, where an attacker impersonates a base station which
+subsequently inquires every ME about its IMSI.
+
+Some related devices have been termed _IMSI catchers_ or _Stingray_ in
+both scientific literature as well as mainstream media. IMSI catchers have
+become small and affordable during the last decade; criminals actors
+and in some cases even tabloid journalists without much budget have
+reportedly used them to track anybody with a mobile phone.
 
 5G addresses this problem with the Subscriber Concealed Identifier (SUCI),
 which uses public-key cryptography to ensure that the permanent subscriber
-identity can only be read by the home network (3GPP TS 33.501, Section 6.12.2).
-A comparable, but different approach to conceal the IMSI for 2G, 3G and 4G is
-provided in this specification.
+identity (IMSI) is not transmitted over the air interface anymore.
+Rather, a concealed version of it is transmitted (3GPP TS 33.501,
+Section 6.12.2).  The 5G SUCI mechanism can not be used 1:1 for previous
+generations of cellular networks as it relies on extending the
+subscriber identity from the small, 15-decimal-digit IMSI to a much
+larger SUPI (Subscriber Permanent Identifier) only available in 5G.
+
+No mechanism for increasing subscriber identity and location privacy on
+the radio interface has been specified for the previous cellular
+technologies 2G (GSM), 3G (UMTS) and 4G (LTE).  Meanwhile, pure 5G
+networks are and will remain rare for many years to come, as operators
+have to support billions of deployed legacy pre-5G ME.  Operating
+combined 5G + previous technology networks enables the so-called
+"downgrade attacks" where the attacker blocks access to 5G e.g. by means
+of jamming/interference, and hence triggers the ME to use a previous
+generation which is still susceptible to the attacks.
+
+This specification proposes a different approach to conceal the
+IMSI for legacy 2G, 3G and 4G networks.
 
 === Summary of Proposed Solution
 
 The solution presented in this document is to periodically change the IMSI of
 the ME to a new pseudonymous IMSI allocated by the Home Location Register (HLR)
-or Home Subscriber Service (HSS). The next pseudonymous IMSI is sent to the SIM
+or Home Subscriber Service (HSS). The next pseudonymous IMSI is sent to the SIM/USIM
 via Short Message Service (SMS), then a SIM applet overwrites the IMSI of the
-SIM with the new value. The only component that needs to be changed in the
-network besides the SIM/USIM is the HLR/HSS, therefore it should be possible
-even for a Mobile Virtual Network Operator (MVNO) to deploy this privacy
-enhancement.
+SIM/USIM with the new value. The only components in the network that need to be
+changed in order to support this mechanism are the SIM/USIM and the
+HLR/HSS.  All other elements (like BTS, NodeB, eNodeB, BSC, RNC, MME,
+MSC/VLR, SGSN, GGSN, S-GW, P-GW, ...) remain as-is, without any changes
+to their specification or implementation.
+
+Constraining the required changes to only two elements in the network
+enables quick adoption potential for the proposed mechanism.
+
+Furthermore, as SIM/USIM and HLR/HSS are the only two elements under control
+of a Mobile Virtual Network Operator (MVNO), this mechanism can be
+deployed by a MVNO without any changes to the operators of the physical
+infrastructure (MNO).
 
 === Summary of Existing Location Updating Procedures in RAN and CN
 
-The subscriber's SIM is provisioned with the IMSI and cryptographic keys of a
-subscriber, after the subscriber was added with the same data to the HLR/HSS.
-In the Remote Access Network (RAN), the IMSI is sent over the air interface and
-then transmitted to the Core Network (CN), where it is validated by the
-HLR/HSS. The involved components vary by the generation of the network and
-whether the SIM is attempting a Circuit Switched (CS) or Packet Switched (PS)
-connection, but the principle is the same. This document uses 2G CS Location
-Updating for reference, as in <<figure-imsi-regular>>.
+Every subscriber's SIM/USIM is provisioned with the IMSI and secret
+cryptographic keys (Ki or K+OP[c]).  The same IMSI and key data is also provisioned
+into the HLR/HSS, the central subscriber database of a cellular network.
+
+In a number of different situations, the IMSI is sent over the air
+interface and back-haul towards the Core Network (CN), where it is
+validated by the HLR/HSS. The involved components vary by the generation
+of the network and whether the SIM/USIM is attempting a Circuit Switched (CS)
+or Packet Switched (PS) connection, but the principle is the same. This
+document uses 2G CS Location Updating for reference, as in
+<<figure-imsi-regular>>.
 
 The IMSI is transmitted in the Location Updating Request from ME. The VLR
-needs an authentication challenge specific to the secret keys on the SIM to
-authenticate the SIM, and looks the authentication challenges up by the IMSI.
+needs an authentication challenge specific to the secret keys on the SIM/USIM to
+authenticate the SIM/USIM, and looks the authentication challenges up by the IMSI.
 If the VLR does not have any more authentication challenges for the IMSI (as it
 happens when the VLR sees the IMSI for the first time), the VLR requests new
-authentication challenges from the HLR. Then the HLR verifies that the IMSI is
+authentication challenges from the HLR/HSS. Then the HLR/HSS verifies that the IMSI is
 known and, if it is unknown, sends back an error that will terminate the
 Location Updating procedure.
 
-After the VLR found the authentication challenge, it authenticates the SIM, and
+After the VLR found the authentication challenge, it authenticates the SIM/USIM, and
 performs a Classmark Enquiry and Physical Channel Reconfiguration. Then the VLR
 has the required information to finish the Location Updating, and continues
 with Process Update_Location_HLR (3GPP TS 29.002). Afterwards, the VLR assigns
@@ -63,6 +101,16 @@
 Reallocation Complete. In following Location Updates with the same MSC, the ME
 sends the TMSI instead of the IMSI in the Location Updating Request.
 
+However, the allocation of the TMSI is optional (the network may choose
+to not perform it), and particularly at mobility changes across the
+MSC/VLR boundary, or even across the PLMN boundary, the TMSI allocated
+by the previouis network element may not be known, and an IMSI based
+Location Updating procedure used.
+
+Furthermore, at any given point in time, a legitimate network or a rogue
+base station can inquire the IMSI from the ME using the "MM IDENTITY
+REQUEST (IMSI)" command.
+
 [[figure-imsi-regular]]
 .Location Updating in 2G CS with IMSI
 ["mscgen"]
@@ -123,16 +171,22 @@
 <<<
 == Required Changes
 
-[[hlr-imsi-pseudo-storage]]
-=== Pseudonymous IMSI Storage in the HLR
+This section covers the changes / enhancements required
+compared to the existing 3GPP specifications.
 
-The HLR must store up to two pseudonymous IMSIs (imsi_pseudo) and their related
-counters (imsi_pseudo_i) per subscriber. Each subscriber initially has one
-pseudonymous IMSI allocated. A subscriber has two valid pseudonymous IMSIs
-only during the transition phase from the old pseudonymous IMSI to the new one.
-The amount of available IMSIs must be higher than the amount of subscribers
-registered with the HLR. If the amount of available IMSIs is too short, the HLR
-can delay assigning new pseudonymous IMSIs until new IMSIs are available again.
+[[hlr-imsi-pseudo-storage]]
+=== Pseudonymous IMSI Storage in the HLR/HSS
+
+The HLR/HSS must store up to two pseudonymous IMSIs (`imsi_pseudo`) and
+their related counters (`imsi_pseudo_i`) per subscriber. Each subscriber
+initially has one pseudonymous IMSI allocated. A subscriber has two
+valid pseudonymous IMSIs only during the transition phase from the old
+pseudonymous IMSI to the new one.
+
+Subsequently, the amount of available IMSIs must be higher than the
+amount of subscribers registered with the HLR/HSS. If the amount of
+available IMSIs is too small, the HLR/HSS could delay assigning new
+pseudonymous IMSIs until new IMSIs are available again.
 
 .Examples for additional subscriber data in HLR
 [options="header"]
@@ -154,32 +208,46 @@
 
 ==== imsi_pseudo
 
-The value for imsi_pseudo is a random choice from the pool of available IMSIs
-that the HLR controls. The pseudonymous IMSI must not be used by any subscriber
-as pseudonymous IMSI yet, but may be the real IMSI of a subscriber.
+The value for `imsi_pseudo` is a random choice from the pool of available
+IMSIs that the HLR/HSS controls. The pseudonymous IMSI must not be used
+by any subscriber as pseudonymous IMSI yet, but may be the real IMSI of
+a subscriber.
 
 [[hlr-imsi-pseudo-i]]
 ==== imsi_pseudo_i
 
-The counter imsi_pseudo_i indicates how often a subscribers pseudonymous IMSI
+The counter `imsi_pseudo_i` indicates how often a subscribers pseudonymous IMSI
 was changed. The value is 1 for the first allocated pseudonymous IMSI of a
 subscriber. When allocating a new pseudonymous IMSI for the same subscriber,
-the new imsi_pseudo_i value is increased by 1. The counter is used by the SIM
+the new `imsi_pseudo_i` value is increased by 1. The counter is used by the SIM/USIM
 applet to detect and ignore outdated requests related to changing the
 pseudonymous IMSI.
 
-=== SIM Provisioning
+=== SIM/USIM Provisioning
 
-IMSI pseudonymization as specified by this document works with SIM and USIM.
-The HLR is allocating a pseudonymous IMSI for the subscriber. This pseudonymous
-IMSI is stored as IMSI on the subscriber's SIM instead of the real IMSI.
+IMSI pseudonymization as specified by this document works with
+traditional SIM (used i 2G), as well as with USIM (used from 3G
+onwards).
+
+The initial IMSI provisioned in the SIM/USIM is provisioned as the initial
+pseudonymous IMSI in the HLR/HSS.
 
 [[sim-app]]
 ==== SIM applet
 
-The SIM is provisioned with a SIM applet, which is able to change the IMSI once
-the next pseudonymous IMSI arrives from the HLR. A reference implementation is
-provided in <<reference-src>>.
+SIM/USIM have long supported the installation and operation of
+additional applets on the card itself.  The programming language and
+runtime environment for such applets is an implementation detail.
+However, the industry has converged around JavaCards with related
+additional APIs specific to SIM, UICC and USIM.  Depending on the card
+profile / provisioning, it is possible for such applets to access the
+card file system and modify files on the card, such as the file storing
+the IMSI.
+
+A SIM/USIM compatible with this specification is provisioned with a SIM
+applet, which is able to change the IMSI once the next pseudonymous IMSI
+arrives from the HLR/HSS. A reference implementation is provided in
+<<reference-src>>.
 
 ===== Counter Storage
 
@@ -206,18 +274,18 @@
 ===== Switch to Next Pseudonymous IMSI
 
 The SIM applet registers to a suitable SMS trigger (3GPP TS 43.019, Section
-6.2). When an SMS from the HLR in the structure of <<sms-structure>> arrives,
-the applet must verify that the SMS is not outdated by comparing imsi_pseudo_i
-from the SMS with the last imsi_pseudo_i that was used when changing the IMSI
+6.2). When an SMS from the HLR/HSS in the structure of <<sms-structure>> arrives,
+the applet must verify that the SMS is not outdated by comparing `imsi_pseudo_i`
+from the SMS with the last `imsi_pseudo_i` that was used when changing the IMSI
 (initially 1 as in <<hlr-imsi-pseudo-i>>). The new value must be higher,
 otherwise the SMS should not be processed further.
 
 The SIM applet registers a timer with min_sleep_time from the SMS. When the
-timer triggers, EF~IMSI~ of the SIM is overwritten with the new pseudonymous
+timer triggers, EF~IMSI~ of the SIM/USIM is overwritten with the new pseudonymous
 IMSI. The TMSI and related data (EF~LOCI~, EF~PSLOCI~) and ciphering keys
 (EF~Kc~, EF~KcGPRS~, EF~Keys~, EF~KeysPS~) are invalidated (see 3GPP TS
-31.102). The current imsi_pseudo_i from the SMS is stored in the SIM applet
-to compare it with the next SMS. imsi_pseudo_lu is reset to 0. Afterwards,
+31.102). The current `imsi_pseudo_i` from the SMS is stored in the
+SIM applet to compare it with the next SMS. `imsi_pseudo_lu` is reset to 0. Afterwards,
 the EF~IMSI~ changing procedure in 3GPP TS 11.14, Section 6.4.7.1 is executed
 to apply the new IMSI.
 
@@ -233,8 +301,8 @@
 SIM applet should warn the subscriber if the pseudonymous IMSI does not change.
 
 The SIM applet registers to EVENT_EVENT_DOWNLOAD_LOCATION_STATUS (3GPP TS
-03.19, Section 6.2) and increases imsi_pseudo_lu by 1 when the event is
-triggered. If imsi_pseudo_lu reaches imsi_pseudo_lu_max, the SIM applet
+03.19, Section 6.2) and increases `imsi_pseudo_lu` by 1 when the event is
+triggered. If `imsi_pseudo_lu` reaches `imsi_pseudo_lu_max`, the SIM applet
 displays a warning to the subscriber.
 
 [[process-update-location-hlr]]
@@ -281,7 +349,7 @@
 
 ==== Update Location Request
 
-When Update Location Request arrives, the HLR does not look up the subscriber
+When Update Location Request arrives, the HLR/HSS does not look up the subscriber
 by the IMSI, but by the pseudonymous IMSI instead. Unless the subscriber has
 two pseudonymous IMSI allocated and used the new pseudonymous IMSI in the
 Update Location Request, this is followed by the existing logic to continue
@@ -290,8 +358,8 @@
 ===== Update Location Request With New Pseudonymous IMSI
 
 If the subscriber has two pseudonymous IMSIs allocated, and the newer entry was
-used (higher imsi_pseudo_i, see <<hlr-imsi-pseudo-i>>), this section applies.
-The older pseudonymous IMSI is deallocated in the HLR. This is done as early
+used (higher `imsi_pseudo_i`, see <<hlr-imsi-pseudo-i>>), this section applies.
+The older pseudonymous IMSI is deallocated in the HLR/HSS. This is done as early
 as possible, so the timeframe where two pseudonymous IMSI are allocated for one
 subscriber is short.
 
@@ -303,7 +371,7 @@
 ===== Update Location Request With Old Pseudonymous IMSI
 
 If the subscriber has two pseudonymous IMSIs allocated, and the older entry was
-used (lower imsi_pseudo_i, see <<hlr-imsi-pseudo-i>>), the newer entry is _not_
+used (lower `imsi_pseudo_i`, see <<hlr-imsi-pseudo-i>>), the newer entry is _not_
 deallocated. This could lock out the subscriber from the network if the SMS
 with the new pseudonymous IMSI arrives with a delay.
 
@@ -315,19 +383,19 @@
 ==== Next_Pseudo_IMSI_Timer Expires
 
 If the subscriber has only one pseudonymous IMSI allocated, and the amount of
-available IMSIs in the HLR is high enough, a second pseudonymous IMSI and
-related imsi_pseudo_i gets allocated for the subscriber (as described in
+available IMSIs in the HLR/HSS is high enough, a second pseudonymous IMSI and
+related `imsi_pseudo_i` gets allocated for the subscriber (as described in
 <<hlr-imsi-pseudo-storage>>).
 
 If the subscriber still has only one pseudonymous IMSI, because not enough
-IMSIs were available in the HLR, the process is aborted here and no SMS with
+IMSIs were available in the HLR/HSS, the process is aborted here and no SMS with
 a next pseudonymous IMSI is sent to the subscriber. The subscriber will get a
-new pseudonymous IMSI during the next Location Updating Procedure, if the HLR
-has enough IMSIs available at that point.
+new pseudonymous IMSI during the next Location Updating Procedure, if
+the HLR/HSS has enough IMSIs available at that point.
 
 An SMS is sent to the SMS - Service Centre (SMS-SC) with the newer pseudonymous
-IMSI (higher imsi_pseudo_i, see <<hlr-imsi-pseudo-i>>) and related
-imsi_pseudo_i value.
+IMSI (higher `imsi_pseudo_i`, see <<hlr-imsi-pseudo-i>>) and related
+`imsi_pseudo_i` value.
 
 [[sms-structure]]
 ==== Next Pseudonymous IMSI SMS Structure
@@ -368,9 +436,9 @@
 
 === Next Pseudonymous IMSI SMS is Lost
 
-If the SMS with the next pseudonymous IMSI does not arrive, the SIM will start
+If the SMS with the next pseudonymous IMSI does not arrive, the SIM/USIM will start
 the next Location Updating Procedure with the old pseudonymous IMSI. Because
-the HLR has both the old and the new pseudonymous IMSI allocated at this point,
+the HLR/HSS has both the old and the new pseudonymous IMSI allocated at this point,
 the subscriber is not locked out of the network.
 
 === Next Pseudonymous IMSI SMS Arrives Out of Order
@@ -379,7 +447,7 @@
 network is not able to deliver them in order, or even because an attacker would
 perform a replay attack.
 
-If the SMS arrives out of order, the imsi_pseudo_i counter will not be higher
+If the SMS arrives out of order, the `imsi_pseudo_i` counter will not be higher
 than the value the SIM applet (<<sim-app>>) has stored. Therefore, the applet
 will discard the message and the subscriber is not locked out of the network.
 
@@ -406,11 +474,11 @@
 When deploying the IMSI pseudonymization, the operator should make sure that
 the next pseudonymous IMSI SMS (<<sms-structure>>) cannot be read or modified
 by third parties. Otherwise, the next pseudonymous IMSI is leaked, and if the
-pseudonymous IMSI in the SMS was changed, the SIM would be locked out of the
+pseudonymous IMSI in the SMS was changed, the SIM/USIM would be locked out of the
 network.
 
 The safest way to protect the next pseudonymous IMSI SMS is a layer of end to
-end encryption from the HLR to the SIM.  The existing means for OTA SMS
+end encryption from the HLR/HSS to the SIM/USIM.  The existing means for OTA SMS
 security (3GPP TS 23.048) provide mechanisms for integrity protection,
 confidentiality as well as replay protection and must be implemented when using
 IMSI pseudonymization.
@@ -441,7 +509,7 @@
 
 https://osmocom.org/projects/imsi-pseudo
 
-The HLR modifications described in <<hlr-imsi-pseudo-storage>> and
+The HLR/HSS modifications described in <<hlr-imsi-pseudo-storage>> and
 <<process-update-location-hlr>> were implemented for reference in OsmoHLR from
 the Osmocom project, licensed under AGPL-3.0. Information about the source code
 and related branches for IMSI pseudonymization can be found at the above URL as