Ham LTE standard, v1 rfc

Sun Apr 20, 2025

We need a specification for ham radio use of LTE.

Here’s a first-draft, I’m versioning it as v1 rc.

Updates

What you see below is as I published it, with some minor additions. Thanks to Michelle W5NYV and Paul KB5MU as well as the members of the ORI mailing list and Slack for discussing these concerns.

Second draft with current understanding is here.

Below is kept for posterity, but no longer accurate to my understanding or plans.

I’ve also brought out the legality portion into a separate article.

PLMN

Every network requires a MCC/MNC (PLMN). This is deeply tied to UE configurations in most cases, as the sim card or esim does not contain APNs and therefore the UE has to offer manual configuration or package known profiles in the OS. It does this by using the PLMN to look up configuration.

This auto configuration is less important for us, as we can standardize on something and our users are massively more technical than the average cell phone user.

So we need our own PLMN.

  • I propose 999-73 for global use of Amateur radio.
  • I propose 999-72 for global use of amateur radio, such as on unlicensed or lightly licensed spectrum - ISM, CBRS, that sort of thing.

Related: Amateur vs amateur

Pros:

  • MCC with a first digit of 9 indicates a worldwide assignment.
  • 73 represents the most common way of saying best regards and is nearly universally understood among hams due to a shared history and usage of CW prosigns. 72 is aaaalmost 73 but not quite.
  • Most importantly, neither are currently assigned, and not likely to be assigned soon.
  • 999 is special, and cut-out for private LTE networks.

This still has a problem. On paper, we oughtn’t just pick one and use it - 3GPP has a whole procedure around this.

But first:

Why not 973-73? Or 973-xx? Because I suspect someone at 3GPP would have a stroke over their beautiful numbering system being used like that (they only have so many numbers, after all), I don’t think we need more than one PLMN, and 999-73 won’t require a central authority issuing numbers the way 973-xx would.

I think having more than one PLMN for ham usage would complicate the system greatly.

Unfortunately, 3GPP are entirely unapproachable. As amateurs, we do not have billions of capital expenditure and don’t have top-down authority. This makes it rather hard for them to recognize us as serious, and for us to accurately represent ourselves as representing all hams.

And I don’t have enough money or standing to try to get it done on my own.

So, I’m going to do as hackers always have, and go ahead and use it anyway. It’s not illegal, and since it’s not in use, shouldn’t cause any real-world problems. Often the fastest and best way forward is to prove the concept, because then it is clear you are serious.

After there’s some use, maybe we can get a group like ORI, ARDC, ARRL, DARC and others together to ask for it - or some other PLMN - to be assigned to global ham radio usage.

This would also let us get a common configuration into the typical carrier config, such as on Android.

Okay, so we picked a PLMN. Now we need spectrum.

Spectrum

Unlicensed (or nearly so)

Said another way, these are the lowercase-a amateur experimenters. We basically have two options for spectrum here in the US, and I apologize for being US-centric, but you can see the full knowledge we have for other countries in the repo, as well as contribute to it for your own regulatory environment.

  • US hams have CBRS available. This has costs associated with it, such as the SAS. You may also need a certification to install your eNBs. Most modern UEs support CBRS

  • LTE-U (like in the same spectrum as WiFi) is totally unlicensed, but has almost no UE support.

Amateur

  • Band 40, TDD 2300-2400MHz, has overlap with US ham privileges 2300-2310 and 2390-2400 MHz, and widespread UE support.
  • Band 42 has overlap with 3400-3450 privileges, which US hams still have (for now) because of footnote 103. This is relatively hard to find equipment for, both UE and eNB.
  • Band 8 with CA, or if they add a TDD version of Band 8. Band 8 has widespread support, but US hams only have privileges on 902-928 MHz. Band 8 is 880 – 915 for the uplink (UE transmit) and 925 – 960 for the downlink (eNB transmit). It has a 45MHz standardized duplex offset, so there is no way to use this band standard with ham radio privileges.

Special note: Band 30 FDD, not useful in my region but maybe useful in yours. Very common UE support.

Now we have to comply with ham radio regulations if we want to operate under Amateur rules.

Lowercase-a amateurs don’t have these needs, of course.

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 you’re reading the solution to that right now so I hesitate to call it a major issue.

Encryption

I’ll address encryption first.

In short, we can encrypt. But we won’t, but not because it’s illegal. Because it’s not illegal.

