Legality

Fri Apr 25, 2025

Amateur LTE has to comply with the regulations. Here I discuss the way a USA ham can get on the air.

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.

We need a separate PLMN to avoid getting non-hams on ham networks. Hams on non-ham experimental networks is not so big a deal.

(Non-hams could just use 00101 or similar, but that’s not intended for our use cases. We want to go to a friends house and use their cell tower, or benefit from a global cabal community of CBRS nodes run by experimenters.)

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.

Derivation from callsigns, when it doesn’t need to be super secret, is not difficult.

One possible method is below.

import hashlib

def hashtrunc(callsign, n):
    call_bytes = callsign.upper().encode()
    h = hashlib.sha256(call_bytes).digest()
    return h[:n]

ki = hashtrunc("W2FBI", 16)
op = hashtrunc("XCL.IS", 16) #or whatever your network OP will be
#opc calculated from ki,op per the spec

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 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.

  • IMSI is big enough for a six character callsign encoded in base40.
  • EEA0 (null encryption) might be necessary, since so much of LTE is ciphered.
  • Except TMSI gives us 32 bits, about the same size, and is sent much more often and in the clear. It’s meant to be random, but MME controls this, and can be patched to use an encoded callsign.

APN might also be useful here, but I haven’t thought of a way I liked.

This needs more attention for long term plans, as IMSI doesn’t have enough space for multiple UE on a single callsign. This could feasibly be adjusted by using 973 as the MCC, and the MNC would be an encoded callsign. IMSI prefix and MCC/MNC don’t necessarily have to match, either.

Either will add more problems, so experimentation is in order to see what we like.

I’ve also toyed around with incrementing the IMSI from an encoded callsign, as the space of encoded callsigns is not the same as the space of all valid characters, and this gives us some ability to figure out which callsign it is.

I worry this would make it difficult to figure out a callsign reliably, so I’ve tabled that idea.

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 not authorized for identifying transmissions, 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 like DMR, D-STAR, YSF, and more.

On that note - when is a digital mode a voice mode, if ever? Does that answer change if it’s 100% packet based with an IP protocol?

It may be time to revisit large chunks of the restrictions and streamline them. Does it really matter to the FCC in current_year whether something is baudot, ASCII, UTF-8 or some other funky encoding? What about the difference between data and voice modes, or between data and non-RTTY RTTY when computers are involved in every data transmission?

Ham radio is largely self-enforcing, and certainly the FCC is not involved in the day-to-day of ham radio. In practice, it’s hams you must convince you are aboveboard, not the FCC.

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.

Final thoughts

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 reason to exist, and in a world of not just stagnation, but actual regression (when’s the last time you saw a 9600 baud radio new? How expensive was it?) new technology like LTE is late to the party.

I hope you’ll join me and the friendly group of hams that are all about experimenting with LTE, and take a look at the main force for modern Amateur research and development.

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