Splicing G.652 and G.657 Fibers — Test Results

As promised, here are the results of a small experiment on splicing G.652D and G.657 fibers. Just to recap, this experiment was prompted by the common belief that splicing G.652D to G.657B results in significant loss — reportedly as high as 0.6 dB.

For the experiment, we used: a Fujikura FSM-50S fusion splicer (our daily workhorse), a Fujikura CT-30 cleaver, a Miller FO 103-T-250-J stripper, a Yokogawa AQ7275 optical time-domain reflectometer (which can also generate a stable 0 dBm / 1 mW optical signal), an SNR-PMT-08C optical power meter, two FC/UPC‑to‑SC/APC patch cords for connecting to the OTDR and power meter, two SC‑SC APC adapters, lint‑free Kimwipes wipes, isopropyl alcohol, and an SC/APC‑to‑SC/APC single‑mode patch cord (0.9 mm, G.652D) which we'd be splicing to the other fiber type.

The measurement setup: OTDR → FC/UPC‑to‑SC/APC cord → adapter → SC/APC‑to‑SC/APC patch cord → adapter → SC/APC‑to‑FC/UPC cord → power meter.

The initial signal level measurements gave us the following readings:

• At 1310 nm: 0.76 mW
• At 1550 nm: 0.81 mW

The photo actually shows 0.80 mW at 1550 nm — the meter was fluctuating between 0.80 and 0.81 mW, but it settled on 0.81 most of the time. Reversing the patch cord gave slightly different results: 0.73 mW at 1310 nm and 0.76 mW at 1550 nm, which I attribute to minor core misalignment in the connectors. When I swapped the connectors back, the readings returned to their original values.

After unpacking the patch cord, we measured it again and got the same numbers — so coiling the fiber with a large radius didn't affect the loss.

Next, as a control test, we cut the patch cord and respliced it — the results stayed the same. We also made another splice with a heat‑shrink protection sleeve — again, no change in optical power levels.

To make sure the results weren't being affected by connector variations, we decided to leave the connectors alone and splice a section of bend‑insensitive fiber directly into the patch cord. Since we'd been splicing this fiber from our splitters into the network, we borrowed a piece from an optical splitter:

This gave us two splices between standard and bend‑insensitive fiber, with the loss split across both joints.

It's worth noting that the splicer might misidentify the fiber type and throw up a loss estimate error. On various forums, professionals recommend forcing the "SM Autocalibrate" mode for this type of splice.

After several splice attempts, we got these power readings:

• At 1310 nm: 0.75 mW
• At 1550 nm: 0.80 mW

Converting these to decibels:

• At 1310 nm: 0.76 mW (−1.19 dBm) → 0.75 mW (−1.25 dBm) = 0.06 dB
• At 1550 nm: 0.81 mW (−0.92 dBm) → 0.80 mW (−0.97 dBm) = 0.05 dB

Keep in mind this is the loss across two splices. So the average loss per splice works out to about 0.03 dB — which is comparable to splicing standard fibers (though admittedly not the best‑quality splices).

Here are a few photos taken during the splicing process:

Splice between standard G.652D fiber and bend‑insensitive G.657B fiber (left).

Splice between standard G.652D fiber and bend‑insensitive G.657A fiber (right). Type "A" fiber is recommended for splicing to standard fiber since it has a matching mode field diameter. In the photo, you can see a slightly more pronounced gradient between the core and cladding materials.

And finally, a short video:

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

G.652 to G.657 Fiber Splicing

