A bit about PON. Part 3

Both GPON and GEPON have built-in bandwidth allocation features in their traffic delivery mechanisms. This means that if a subscriber is hogging a lot of data, they can get extra bandwidth that isn't being used by others at that moment. This is clearly some pretty complex tech, so I won't pretend to know exactly how it works under the hood. Long story short, with a 1 Gbps downstream channel, a single subscriber could actually get the full speed—assuming the ISP allows it and nobody else is online at the time. The bandwidth is shared among all active users, and individual speeds only start dropping if the total capacity gets completely maxed out. Just to recap, the bandwidth can be capped either on the ISP's configuration side or directly by the PON hardware itself.

This article is a translation of the original Russian-language post.My journey of learning GPON 

A bit about PON. Part 2

Just a quick reminder, folks—I’m not a PON, networking, or fiber optics engineer. Everything I know about this stuff comes straight from my own hands-on experience. I’ll be the first to admit my knowledge is pretty high-level, but hopefully, someone out there finds it useful.
Anyway, let’s pick up where we left off. The main difference between GPON and GEPON is that GPON uses fixed-length frames and synchronized transmission—meaning the OLT sends and receives frames based on its own internal clock. Since these frames have a strictly defined size, any large packet gets chopped up into small pieces and sent in parts. GEPON, on the other hand, is built on top of standard Ethernet, where the timing and size of the transmitted data aren't known in advance. While downstream data from the OLT is filtered by the ONT using an ID, the upstream traffic works a bit differently: the headend terminal periodically sends a data packet to each client device, telling it exactly when and for how long the OLT is ready to receive its data. Since the transmission duration can change dynamically, there’s no need to break packets into fragments. Of course, this doesn't mean you can blast a massive file—like your favorite movie—all in one go :) No, we're talking about standard Ethernet packet sizes here. Though, during its assigned time slot, an ONT might manage to burst through several packets. Either way, each packet is sent in its entirety. From a purely Ethernet traffic standpoint, GEPON looks pretty attractive, especially since data volumes keep skyrocketing with the rise of internet services and ever-growing demands for high-quality content.

This article is a translation of the original Russian-language post.My journey of learning GPON 

A bit about PON. Part 1

Honestly, picking something you don't really know inside out is pretty tough. Especially since I'm more of a hardware guy than a software techie. The spec sheets are packed with fancy buzzwords—IGMP snooping, multicast, VLANs, 64 subscribers per branch, you name it. To brush up on my knowledge, I hit up Google to look into GPON and GEPON. And let me tell you, finding solid, straightforward information on passive networks is a real pain. Most of what you find is just marketing fluff with generic descriptions. It's usually something along the lines of: downstream traffic from the OLT to subscribers runs on a 1490nm wavelength, while upstream runs on 1310nm. There's a shared frame broadcast going out to the subscribers, which includes the ID of the ONU (Optical Network Unit)—the client device. These devices only accept the data that matches their ID and just ignore the rest. This stream also tells the ONUs exactly when they are allowed to send data back to the OLT—meaning, from the subscriber to the network. Getting the timing exactly right for ONU transmissions is pretty much the cornerstone of both GPON and GEPON. Since signals from multiple subscribers feed into a single fiber, the sensitive receiver on the line terminal can only pick up one wavelength at a time. If client devices just started blasting data whenever they felt like it, everything would turn into absolute chaos in the fiber. The signals would step all over each other, and the headend gear wouldn't understand a single thing. Think of it like standing in front of a massive crowd where everyone wants to tell you something, but they all talk at the exact same time. You won't hear anything except a wall of noise and shouting. But if you yell, "One at a time, everyone! Let's start from the far left and go down the line..." then you can actually listen to everyone, even if it takes a bit longer.

This article is a translation of the original Russian-language post.My journey of learning GPON 

The PON Technology Dilemma

The next question was which PON technology to go with. Right now, APON, EPON, GPON, and GEPON are all out there. We ruled out the first two right away since they're outdated and just can't keep up with what users need today. That left us choosing between GPON and GEPON. Both technologies have plenty of manufacturers, but here’s the catch: their gear isn’t compatible with each other, even within the same technology. And it makes sense—who wants to pour money into R&D just for everyone else to ride their coattails and let low-cost copycats win the price war? This way, vendors lock you into their ecosystem. From a tech standpoint, it’s way smarter to stock spares from just one manufacturer rather than managing a whole zoo of different brands just in case something breaks. An N+1 redundancy setup is always going to be cheaper than 1+1 anyway. So, picking a manufacturer pretty much ties your company down to them for the long haul and leaves you dependent on them.
Either way, buying an expensive solution from big-name vendors completely in the dark felt pretty sketchy. We were looking for pretty much the cheapest option available. On top of that, for the pilot launch, we needed an all-in-one box, not a modular system. Some manufacturers don't even make 1U OLTs (Optical Line Terminals), only modular chassis. That immediately knocked them off our list because we have a limited number of fibers running from our central hub to the remote node serving the residential area, and every single fiber counts.
Anyway, we narrowed down the list of available manufacturers, and the price of customer premises equipment (CPE) was roughly the same across the board.
The only question left on the table was: GPON or GEPON?

This article is a translation of the original Russian-language post.My journey of learning GPON

A bit about me

Good day to you, guests of my blog.
I work for a company that provides Internet services to the public – in common parlance, an Internet service provider. In our small town, there are five providers: three of them (including our company) were originally founded in the town itself. Later, the largest one was bought out by MTS, and two others came to the town not so long ago – VimpelCom and the mega-monster Rostelecom, which has existed for a long time but gained the resources of CenterTelecom a couple of years ago. There are also several other organizations that provide Internet to businesses and government agencies. They practically never cross paths with us in our work, so I have little information about them.
We connect subscribers using the classic scheme – fiber to the building. Unfortunately, the fiber does not come from a central hub, but from a district hub – which aggregates a couple of dozen buildings. The network topology is a star.
Over the course of several years, the network was built gradually, district by district. Slowly, without rushing, because the resources for construction are limited, and it is easier to purchase backbone and subscriber equipment in a planned manner.
Be that as it may, over time the network was built in all multi-apartment buildings in the city. We then faced the problem of choosing a connection technology for subscribers in private housing areas, of which there are territorially about three – two areas with roughly 150 households each, and the largest one – about 600 households. For a long time, we weighed various options for connecting subscribers – from placing nodes on power-line poles and connecting houses via twisted pair, to a fully optical network.
We almost immediately came to the conclusion that an optical cable should go to the subscriber – in order to protect the subscriber equipment (and our own nerves) from the consequences of lightning strikes.
It remained to decide on the scheme for delivering traffic – either by setting up micro-nodes for a few houses and aggregating them into a larger backbone node, or by using passive optical network equipment. The first option, when abandoning intermediate nodes, requires the use of multi-fiber cables – which complicates the installation and maintenance of cable lines – but it allows the use of well-studied and inexpensive equipment. In principle, this option seems more preferable to me.
But I also had a desire to get acquainted with PON technologies, to evaluate their pros and cons not on paper and from promotional brochures, but in real-world conditions.

This article is a translation of the original Russian-language post.My journey of learning GPON