Coordinated Multi-Point (CoMP) is a technique in 5G and LTE-Advanced networks designed to improve network performance in terms of capacity, throughput, and reliability, especially at the cell edges where interference is typically higher.

If there is one sentence worth holding on to before the terminology starts, it is this. In an ordinary network the neighbouring cell is a nuisance to be tolerated. In CoMP it becomes a resource to be used.

It also helps to know that CoMP is not one technique. It is a family of four, and they have more in common in what they achieve than in what they cost. What separates them is how much the two transmission points have to share with each other, and how quickly. That single factor decides which of them you can deploy. It also explains why the impressive numbers in the early CoMP literature were so hard to reproduce in a live network.

Basically CoMP in 5G is almost same as CoMP introduced in LTE advanced.

That is true of the concepts, but not of the vocabulary, and the difference catches people out. If you search the 5G specifications for CoMP you will not find it. There is no CoMP feature in NR, no CoMP clause and no CoMP configuration. The same ideas are all there, but they arrive under a different heading called multi-TRP. I have given that mapping a section of its own further down. If you already know the LTE version, it is probably the one to read first.

• Why is the cell edge such a hard place ?
• Key Concepts of CoMP
• Four schemes, one question
• Coherent or non-coherent joint transmission ?
• Uplink CoMP is a different, and easier, problem
• Benefits
• Challenges
• Implementation in 5G
• How CoMP actually appears in 5G NR
• UE Capability
• Use Cases

Why is the cell edge such a hard place ?

Before looking at what CoMP does, it is worth being precise about the problem it is solving. The cell edge is not difficult because the signal is weak. It is difficult because of what arrives with it.

Walk away from a base station and the wanted signal falls off. That much is obvious. But as you walk away from one cell you are walking towards another, so the interference from the neighbour rises at the same time. Both things move in the wrong direction at once. That is why cell edge SINR falls much faster than cell edge RSRP does.

Turning up the transmit power does not help either, and the reason is worth stating plainly. If every cell raises its power, the wanted signal and the interference rise together, and SINR stays exactly where it was. At the cell edge the network is interference limited, not power limited. You cannot buy your way out with watts.

Now here is the observation that the whole of CoMP is built on. The interference is not noise. It is a perfectly good signal, from a base station that the operator also owns. It carries data the operator also controls, on hardware that can be told what to do. Thermal noise cannot be negotiated with. A neighbouring gNB can.

So the question stops being 'how do we suppress the interference' and becomes 'what should the other transmitter do instead'. Every CoMP scheme is one answer to that question.

Key Concepts of CoMP

Coordinated Multi-Point (CoMP) is a transformative feature in modern wireless networks, enabling multiple base stations or transmission points, such as gNBs in 5G, to work together in serving a user equipment (UE). By facilitating seamless coordination across these transmission points, CoMP mitigates inter-cell interference (ICI), delivering a more consistent and robust user experience across the network. The primary objectives of CoMP are to enhance the performance for users at the cell edges and to improve spectral efficiency and data rates throughout the network. This is achieved through various implementation techniques, including Joint Transmission (JT), where multiple points transmit the same data simultaneously to strengthen signal reliability; Dynamic Point Selection (DPS), which dynamically chooses the optimal transmission point for the UE; Coordinated Beamforming (CB), which aligns beam patterns to maximize the signal-to-noise ratio while minimizing interference; and Coordinated Scheduling and Transmission (CST), which optimizes resource allocation to prevent interference. Together, these techniques underscore CoMP's pivotal role in enabling high-performance, interference-resilient networks.