As it turns out, the planar splitters we bought use bend‑insensitive fiber — G.657 standard. Based on what I could see on the splicer screen, the input fiber looks like G.657.B, while the output fibers look like G.657.A. That's not a definitive identification, of course — the splitter documentation doesn't specify the fiber types, only the insertion loss and return loss measurements. The "B" type fiber is recognizable on screen by a clear gradient from the core to the cladding — sharp transitions that are easy to see. This is due to a smaller mode field diameter and special doping. Standard fiber, by contrast, has a core that's almost all one color, with barely visible stripes running along it. The "A" type fiber looks more like G.652 — the stripes at the edges of the core are a bit more noticeable, but the mode field diameter matches that of standard fiber. So splicing standard single‑mode fiber to "bend‑insensitive" G.657.A shouldn't cause any problems. And that's exactly what we saw in practice. The only thing is, because of the different materials, you can see a thin vertical line at the splice point. The splicer estimates loss about the same as for identical fibers, and in most cases we got splice losses around 0.01‑0.03 dB.

When splicing standard fiber to "bend‑insensitive type B," though, we ran into trouble. The splicer identifies G.657.B as non‑zero dispersion‑shifted fiber (NZDSF — it shows up as "NZ" on the screen). That said, the actual splice process looked pretty clean — the arc was stable, and any bubbles we got were mostly due to poor cleaves, which happens with standard fiber too. What bothered me was that no matter how good the splice looked, the splicer always threw up some kind of error at the end. And of course, you could easily see the splice point on the screen. So I spent the evening browsing forums to see how others were handling this. In the end, I settled on using the "SM Auto" mode (standard single‑mode with automatic calibration) and evaluating splice quality visually — looking for a clean, stable arc with no spots or flashes, and ignoring the splicer's loss estimate altogether. In theory, you could measure the loss with an OTDR, but as I mentioned earlier, we're splicing the input fiber to the splitter — which is less than a meter long — so the splice wouldn't even show up on the trace; it'd be buried in the OTDR's dead zone and reflections. That leaves only one option: measuring the optical signal level before and after the splice. But unfortunately, for various reasons, that's not always practical.

While searching for information, I came across an article that reported splice losses for these fiber types. On average, they were around 0.6 dB — which is quite high compared to the 0.1 dB maximum typically allowed for a splice. I'm planning to run some tests with actual signal level measurements in the next few days, and I'll definitely post the results.

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

A Few Words About the Network and Splitters

I want to apologize for the long silence on the blog. As you know, summer is the busy season for fiber installers. Every day it's field work — rooftops, private residential areas. You have to get cables laid out along the routes, splice closures — basically, there's a ton of work and not enough time.

And that's exactly where we are now — we've started building our passive optical network. Every day it's up the ladder, unspooling cable from poles, splicing closures, and coiling it all back up again :) The weather's been cooperating, though spending hours under the sun takes its toll. We're going through water by the bucket. But that's not what I wanted to write about.

The real surprise during the build was splicing standard single‑mode fiber — ITU‑T G.652.D — which is what both the cable and splitter manufacturers specify. For our lines, we're using OKPM‑02‑6×4E3‑(9.0) cable from Moskabel‑Fujikura. This cable has 24 standard single‑mode fibers with an extra low‑loss window — meaning there's practically no excess loss between the 1310 nm and 1550 nm windows, so you can use WDM to increase capacity. For regular networks, this is the most common fiber type. I'm mentioning the 24‑fiber cable as an example — in practice, we use cables ranging from 8 to 144 fibers.

For splitting the optical signal, we bought planar splitters in 2‑way, 4‑way, and 8‑way configurations. Just to recap: planar splitters are made using the same technology as microprocessors — layers are deposited onto a substrate through a mask. Fused splitters, by contrast, are made by fusing two fibers at an X‑shaped intersection. Planar splitters have more stable characteristics — less variation in insertion loss between taps — and most come in a compact housing that's easier to fit inside splice closures. Plus, their passband covers the full PON wavelength range — roughly from 1260 to 1650 nm.

As I mentioned earlier, the first splitter (8‑way) is connectorized, while the downstream subscriber splitter (also 8‑way) is spliced in at the input. During the design and construction phase, we also decided to create subscriber "extensions." That means we put an 8‑way splitter in the subscriber closure, but at that particular location we might only use 4 taps. The remaining taps get spliced to drop cables and routed to a remote group of buildings, where they terminate in a 4‑port enclosure. Inside the enclosure, those four fibers are connected to adapters via pigtails for customer hookups. The reasoning behind this approach was to simplify the connection process and reduce the number of subscriber cables hanging on utility poles. After all, four cables converging on a single pole at the center of a building group looks a lot cleaner than four (or more) parallel cables running the entire last span to the closure.

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