What we can’t do is encrypt for the purpose of obscuring the meaning of the message, which is indeed what most encryption does. Does the effect control the intent?

There are good arguments to be made about intent. Read the following from N2IRZ:

Data Encryption Is Legal

It’s clear to me that encryption in LTE and similar tools are intended for network security, access control, and more, and therefore permissible.

Aside: Intent gets harder when you talk about more than one person, too. I didn’t make LTE - whose intent matters?

Anyway, I’m convinced N2IRZ has a strong enough argument!

That doesn’t mean there aren’t other factors in play.

Cultural concerns

Amateur radio has a long tradition of open access and open inspection of signals. This is important for a number of reasons, but the most persuasive to me is that if the signal is open, documented, it can be experimented with and understood that much more easily.

And that’s what we’re here to do.

Hams did not really flock to DMR until two things happened nearly simultaneously:

  • Increased availability of affordable DMR handhelds (Tytera MD-380, $99)
  • Travis Goodspeed published a hacked firmware for that same platform that enabled monitoring of all received DMR talkgroups on a timeslot, which was not possible in a cheap handheld prior.

Hams are snoops and want to know what’s going on. I say this with all love and full awareness of the sheer number of scanners in my house.

LTE is going to be spectacularly opaque compared to the average ham mode.

LTE supports a null cipher, EEA0. All eNB and UE must support it, per the spec. I’ll be configuring it on purpose.

The EEA0 algorithm shall be implemented such that it has the same effect as if it generates a KEYSTREAM of all zeroes

NOTE 3: EEA0 and EIA0 provide no security.

https://www.etsi.org/deliver/etsi_ts/133400_133499/133401/12.12.00_60/ts_133401v121200p.pdf

EEA0 : no encryption

https://gdelugre.github.io/2018/05/10/3gpp-ota-security-evolution/

Otherwise, we can publish keys, or make them predictable in some way, as long as identification requirements are met.

If we can derive the Ki and OPc from the callsign, we’ve effectively published keys and enrollment into a ham EPC can be made that much easier.

More on this kind of thing in identification.

Identification

As Amateurs, we must identify our transmissions.

This brings up the mode issue. We’ll get into that more later. We need to use an authorized emission type for LTE in general, and for the identification requirements as well because 97.119 has a list of authorized ways to identify.

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

Central database

One of the things I’ve learned over the years is that centralization is bad. Any reliance on a database of users is going to be a nightmare. That was a factor with DMR-MARC, with Brandmeister, with TGIF. It’s causing some consternation with dvref now.

It’s fragile.

Overall, I’d prefer a system that can encode or derive what is needed rather than look it up, or if it needs to be looked up it at least needs to be federated without one central authority.

M17 and D-STAR both encode callsigns directly. This is believed to be sufficient for identification requirements.

DMR has a “dmr id” which doesn’t identify the operator and relies on a database. This is not sufficient.

Maybe none of this seems to matter to you, since we all say our callsigns anyway, but it absolutely does matter for non-voice communications such as data. Arguably, DMR data is not in compliance without the callsign being somewhere else explicitly, such as Talker-Alias.

But this is concerning. The site radioid.net is a centralized place, run by people, who thankfully have been good stewards of their role. They are now depended on by nearly everyone, leaned on to add friction even for things like Droidstar in M17 mode as a way of preventing unrelated issues like non-hams using the service.

They’re fine right now, but that never lasts. There will, eventually, be drama and discontent, if I haven’t missed some already.

So we need a way to do this without making too many opportunities to shoot ourselves in the foot.

Direct encoding

I can think of a few ways, and we should probably do all of them.

  • Phone number (MSISDN) transform to/from callsign, using something like M17’s base40 callsign encoding but without the 48bit restriction.
  • IMSI is big enough for a six character callsign, but this has problems. Some of those problems might be able to be addressed, because MME is responsible for assigning M_TMSI which is used for S_TMSI.
  • EEA0 (null encryption) might be necessary, because most things are only sent plaintext on first attach. I’m not sure what the implications of that are in terms of UE support.
  • APN might be used to send a callsign?

I don’t get the impression we have control of a lot of the common fields, and we don’t have control of most of the modems in use so deep intervention is not practical.

I need to keep reading, and learning. If you have ideas, I’m all ears.

In the meantime, expect my networks to use EEA0, and will encode both the phone number and IMSI with:


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.

IMSI may either be entirely encoded callsign, or only the right-most 10 digits, depending on the outcome of experiments with the fully-encoded IMSI.