• Coordination Across Base Stations (gNBs):
• CoMP enables multiple base stations or transmission/reception points to coordinate their actions to serve a user equipment (UE).
• This coordination can mitigate interference and provide a more uniform user experience across the network.
• Objective:
• Enhance cell-edge performance by reducing inter-cell interference (ICI).
• Improve overall spectral efficiency and data rates.
• Techniques: CoMP involves multiple techniques depending on how the coordination is implemented:
• Joint Transmission (JT): Multiple transmission points transmit the same data simultaneously to the UE, improving signal strength and reliability through constructive interference.
• Dynamic Point Selection (DPS): The data transmission dynamically switches between multiple transmission points, ensuring the UE always receives data from the best point.
• Coordinated Beamforming (CB): Transmission points coordinate their beamforming patterns to minimize interference with neighboring cells while maximizing signal strength to the target UE.
• Coordinated Scheduling and Transmission (CST): Neighboring cells coordinate their resource allocation and scheduling to avoid interference.

Four schemes, one question

The previous section lists the four techniques. They are much easier to remember as four different answers to one question. What do we do about TRP 2 ?

Read left to right, top to bottom. The four answers are : recruit it, mute it, aim it away, or move it out of the way. That ordering is not arbitrary. It runs from the scheme that gains the most to the scheme that costs the least. The table below shows why those two things pull in opposite directions.

That backhaul column is the one that decides what actually gets deployed. Joint transmission needs the two points to behave as one radio. In practice that means two radio units hanging off the same baseband, not two independent sites. Coordinated scheduling only needs the two schedulers to agree on who uses what. That agreement can travel over an ordinary Xn interface, at ordinary latencies.

NOTE : This is why so much of the early CoMP literature promised large gains that did not appear in real networks. The gains were real, but they assumed the ideal backhaul case. Most inter-site deployments could only support the schemes at the bottom of the table.

Coherent or non-coherent joint transmission ?

Joint transmission comes in two forms, and the difference between them is larger than the name suggests.

Coherent JT means the two points transmit the same symbols with their phases deliberately aligned. The two copies then add constructively at the UE antenna. This is the version that gives an array gain, and on paper it is the most attractive of everything on this page.

It is also very hard. To make two waves add at a point, you have to control their relative phase at that point. That means the two transmitters need a common phase reference. The propagation delay difference has to be known and compensated. Any drift between the two local oscillators has to be tracked as well. Doing this between two radio units on the same baseband is difficult. Doing it between two sites, over a backhaul link, at millimetre wave, is another matter entirely.

Non-coherent JT gives up on phase alignment. The two points transmit different layers, or different redundancy versions, and the UE separates them the way it separates any MIMO stream. Nothing needs to add up in phase. The gain is spatial multiplexing or diversity rather than array gain.

5G NR standardised the non-coherent version, and it is usually written NC-JT. That choice tells you a lot about what turned out to be practical. The industry took the smaller, robust gain over the larger, fragile one.

Uplink CoMP is a different, and easier, problem

Everything above is about the downlink, and that is where most descriptions of CoMP stop. The uplink deserves a paragraph of its own, because it is the easier half and it was deployed first.

In the uplink the UE transmits once, and several reception points hear it. Nothing has to be coordinated at the transmitter at all. The receivers simply forward what they heard to a common point, which combines the copies and decodes. This is usually called joint reception.

Why is that so much easier ? Because combining happens after the fact, in a processor, on stored samples. There is no phase to align in the air and no deadline to hit before transmission. If the samples arrive late, they are still useful. Compare that with coherent JT, where being late by a fraction of a symbol destroys the gain you were trying to get.

There is a second advantage that matters commercially. Uplink joint reception is invisible to the UE. The device transmits exactly as it always would, and has no idea that three sites are listening. So it needs no UE support, no new signalling, and no specification work. That is why it appeared in networks well before any downlink scheme did.

Benefits

CoMP brings significant advantages to wireless networks by addressing critical challenges such as interference and coverage gaps. One of its primary benefits is an enhanced user experience, particularly for users at the cell edges, where improved signal-to-interference-plus-noise ratio (SINR) translates to higher data rates and greater reliability. CoMP also excels at mitigating inter-cell interference, a common issue in dense network deployments, ensuring more stable and efficient communication. Additionally, by optimizing resource coordination across multiple transmission points, CoMP delivers substantial capacity gains, allowing for better utilization of the available spectrum. For users in areas of poor coverage, such as cell edges, the coordinated signal enhancements provided by CoMP significantly improve connectivity, making it a key enabler for robust and high-performance networks.