Line Troubleshooting. Part 3

I'd say this section is still mostly theoretical, because I want to think out loud a bit about using an OTDR to find high-loss points in fiber lines. We do have an OTDR at the company, and I've even used it successfully — but only on regular point‑to‑point links, like from a node to a building or between two nodes. In a PON setup, though, you've got optical splitters dividing the signal. Since our company also offers cable TV services alongside Internet access, the trace on the OTDR screen looks somewhat familiar. In cable TV networks, we also use optical splitters — and in fact, PON is designed to carry the TV signal on the same fiber to subscribers, using the 1550 nm wavelength band. That's the classic wavelength for CATV, just like 1310 nm. But you can't use 1310 nm in PON — that's the upstream wavelength from subscribers to the OLT. Which immediately creates a problem: you can't take an OTDR measurement from the headend on 1310 nm, even if only one subscriber is connected. And what if there's more than one? Plus, any attempt to measure would knock all subscribers on that PON branch offline.

I should probably explain a bit about how an OTDR works. It's an incredibly useful tool for anyone working with cables. In a nutshell: the OTDR fires a laser pulse into the fiber — it knows exactly how long, how powerful, and when it sent that pulse — and then starts measuring the reflected signal. The signal reflects back from the fiber material itself (that's called backscatter) and from any imperfections along the way. By analyzing how long it takes for the reflection to return and how strong it is, the OTDR builds a visual map of the fiber. You can see excessive loss as a downward step on the trace. Loss usually shows up at bad splices or where the fiber's bent too tightly. Reflections from imperfections, on the other hand, show up as spikes. These are typically connectorized joints (where the signal crosses from one medium to another) or cracks in the fiber. Since the OTDR knows the round‑trip time and the speed of light in the fiber, it can calculate the distance to each event. So you get a complete profile of loss and distance from the measurement point. If you know the cable route and span lengths, you can usually pinpoint exactly where the problem is.

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

Line Troubleshooting. Part 2

I don't know if it's actually true, but you constantly see posts online about the danger of an ONU getting stuck in PON networks. If the laser on an ONU stays on, it can bring down the entire branch it's connected to. Here's why. As I mentioned earlier, the OLT constantly sends commands telling each ONU when it's allowed to transmit upstream. It also sends periodic signals to check for new devices. Either way, every ONU needs to send data back to the OLT from time to time — and managing those transmission windows is the whole foundation of PON.

Now let's look at what happens in more detail. The OLT sends data and instructions to a specific ONU on 1490 nm, telling it, for example, that it expects upstream traffic and status info at a certain time. The ONU waits for that slot and starts transmitting on 1310 nm. But if a faulty ONU has its laser stuck on at the same wavelength, the OLT receives both the signal from the working ONU and noise from the stuck one at the same time. The OLT can't properly decode the data, so it retries. And it'll do this for every ONU on that branch — eventually none of them will be able to transmit successfully.

That said, these cases are pretty rare. I've only ever read about the risk — I've never actually seen anyone on a forum describe it actually happening. Plus, manufacturers build hardware safeguards into their equipment to prevent stuck lasers.

What's even worse is when someone plugs any 1310 nm transmitting device into a subscriber's fiber — like a media converter, a switch with an optical port, or an SFP module. Any subscriber with a basic understanding of fiber optics could do this. Whether they're trying to cause trouble or just curious about what happens doesn't really matter. The bottom line is that everyone else on that branch loses Internet access, and the operator gets all the complaints.

