Ham LTE standard, v1 NEARfest

Fri Apr 25, 2025

This is the set of details for my LTE operations at NEARfest May 2nd and 3rd, 2025.

PLMN

  • 999-73

Frequency

For NEARfest, I will be using a 10MHz cell at 2390-2400, and possibly a 5MHz cell at 2305-2310 if possible. This is on LTE Band 40, which is 2300-2400 MHz.

Regulatory Compliance

In the USA, hams are regulated by 47 CFR Part 97.

I’ve identified two major issues with ham LTE: identification, and encryption.

There’s another thing to address, which is the authority by which we can experiment with this new digital mode, but that’s best discussed in legality

What you see here is what I’m going to do for public demos in early May 2025, and the discussion of why it must be done separately because it is complicated.

Encryption

Data Encryption Is Legal

But for now, I will be using EEA0 for the cipher and this means we still have identity and integrity protection.

In the future this could change. Expect a version bump if that happens.

Identification

As Amateurs, we must identify our transmissions.

LTE is mostly structured for a different use case and does not support our kind of identification easily. We need to shoehorn something in to meet our needs.

We also have several different concepts of identity.

  • Legal identity (callsign, like W2FBI)
  • UE identity (perhaps with SSID, like W2FBI-1)
  • Purpose

And these are used for different things. The most obvious thing is MSISDN, or the phone number.

We don’t strictly need a phone number, but I like the idea because then we can have an Asterisk server handling cross-mode bridges, conference calls, etc, plus built-in text messaging and voice calls.

UE Identity and phone number

Phone numbers will be generated from the full callsign, encoded with an M17-compatible base40 encoding (but without the 48bit restriction).

I already made a proof-of-concept dialer that will work one your phone in the browser.

This will also make conference calls and other such things easy to remember - not a phone number, but a string like “LOCAL” or “SITE”.

  • IMSI is big enough for a six character callsign. I’m not happy with this long-term due to the inability to separate out different UE, but we’ll roll with it for the demo at NEARfest. This may not be sent often enough.

  • TMSI is sent by the UE as needed, and is assigned by the MME. I am going to patch Open5GS to make it the salient part of the IMSI, to preserve UE identification. I will also patch Open5GS to roll TMSI on an appropriate timeline per our legal requirements, as this requires it be sent over again. The TMSI will not actually change, though I may reserve a high-order bit to toggle on and off if needed.

  • APN could plausibly be used to send a callsign. I’m not going to bother with that.

In the meantime, here’s code for the callsign IMSI and MSISDN encoding.


base40 = " " + string.ascii_uppercase + string.digits + "-/."
callsign_alphabet = base40

def alphaencode(s,alphabet=None):
    if alphabet is None:
        alphabet = callsign_alphabet
    n = 0
    for c in s.upper()[::-1]:
        ci = alphabet.index(c)
        n *= len(alphabet)
        n += ci
    return n

def alphadecode(n,alphabet=None):
    if alphabet is None:
        alphabet = callsign_alphabet
    cs = ""
    while n > 0:
        i =int(n%len(alphabet))
        cs += alphabet[i]
        n //= len(alphabet)
    return cs


each = "W2FBI"
n = alphaencode(each)
ns = str(n)[::-1]
print(ns, len(ns))
> 38787132 8

each = "38787132"
n = int(each[::-1])
call = alphadecode(n)
print(call)
> "W2FBI"

#Why those reversals?
#Because a short callsign is a small number, 
#but phone numbers are short from the left, not the right.

Future work might test to see if we can use the 5 decimal digits making up the PLMN in the IMSI for more encoding space.

For now, only the right-most 10 digits of IMSI/TMSI will be the callsign.