• Enhanced User Experience:
• By improving signal-to-interference-plus-noise ratio (SINR), users at the cell edges experience higher data rates and better reliability.
• Interference Mitigation:
• CoMP effectively reduces inter-cell interference, a significant problem in dense deployments.
• Capacity Gains:
• Better utilization of available spectrum due to coordinated resource usage.
• Improved Coverage:
• Users in poor coverage areas (e.g., cell edges) benefit from coordinated signal enhancements.

Challenges

CoMP offers transformative benefits to wireless networks, its implementation is not without challenges. One significant hurdle is the high backhaul requirement, as CoMP demands low-latency and high-capacity communication between base stations or transmission points to facilitate real-time coordination. The computational complexity of CoMP is also considerable, as it relies on advanced signal processing and scheduling algorithms to manage coordination effectively. Precise synchronization among transmission points is another critical factor, particularly for techniques like joint transmission, where any misalignment can result in destructive interference. Additionally, scalability poses a challenge in dense network environments, as the overhead associated with coordinating multiple cells can strain resources and impact performance. Addressing these challenges is essential to fully realize the potential of CoMP in modern wireless networks.

• High Backhaul Requirements:
• CoMP requires low-latency, high-capacity communication between base stations or transmission points to exchange coordination information.
• Increased Computational Complexity:
• Advanced signal processing and scheduling algorithms are required for coordination.
• Synchronization:
• Precise synchronization among the transmission points is crucial for techniques like joint transmission to avoid destructive interference.
• Scalability:
• In dense networks with many cells, the overhead for coordination can become significant.

Implementation in 5G

In 5G networks, CoMP has been significantly enhanced compared to its implementation in LTE, leveraging the advanced features of 5G technology. Massive MIMO, a cornerstone of 5G, provides advanced beamforming capabilities that enable more precise and effective coordination among transmission points. The ultra-reliable low-latency communication (URLLC) supported by the 5G architecture further facilitates real-time coordination between base stations, ensuring seamless and efficient operation of CoMP techniques. Additionally, CoMP proves especially valuable in the higher spectrum bands used by 5G, such as millimeter-wave (mmWave), where coverage is inherently more challenging. These improvements make CoMP a critical tool for achieving the performance, capacity, and coverage goals of 5G networks.

In 5G, CoMP is enhanced compared to LTE due to:

• Massive MIMO: Advanced beamforming capabilities in 5G allow better coordination and precision.
• Low Latency: The 5G architecture supports ultra-reliable low-latency communication (URLLC), enabling real-time coordination between base stations.
• Higher Spectrum Bands: CoMP is particularly useful in high-frequency bands (e.g., mmWave) where coverage is more challenging.

How CoMP actually appears in 5G NR

Here is something that surprises people who go looking for CoMP in the 5G specifications. They will not find it. There is no feature called CoMP in the NR specifications, no CoMP clause, and no CoMP configuration.

That is a change from LTE. In LTE Release 11, CoMP was an explicit feature, with its own transmission mode, its own CSI processes and its own CoMP hypotheses. In NR the same objectives are met by a more general framework called multi-TRP, or mTRP, introduced in Release 16. So the concepts on this page are still exactly right. It is only the vocabulary that moved.

The framework splits in two, and the split is the first thing to get straight.

Notice what the two flavours are really distinguishing. It is not which CoMP scheme you get. It is whether the two points run one scheduler between them or one scheduler each.

In the multi-DCI case each TRP has its own CORESET pool, its own PDCCH and its own PDSCH, with independent HARQ. The two points barely have to agree on anything in real time, which is why this is the variant that survives a non-ideal backhaul. In the single-DCI case one TRP sends the only PDCCH, and the DCI it carries points at two TCI states at once. One transport block is then split across both points.