To be honest, I actually ran a test in the lab. I connected a 20 km media converter to a PON setup I'd built on a bench using CATV splitters. Total split ratio was 108 ways — three splitters in series: 6, 6, and 3 ways — with total loss around 21 dB. And the PON equipment kept working just fine. Maybe the media converter I used had a weak laser, but real-world PON losses are higher anyway. For reference, a typical 64‑way split using two 1×8 planar splitters gives about 20‑21 dB loss, plus another 3‑4 dB for connectors.

In general, the probability of an OLT receiver being blinded by external signals is pretty low — but it's still possible. That's why network designers usually include the ability to disconnect individual branches, all the way down to the subscriber level. The easiest way is to put splitters on connectors, so you can just unplug a branch. All you'd need is a pigtail spliced to the outgoing fiber and connected to the splitter tap through an optical outlet.

If you do run into interference and everything is spliced, your only option is to visit every subscriber and unplug their ONUs until you find the culprit — or call them and ask to power down their devices. But there's a good chance the subscriber won't be home. In that case, you have to grab your splicer and start breaking and re‑splicing fibers one by one. That's not exactly fun — splice closures are usually up on poles. If the connections are connectorized, though, you can isolate the source much faster by just unplugging branches. Start at the main closure to find the problem segment, then work your way down to the subscriber drops until you find the noisy connection.

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

Line Troubleshooting. Part 1

When designing a PON network, you're constantly balancing optical budget against maintainability. As they say, you can never have too much budget — so ideally, the entire path from OLT to subscriber would have no connectors at all, just splices. But that's not really practical. Imagine having to strip the incoming cable, glue a connector onto the fiber, and plug it straight into the OLT's SFP port. I'd love to have equipment that could re‑coat the fiber with buffer material in the field. On top of that, epoxy‑termination is a pain — you need special tools and gear for polishing, curing, and inspecting the polish quality.

So most operators use pre‑terminated pigtails instead — these are factory‑made fiber tails with a connector already glued, cleaved, polished, and tested for loss. Then you just splice the pigtail to the cable fiber inside splice closures or distribution frames, which protect the splices from damage and the elements. Cross‑connections to outside lines are done through optical outlets. So right off the bat, we've already got one connectorized joint in our link — actually three: two at the OLT port (one on each side of the adapter) and one at the ONU input. These are unavoidable. The number of additional connectors depends on the designer.

In our network, as I mentioned before, we add one more connector at the splice closure where the subscriber drop cable connects, plus two connectors on the top‑level splitter — one at the input and one at the tap. That gives us a total of six connectorized joints in the link. Typical loss per connector, according to manufacturers, is about 0.5 dB, which adds up to 3 dB total for all six. For splices, industry standards allow up to 0.1 dB loss, but in practice that's a very conservative number. Fujikura, for example, measured their splicers' average losses in the 0.01‑0.03 dB range — which, as you'll agree, is way lower than the budget you'd normally reserve.

Connectorized joints are a potential source of trouble, and the more you have, the higher the chance of something going wrong. Plus, connectors at the top of the network affect service for many subscribers at once. In my experience, I've run into excessive loss on adapters quite often, and replacing the outlet usually fixes the problem.

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

Planning the Distribution Network. Part 3.

You often come across posts online about pretty strict requirements for splice and connector quality in PON networks. Some say you need specialized fusion splicers, others insist that every single joint should be checked with an OTDR right away. Since our company also runs a cable TV operation — where optical losses are quite critical — we've made it a rule from day one to keep splice loss below 0.03 dB per the splicer's reading.

That said, the splicer's loss estimate is only an approximation. Real-world measurements often give different numbers. So we also visually inspect every splice as it's being made. A bad splice is usually obvious right away — you'll see dark spots or black dots, which are air bubbles. The splicer doesn't always catch these properly, so it's better to play it safe and re‑splice any suspicious spot.

One thing to keep in mind: you're far more likely to run into high loss at a connector (through an adapter) than at a fusion splice. A single bad connector can ruin all your perfect splices along the line. I should also mention that the quality of pigtails and patch cords you buy these days is pretty hit‑or‑miss. I haven't found any real correlation between price and quality, or even between brands. Most of the time it's acceptable, but there's always an element of luck involved.