I’m confident this can be improved, and welcome your comments!

Before then I will also be investigating to see what can be shoved into various fields, since I understand some are sent more often, and in the clear.

I suspect the MSISDN encoding will stick around, to allow for direct dialing by callsign.

I am not yet sure what the long term identification compliance measures will look like.

Authorized emissions

This is a can of worms, because it’s not clear how to read the regulation when the text is overly specific.

First, what is RTTY?

97.3(c)(7) RTTY. Narrow-band direct-printing telegraphy emissions having designators with A, C, D, F, G, H, J or R as the first symbol; 1 as the second symbol; B as the third symbol; and emission J2B. Only a digital code of a type specifically authorized in this part may be transmitted.

Honestly, not clear on what that means in 2025.

and what is data?

97.3(c)(2) Data. Telemetry, telecommand and computer communications emissions having (i) designators with A, C, D, F, G, H, J or R as the first symbol, 1 as the second symbol, and D as the third symbol; (ii) emission J2D; and (iii) emissions A1C, F1C, F2C, J2C, and J3C having an occupied bandwidth of 500 Hz or less when transmitted on an amateur service frequency below 30 MHz. Only a digital code of a type specifically authorized in this part may be transmitted.

That looks an awful lot like RTTY to my eyes. Note that Data clearly includes computer communications, whereas RTTY says “direct-printing”.

And if you use fldigi as a software modem, …?

And, what’s a computer? A laptop? A separate microcontroller? The main CPU of the radio? (Actually, what radios don’t have a computer in them?)

These are the only two emission types that might apply to LTE. Neither are obviously a match, to my eye.

It gets worse:

97.309 RTTY and data emission codes.

  • (a) Where authorized by §§ 97.305(c) and 97.307(f) of the part, an amateur station may transmit a RTTY or data emission using the following specified digital codes:
    • (1) The 5-unit, start-stop, International Telegraph Alphabet No. 2, code defined in ITU-T Recommendation F.1, Division C (commonly known as “Baudot”).
    • (2) The 7-unit code specified in ITU-R Recommendations M.476-5 and M.625-3 (commonly known as “AMTOR”).
    • (3) The 7-unit, International Alphabet No. 5, code defined in IT–T Recommendation T.50 (commonly known as “ASCII”).
    • (4) An amateur station transmitting a RTTY or data emission using a digital code specified in this paragraph may use any technique whose technical characteristics have been documented publicly, such as CLOVER, G-TOR, or PacTOR, for the purpose of facilitating communications.
  • (b) Where authorized by §§ 97.305(c) and 97.307(f), a station may transmit a RTTY or data emission using an unspecified digital code, except to a station in a country with which the United States does not have an agreement permitting the code to be used. RTTY and data emissions using unspecified digital codes must not be transmitted for the purpose of obscuring the meaning of any communication. […]

Maybe you can already see the problem. It gets still worse, these are the identification requirements we hinted at earlier:

97.119(b)

The call sign must be transmitted with an emission authorized for the transmitting channel in one of the following ways:

  • (1) By a CW emission. When keyed by an automatic device used only for identification, the speed must not exceed 20 words per minute;
  • (2) By a phone emission in the English language. Use of a phonetic alphabet as an aid for correct station identification is encouraged;
  • (3) By a RTTY emission using a specified digital code when all or part of the communications are transmitted by a RTTY or data emission;
  • (4) By an image emission conforming to the applicable transmission standards, either color or monochrome, of § 73.682(a) of the FCC Rules when all or part of the communications are transmitted in the same image emission

So the question is, if we write our specification and refer to 3GPP specifications, how are the LTE protocols, with our additional specifications in this document published publically, going to be treated?

And what, then, does this mean?

Only a digital code of a type specifically authorized in this part may be transmitted.

  • What’s the difference between a “code” and a “technique”? Neither are defined explicitly. The first three codes seem to have a peculiar definition of code, much like morse code, i.e. a mapping of one symbol to another.
  • What’s the difference between “RTTY” and “data” in the identification requirements? They are often used together, and sometimes appear to be used interchangeably, but other times there are clear distinctions in usage.
  • What is the type of a digital code? It says “digital code of a type” but then names specific codes. The difference between “Only a digital code of a type specifically authorized … " and “Only a digital code that is specifically authorized … " is nontrivial. I think the only way to interpret this in this context is that those two sentences must be equivalent, but to a native english speaker, especially a technical one, they are clearly not the same and so this is an extra bit of confusion that must be overcome.
  • 97.309(a) says “using the following specified digital codes:” and then item four of those “specified digital codes” refers to “using a digital code specified in this paragraph”. Is (4) a specified digital code? Does it authorize the use of any digital code that is specified, or any technique that is specified? The difference matters.