The RRC parameters are worth recognising when you meet them in a log. The first thing to know is that they are not in one place. Multi-TRP configuration is spread across four information elements at three different levels, so there is no single branch to look under.

Where the multi-TRP configuration lives

CellGroupConfig
 |
 |-- physicalCellGroupConfig --------> PhysicalCellGroupConfig          per cell group
 |                                       ackNackFeedbackMode-r16
 |                                       pdsch-HARQ-ACK-CodebookList-r16
 |
 |-- spCellConfig
       |-- spCellConfigDedicated ----> ServingCellConfig                per serving cell
             |                           enableTwoDefaultTCI-States-r16
             |                           enableDefaultTCI-StatePerCoresetPoolIndex-r16
             |                           crs-RateMatch-PerCORESETPoolIndex-r16
             |                           lte-CRS-PatternList1-r16
             |                           lte-CRS-PatternList2-r16
             |
             |-- downlinkBWP-ToAddModList
                   |-- BWP-Downlink
                         |-- bwp-Dedicated
                               |-- pdsch-Config --> PDSCH-Config        per bandwidth part
                               |                      repetitionSchemeConfig-r16
                               |
                               |-- pdcch-Config --> PDCCH-Config
                                     |-- controlResourceSetToAddModList
                                           |-- ControlResourceSet       per CORESET
                                                 coresetPoolIndex-r16

SCells reach the same ServingCellConfig through sCellToAddModList instead of spCellConfig.

Notice what each level is responsible for. A CORESET belongs to one TRP or the other. A bandwidth part decides how the PDSCH is split between them. A serving cell decides the default beams and the LTE coexistence handling. The cell group decides how HARQ feedback comes back. That scattering is the main reason multi-TRP is awkward to read off a live RRC message.

Here is the whole set, grouped the same way.

-- per CORESET ------------------------------------------------------------------

ControlResourceSet ::=                   SEQUENCE {
    ...
    [[
    coresetPoolIndex-r16                 INTEGER (0..1)                            OPTIONAL,  -- Need S
    ...
    ]]
}

maxNrofCoresetPools-r16                  INTEGER ::= 2

-- per bandwidth part -----------------------------------------------------------

PDSCH-Config ::=                         SEQUENCE {
    ...
    [[
    repetitionSchemeConfig-r16           SetupRelease { RepetitionSchemeConfig-r16 }   OPTIONAL,  -- Need M
    ...
    ]]
}

RepetitionSchemeConfig-r16 ::=           CHOICE {
    fdm-TDM-r16                          SetupRelease { FDM-TDM-r16 },
    slotBased-r16                        SetupRelease { SlotBased-r16 }
}

FDM-TDM-r16 ::=                          SEQUENCE {
    repetitionScheme-r16                 ENUMERATED {fdmSchemeA, fdmSchemeB, tdmSchemeA},
    startingSymbolOffsetK-r16            INTEGER (0..7)                            OPTIONAL   -- Need R
}

SlotBased-r16 ::=                        SEQUENCE {
    tciMapping-r16                       ENUMERATED {cyclicMapping, sequentialMapping},
    sequenceOffsetForRV-r16              INTEGER (1..3)
}

-- per serving cell -------------------------------------------------------------

ServingCellConfig ::=                    SEQUENCE {
    ...
    [[
    enableDefaultTCI-StatePerCoresetPoolIndex-r16   ENUMERATED {enabled}           OPTIONAL,  -- Need R
    enableTwoDefaultTCI-States-r16                  ENUMERATED {enabled}           OPTIONAL,  -- Need R
    crs-RateMatch-PerCORESETPoolIndex-r16           ENUMERATED {enabled}           OPTIONAL,  -- Need R
    lte-CRS-PatternList1-r16       SetupRelease { LTE-CRS-PatternList-r16 }        OPTIONAL,  -- Need M
    lte-CRS-PatternList2-r16       SetupRelease { LTE-CRS-PatternList-r16 }        OPTIONAL,  -- Need M
    ...
    ]]
}