The big question during construction was how to connect the splitters into the line: should we splice them directly in, or use adapters (optical outlets)? With the first approach, we reduce loss by minimizing the number of connectorized joints. With the second, we gain flexibility — we can reconfigure or replace splitters to redirect power as needed, without having to do any extra work on the fiber itself. But it's hard to anticipate every possible distribution scenario, and this setup really only works well for bus‑type connections. Adding a subscriber at the far end, for example, would mean replacing every splitter along the line — and so on. There are so many nuances that it's tough to make the right strategic call. So in most cases, you simply can't avoid fusion splicing.

In our case, we could have done everything with splices, since we designed for 100% take‑rate and don't expect any changes to the signal distribution. But as I mentioned earlier, subscriber connections will be done using pre‑made patch cords — so using an outlet at the final drop is a must. The splitter itself is spliced to the incoming fiber on its input side. For the top‑level splitter — the one that divides the signal into major directions — we decided to go fully connectorized.

I'll explain why in the next post.

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

Planning the Distribution Network. Part 2.

In reality, network topologies are rarely used in their pure form. The main reason is the wide variety of deployment conditions — you have to account for all sorts of factors in each specific situation: where buildings are located, distances between subscriber groups, total line length, and many more. For example, you might split the signal three ways at the start, then run a bus to two subscribers, followed by a 16-way splitter. There are countless combinations, and there's no one-size-fits-all solution.

Another factor is the expected take‑rate — the percentage of subscribers you plan to connect. For a group of buildings, one operator might reserve enough power for 100% of potential subscribers, another might plan for 50‑70%, and someone else might consider 20% or even 90% sufficient. The projected take‑rate depends on residents' income levels, the cost of connection, payback periods, competition, and existing infrastructure. In a monopoly situation, you can expect a high percentage; but if you're entering an area where another provider has been operating for a long time, you'll probably see much lower numbers.

For our own network, we decided to design for 100% take‑rate. The reasoning was simple: we wanted to build the entire network all the way to the subscriber tap points from the very beginning. That way, connecting a new customer would just mean running a pre‑made patch cord from the nearest splice closure — or making one on the spot using quick‑connect connectors. No additional work on the main fiber would be required. This means a regular field tech could handle the connection, without having to call in specialized fusion splicers.

If we had planned for a lower percentage, we'd run the risk of eventually running out of available taps in a particular area. That would force us to do extra work — splicing in additional fibers, replacing splitters, allocating more OLT ports, and so on. Of course, you can never be 100% sure that no new connection points will appear down the road. But planning for full coverage significantly reduces that risk. Chances are, we'll never actually reach 100% take‑rate — but if that happens, there's a nice upside: every connected subscriber gets more bandwidth available on both downstream and upstream.

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

Planning the Distribution Network. Part 1.

What makes PON technology so great is that you don't have any active equipment out in the field. That means no power hookups, no UPS units to install and maintain, no swapping out failed gear, no keeping spare units on hand, and no extra staff to send out for node maintenance. All those headaches just disappear.

Of course, PON has its drawbacks too — we'll cover those in a later post. And I'm sure we'll run into some unexpected issues during construction and day-to-day operation.

When we started planning the distribution network, two main questions came up: how to split the signal along the line, and how to make branches from the main trunk. These sound similar, but they're actually completely different problems.

There are several common approaches to signal splitting.

First, the centralized approach. You run a dedicated fiber from the central node all the way to each subscriber. The downside is pretty obvious — it's expensive. Multi-fiber cables cost a lot, and you have to terminate all those fibers at the central office. Sure, there are high-density modular splice trays and frames these days, but they take up a lot of space and aren't easy to fit into existing facilities. In a PON setup, you put the optical splitters right in that same cabinet and feed each subscriber individually. The big advantage is that you can add OLT ports gradually as subscribers sign up. This works especially well in apartment buildings, where cable runs are short and maintenance is straightforward. Plus, signal levels at every subscriber drop end up nearly identical — the only variations come from cable length differences and minor splitter tap loss variations.