If code == technique, then any documented protocol can be used for identification.

If code != technique and (4) is a code, then any documented protocol becomes a specified digital code and can be used for identification.

If code != technique and (4) is not a code, then the phrasing clearly says the technique is what has to be documented publically, and more importantly we cannot identify with that technique despite 97.309(b) authorizing the unspecified code for usage.

And, if RTTY != Data, then none of the above matters and you cannot identify with any data protocol that is not RTTY.

The phrasing presumes a certain type of usage that no longer matches the reality of Amateur communications, but I think the intent is still clear, and it’s not good for us.

The only way I can read all of the above, is the worst of all those at the same time:

  • code != technique seems clear to me, as they are clear in making the distinction in usage and consistent elsewhere
  • (4) is obviously not intended to be a code itself, but a way of saying anything using those codes above can be used for other digital modulations, not just the ones that originally led their creation.
  • RTTY != data and I think this is clear from the way each is specifically defined.

I suspect the intent was that you wouldn’t need to have a copy of the data modem in use to identify a transmission. That’s why RTTY is direct-printing, why Data includes computer communications. The intent seems to have been that someone with standard equipment could identify your transmissions. Similarly, it seems meant to make sure anyone that had the right modem could read your messages by only trying three possible codes. 97.309(b) was to allow for unspecified codes, but notice the restrictions on it!

This all rather throws a wrench in our plans, doesn’t it? This doesn’t even get into the emission designators, plural, of LTE, which are yet more problems I decline to examine in detail right now. But, on its face, emission designators alone would seem to outlaw a good quantity of ham radio communications already in use that’s multi-carrier, among other possible issues.

Thanks to W5NYV and KB5MU for pointing out 97.307(f)(8), which appears to make the emission designator problem a non-issue above 6m.

ReferenceError

In practice, we know there exist a great many RF protocols, almost none of which are using Baudot, Amtor, or 7-bit ASCII.

No one seems concerned those are illegal to identify with, and the assumption seems to be that if it’s documented it’s good to go, and even if it’s not documented no one seems to mind because of 97.309(b), and we’ll just avoid thinking about all the issues associated with current digital modes this brings up.

Back to the fun parts!

Callsign routing

It’s all well and good to have callsigns, but sometimes you want to reach a specific person. That requires a lot more work.

DMR handles this by having a particular network. But because of the network centralization, we ended up with multiple networks, and that ultimately didn’t work out at all.

D-STAR may or may not handle this. I don’t know. I don’t have a D-STAR radio and the audio quality is too bad for me to justify the $400+ to buy one just to satisfy my curiosity (there are no d-star repeaters around).

There’s no issue for working on a single EPC. I think we can probably figure something out for EPC federation when the time comes, but I’m going to punt on this for now.

What kind of station is a UE?

Good question! Is there another question?

(I don’t think it gets any particular definition)

What kind of station is a eNB?

97.3 covers this

Well, it’s not a repeater:

(40) Repeater. An amateur station that simultaneously retransmits the transmission of another amateur station on a different channel or channels.

It could be in a message forwarding system, except I’m not totally sure that applies:

(32) Message forwarding system. A group of amateur stations participating in a voluntary, cooperative, interactive arrangement where communications are sent from the control operator of an originating station to the control operator of one or more destination stations by one or more forwarding stations.
97.219

I think it’s an Auxiliary station:

(7) Auxiliary station. An amateur station, other than in a message forwarding system, that is transmitting communications point-to-point within a system of cooperating amateur stations.

Except, I wouldn’t really call it point-to-point.

Or is it an automatically controlled digital station? https://www.law.cornell.edu/cfr/text/47/97.221

97.3(a)(6) Automatic control. The use of devices and procedures for control of a station when it is transmitting so that compliance with the FCC Rules is achieved without the control operator being present at a control point.

Ham radio is for experimentation, and maybe FCC is more about the vibes, given their low enforcement capability.

Ham LTE is certainly well within our purpose, and indeed is a long time in coming. I hope you’ll join me and the friendly group of hams that are all about experimenting with LTE.

Give me a call on Band 40 at “W2FBI”!