LTE-CRS-PatternList-r16 ::=              SEQUENCE (SIZE (1..maxLTE-CRS-Patterns-r16))
                                             OF RateMatchPatternLTE-CRS

-- per cell group ---------------------------------------------------------------

PhysicalCellGroupConfig ::=              SEQUENCE {
    ...
    [[
    ackNackFeedbackMode-r16              ENUMERATED {joint, separate}              OPTIONAL,  -- Need R
    pdsch-HARQ-ACK-CodebookList-r16      SetupRelease {PDSCH-HARQ-ACK-CodebookList-r16}  OPTIONAL,  -- Need M
    ...
    ]]
}

PDSCH-HARQ-ACK-CodebookList-r16 ::=      SEQUENCE (SIZE (1..2)) OF ENUMERATED {semiStatic, dynamic}

• coresetPoolIndex-r16 is the multi-DCI switch : it takes the value 0 or 1. That is what assigns a CORESET to one TRP or the other. Two CORESETs with different pool indexes mean two independent schedulers, as far as the UE is concerned.
• Two TCI states in one codepoint is the single-DCI switch : the TCI field in the DCI is still three bits. But a codepoint can be mapped by MAC CE to a pair of TCI states rather than one. Two TCI states means two sources, and therefore two TRPs.
• The repetition schemes decide how the PDSCH is split : fdmSchemeA and fdmSchemeB divide it in frequency. The tdmSchemeA option divides it within a slot, and slotBased-r16 spreads repetitions across slots. The first is for throughput. The rest are for reliability.
• SDM is the throughput case : the two TRPs send different layers on the same time and frequency resources. This is non-coherent joint transmission, and it is the scheme that most closely matches JT in the older vocabulary.
• ackNackFeedbackMode-r16 chooses joint or separate HARQ : this is the RRC switch that pairs with the harqACK-jointMultiDCI-MultiTRP-r16 and harqACK-separateMultiDCI-MultiTRP-r16 capabilities in the next section. The capability says what the device can do. This field says which is used.
• The two default TCI state fields cover the gap before a beam is indicated : enableTwoDefaultTCI-States-r16 covers the single-DCI case. The multi-DCI equivalent is enableDefaultTCI-StatePerCoresetPoolIndex-r16. They matter when the scheduling offset is shorter than the UE needs to retune. That is the same default beam rule described on the beam management page.
• The CRS fields are an LTE coexistence item : where NR shares spectrum with LTE, the two TRPs may sit on different LTE carriers. Those carriers can carry different CRS patterns. That is why there are two pattern lists, and a switch to apply them per CORESET pool.
• Nothing here configures the pairing of beams : the TCI states themselves are configured in PDCCH-Config and PDSCH-Config as usual. Mapping two of them onto a single DCI codepoint is done by MAC CE, not by RRC. So there is no ASN.1 to show for the step that defines single-DCI multi-TRP, and looking for one is a common dead end.

One last mapping, to tie the two vocabularies together. Multi-DCI mTRP with the two points scheduling independently is the modern form of coordinated scheduling. Single-DCI mTRP with SDM is non-coherent joint transmission. Choosing one TRP and leaving the other quiet, which the UE sees simply as a TCI state change, is dynamic point selection. The ideas survived intact. Only the names in the specification changed.

UE Capability

Everything above describes what the network can do. Whether it can do it with a particular device is a separate question. The answer comes back in the UE capability message. That deserves a section of its own here, because the capability names follow the specification rather than the textbook.

Start with what you will not find. There is no UE capability called CoMP. Search the whole of 38.331 for the string and it does not appear once. Every relevant capability is named after multi-TRP instead, which is the same vocabulary shift as in the previous section.

The second surprise is that they do not all live in one place. They are split across two branches of the capability tree, and the split is not arbitrary.