Second, the bus configuration. Here you use splitters with uneven tap ratios. For example, if you're serving 64 ONUs from one OLT port and you've got 8 subscribers on the first tap, you'd use a splitter with a 12:88 ratio — 12% goes to those 8 subscribers, and 88% continues down the line. Why 12%? Because each subscriber needs roughly 1/64 of the OLT's signal power, or about 1.5%. For 8 subscribers, that adds up to 12%. Further down the line, you'd use splitters with ratios like 14:86, 17:83, 20:80, 25:75, 33:67, and finally 50:50.

The advantage here is that you only need one trunk fiber for the entire run, which saves a lot on cable costs. You can also select splitters to balance signal levels across all subscribers. The downside is that you end up with many different splitter types — most of which you'd have to order as custom builds. In practice, splitters are pretty robust. In all my years, I've only seen two fail: one was dead out of the box, and another lost a tap after some time in service. I couldn't tell you what caused either one. You'll probably want to keep spare splitters of each type in stock. Also, uneven splitters are still made by fusing fibers, and it's hard to get precise isolation between taps. Manufacturers give themselves a margin of error, and when you cascade several of these, those errors stack up — so what you get at the far end isn't always what you calculated.

Third, the star topology. Here you split the signal into multiple directions at certain points. Ideally, you place these split points in the center of your distribution area, and sometimes fibers from that point go back the way they came. Often those fibers are actually in the same cable. Then each arm of the star can be split further in the same way. It's not really a star at that point — more like a snowflake. But again, all those "arms" might still be bundled in one cable. So why bother? Because this makes it much easier to distribute optical power using just a handful of splitter types. For instance, in our network we plan to use 2-way, 4-way, and 8-way splitters with even splits. Say you've got an 8-way splitter roughly in the middle of a cable run. Half the taps go forward, the other half loop back. On each side, those taps can split into 8, or into 2 then 4, depending on how many buildings are there and where they're located. In total, you get 64 subscribers per OLT port (8×8 or 8×2×4).

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

We’re going with GPON

Reading through hardware specs, digging for scarce info on websites, and browsing tech forums for ISPs, I kept second-guessing myself: which tech should I actually use for my network? Honestly, every option has its pros and cons. For GEPON, the big plus was that it’s based on Ethernet protocols. It’s pretty much an extension of standard LAN hardware lines, which, in theory, should make it cheaper. GPON is different because it handles various types of data—like ATM cells, Ethernet frames, and TDM—all packed into GEM frames. To send Ethernet traffic, the hardware has to chop up the packets into frames first and then piece them back together on the receiving end. This puts a heavier load on the hardware doing the heavy lifting, which ultimately drives up the price. Though to be fair, lately that price gap hasn't been all that big.
But GPON still has a couple more things going for it. First off, downstream bandwidth is bumped up to 2.5 Gbps, while GEPON gives you an equal 1.25 Gbps both ways. Second, there's physical layer bandwidth efficiency. GPON hits about 93%, while its competitor sits around 68-72%. This means that out of a gigabit, you only get about 850-900 Mbps of real data, with the rest swallowed up by overhead. Third, most GEPON user devices only come with FastEthernet ports, and just a few support gigabit speeds. In the opposite camp, pretty much every device is packed with gigabit ports, which gives you bragging rights to market an imaginary edge over other ISPs :). On top of all that, in most polls people seem to vote for GPON—not sure why, honestly.
Price-wise, we went for the most budget-friendly option. Like I said, we didn't really feel like dropping big money on an unfamiliar technology. Among the budget solutions, we settled on Dasan Networks, a South Korean hardware manufacturer. The gear is already bought—we got an OLT and a few 2-port and 4-port ONUs.

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

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