UE-NR-Capability
 |
 |-- rf-Parameters
 |     |-- supportedBandListNR
 |           |-- BandNR
 |                 |-- mimo-ParametersPerBand ---> MIMO-ParametersPerBand
 |                                                 per band. Most of the multi-TRP flags live here.
 |
 |-- featureSets
       |-- featureSetsDownlinkPerCC-v1620
             |-- FeatureSetDownlinkPerCC-v1620
                   |-- multiDCI-MultiTRP-r16   ---> MultiDCI-MultiTRP-r16
                   |-- supportFDM-SchemeB-r16
                                                   per carrier. The resource limits live here.

Read that split as a statement about hardware. Whether a device can do multi-TRP at all depends on its radio and its antenna arrangement. So it is reported per band. How many CORESETs and PDSCHs it can juggle depends on its baseband budget, so it is reported per carrier.

The Release 15 precondition

Before any Release 16 flag matters, there is an older one. The multipleTCI flag says the UE can hold more than one TCI state active at a time. Without it there is only ever one beam to talk about, and nothing else on this list means anything.

Multi-DCI capabilities

MultiDCI-MultiTRP-r16 ::=              SEQUENCE {          -- per carrier
    maxNumberCORESET-r16                 ENUMERATED {n2, n3, n4, n5},
    maxNumberCORESETPerPoolIndex-r16     INTEGER (1..3),
    maxNumberUnicastPDSCH-PerPool-r16    ENUMERATED {n1, n2, n3, n4, n7}
}

-- and inside MIMO-ParametersPerBand, per band :

    multiDCI-multiTRP-Parameters-r16     SEQUENCE {
        overlapPDSCHsFullyFreqTime-r16          INTEGER (1..2)                    OPTIONAL,
        overlapPDSCHsInTimePartiallyFreq-r16    ENUMERATED {supported}            OPTIONAL,
        outOfOrderOperationDL-r16               SEQUENCE {
            supportPDCCH-ToPDSCH-r16                ENUMERATED {supported}        OPTIONAL,
            supportPDSCH-ToHARQ-ACK-r16             ENUMERATED {supported}        OPTIONAL
        }                                                                         OPTIONAL,
        outOfOrderOperationUL-r16               ENUMERATED {supported}            OPTIONAL,
        separateCRS-RateMatching-r16            ENUMERATED {supported}            OPTIONAL,
        defaultQCL-PerCORESETPoolIndex-r16      ENUMERATED {supported}            OPTIONAL,
        maxNumberActivatedTCI-States-r16        SEQUENCE {
            maxNumberPerCORESET-Pool-r16            ENUMERATED {n1, n2, n4, n8},
            maxTotalNumberAcrossCORESET-Pool-r16    ENUMERATED {n2, n4, n8, n16}
        }
    }                                                                             OPTIONAL,
    harqACK-jointMultiDCI-MultiTRP-r16      ENUMERATED {supported}                OPTIONAL,
    harqACK-separateMultiDCI-MultiTRP-r16   SEQUENCE {
        maxNumberLongPUCCHs-r16                 ENUMERATED {longAndLong,
                                                            longAndShort,
                                                            shortAndShort}        OPTIONAL
    }                                                                             OPTIONAL

• The out of order flags are the interesting ones : two independent schedulers work without asking each other. So the PDCCH, PDSCH and HARQ-ACK ordering can cross over. A Release 15 UE was never allowed to see that. The outOfOrderOperationDL-r16 and outOfOrderOperationUL-r16 flags are the device saying it can cope.
• HARQ feedback can be joint or separate : joint means one codebook covering both TRPs. Separate means one per TRP. That is why the separate case has to declare which combination of long and short PUCCHs it can send at once.
• Activated TCI states are counted twice : once per CORESET pool and once across both pools. A device may manage 8 per pool but only 16 in total. The second limit is not simply the first one doubled.
• separateCRS-RateMatching-r16 is an LTE coexistence item : where NR shares spectrum with LTE, each TRP may need its own CRS rate matching pattern. It has nothing to do with beams. It simply sits in the same list.

Single-DCI capabilities

Here there is roughly one flag per transmission scheme. That makes the list easy to read against the schemes described earlier.

One oddity is worth pointing at, because it looks like a mistake and is not. FDM scheme A is reported per band, while FDM scheme B is reported per carrier. The two are closely related schemes, so you would expect them together. They sit apart because scheme B needs soft combining of two redundancy versions. That is a buffer question rather than a radio question.

The one that decides everything in FR2

One capability matters more than all the others at millimetre wave, and its name does not mention multi-TRP at all.

simultaneousReceptionDiffTypeD-r16 asks a simple question. Can the device receive two different QCL-TypeD sources at the same instant ? QCL-TypeD is the spatial one. So in plain terms, this asks whether the UE can listen in two directions at once.

If it cannot, then SDM and FDM are simply impossible in FR2. Both need the two TRPs arriving in the same slot. That means two receive beams live together, and therefore two panels running at once. Many devices cannot do that. Some that can will not do it while the display is on, because of the power cost.

TDM is the escape route. If the two TRPs transmit in different slots, one panel is enough. The UE simply retunes between them, exactly as it would for an ordinary beam switch. That is why the TDM schemes are the ones you meet most often on real handsets. It is also why the reliability oriented variants of multi-TRP arrived first.

NOTE : The capability names above are Release 16. Release 17 added more, including multi-TRP PDCCH, PUCCH and PUSCH repetition, multi-TRP beam failure recovery and inter-cell multi-TRP. Those bring their own capability fields, which are not listed here.

Use Cases

CoMP technology plays a vital role in enhancing network performance across a variety of scenarios. In dense urban areas, where interference from neighboring cells is a major challenge, CoMP improves performance by effectively managing inter-cell interference, ensuring smoother and more reliable connectivity. For users at the cell edges, CoMP provides a significant boost in signal quality and overall experience, mitigating the poor coverage often encountered in such areas. Additionally, CoMP is crucial in industrial automation, where reliable and low-latency communication is essential for mission-critical applications in smart factories and industrial IoT environments. These diverse use cases highlight the versatility and importance of CoMP in addressing the unique demands of modern wireless networks.

• Dense Urban Areas:
• CoMP improves performance in high-interference environments.
• Cell Edge Users:
• Provides a better experience for users in areas of poor signal quality.
• Industrial Automation:
• Ensures reliable communication for mission-critical applications in smart factories and industrial IoT.

That list is the standard one, and it is correct as far as it goes. It is worth going one level deeper though, because in practice the question is rarely where CoMP would help. It is where the network allows it.

Where the ideal backhaul boundary actually falls

The table earlier on this page put a backhaul requirement against each scheme. That requirement is not really about cable quality. It is about how far apart the two points sit in the network, and there are three cases worth telling apart.

The left case is the one that surprises people. Two sectors of the same macro site, or a row of radio units in a building, are not two coordinating base stations at all. They are radio units hanging off one baseband, sharing one clock and one scheduler. Everything in the toolbox is available there, including joint transmission, and no inter-node interface is involved.

The middle case is the modern one, and it is where most deployments now sit. Splitting into a CU and DUs moves the boundary. Two DUs under one CU still coordinate, but over F1, at millisecond latencies. That is enough for scheduling and beam coordination. It is not enough to make two points behave as one radio.

The right case is what most of the early CoMP literature assumed, and it is the weakest of the three. Two independent gNBs over Xn can agree on who uses which resources, and little else.

NOTE : This is the honest answer to why CoMP was seen as disappointing for years. The gains were real, but they were measured for the left case and then hoped for in the right case.

Five deployments where it actually earns its place

The scenarios below follow the same shape each time : what the situation looks like physically, which scheme fits, and why the others do not.

1. A UE at the boundary between two sectors of one macro site

This is by far the most common real deployment, and it is almost invisible. A three sector site has a UE sitting where two sectors overlap, hearing both at similar strength. Classically this is where throughput collapses.

Both sectors are radio units on the same baseband, so this is the left case in the diagram. Dynamic point selection is the usual choice. The two sectors point in different directions, so joint transmission adds less than you might expect. Simply picking the better sector slot by slot removes most of the loss. To the UE this looks like nothing more than a TCI state change.

What makes it hard to spot is that there is no interface to trace. No Xn message is exchanged, because there is no second node. The coordination happens inside one scheduler.

2. An indoor venue with many small radio units

A stadium, an airport or a large office has dozens of small radio units, often all on one cell and one baseband. Users are dense and the units are close together, so interference between them is severe.

This is the case that most resembles the original CoMP vision, and it is where joint transmission genuinely works. All the units share a clock and a scheduler. So the timing and phase problems that make coherent transmission hard between sites simply do not arise.

Coordinated scheduling would be the wrong answer here. Keeping the units on separate resources would protect them from each other. It would also throw away most of the capacity, in a place built for capacity.

3. A mmWave street with people and vehicles in the way

Two TRPs cover a street from opposite ends, and a UE walks between them. Pedestrians, vans and the user's own body keep cutting one path or the other.

Here multi-TRP is not about throughput at all. It is about not losing the link. If the UE is already receiving from two directions, a blockage on one costs a repetition rather than an outage.

The scheme is usually TDM, either within a slot or across slots. The reason is the capability discussed in the previous section. Most handsets cannot receive two different QCL-TypeD sources at once, so the two TRPs have to take turns.

It is worth seeing how this relates to beam failure recovery. Recovery is what happens after the serving beam has already died. Multi-TRP is the preventive version of the same idea. One keeps a spare path warm, the other goes and finds a new one after the fact.

4. A factory floor with a latency budget

An automated vehicle or a robot arm needs a packet delivered within a millisecond, at very high reliability. The building around it is full of metal and moving machinery.

The latency budget is what decides the design. There is no room for a HARQ retransmission round trip, so the diversity has to be in the first transmission. Sending the same transport block from two TRPs at once does exactly that. If one path is shadowed by a passing machine, the other still arrives, and no retransmission was needed.

In configuration terms this is repetitionSchemeConfig-r16. One option is fdmSchemeB, with two redundancy versions side by side in frequency. The other is slot based repetition, with cyclicMapping across the two TCI states.

This scenario explains something about the specification itself. Multi-TRP in Release 16 was driven heavily by URLLC rather than by capacity. That is why the parameters live in something called RepetitionSchemeConfig, and why most of the schemes produce redundancy rather than extra layers.

5. High speed rail

TRPs are placed every few hundred metres along a track, and a train passes at 300 km/h or more. A UE crosses the coverage of each TRP in a couple of seconds.

Handing over at every TRP would be unworkable. So the TRPs are put into a single cell instead, and the UE moves between them by dynamic point selection. The cell identity never changes, so there is no handover signalling. What changes is the TCI state.

This is worth noticing as a general pattern. Multi-TRP can be used to make a group of transmission points look like one cell, which converts a mobility problem into a beam problem. Release 18 pushed the same idea further with L1 and L2 triggered mobility.

Putting the five together

Read down the last column and a pattern appears that the usual description of CoMP misses. Only two of the five are really about throughput. The other three are about reliability, link survival and mobility. That is a fair summary of what happened to the idea between LTE and NR. It started as a way to make the cell edge faster. It ended up mattering most as a way to make links harder to break.

Video Demo :

[1] 5G CoMP for Spectrum Sharing (Qualcomm)

[2] 5G NR Spectrum Sharing (Qualcomm)

[3] Coordinated Multipoint (CoMP) Transmission (FraunhoferHHIWN)

[4] Nokia TD-LTE-Advanced DL COMP demo (Nokia)