5G/NR

 

 

 

CLI and RIM

 

TDD looks simple when every cell in the network follows the same DL/UL pattern at the same time. All gNBs transmit in the DL symbols, all UEs transmit in the UL symbols, and a guard period between them absorbs the propagation delay. Release 16 deals with two situations where this assumption breaks. The first is when neighbouring cells use different TDD patterns, so one cell is in UL while the other is in DL. This creates CLI (Cross Link Interference). The second is when the DL signal of a gNB far away arrives so late that it falls into the UL symbols of another gNB. This is remote interference, and the mechanism against it is RIM (Remote Interference Management).

The two topics came together in the same Release 16 work, and they share the same root cause: a transmitter in one direction hitting a receiver in the other direction. But the tools are very different. CLI is handled with new UE measurements, SRS-RSRP and CLI-RSSI, configured over RRC. RIM is handled only between gNBs, with a special reference signal (RIM-RS) and backhaul messages, and the UE is not involved at all. CLI is also the groundwork for SBFD in Release 19, which is described in the SBFD page.

Why we need CLI and RIM ?

Why does TDD need a common DL/UL pattern in the first place ? Because a DL transmitter is much stronger than an UL transmitter. A gNB transmits with tens of watts from a high mast. A UE transmits with a fraction of a watt from someone's hand. If one cell is in DL while its neighbour is in UL, the strong DL signal can fall into a receiver that is trying to hear a weak UL signal. So in a classic TDD network, all cells in an area are synchronized and use the same pattern, and the guard period covers the propagation delay between them.

Then what is the problem ? There are two. The first one is a choice that operators want to make. A cell with mostly UL traffic, for example a stadium uploading video, would like more UL slots than its neighbours. That is dynamic or flexible TDD, and it means neighbouring cells are no longer aligned. The second one is not a choice at all. Under certain weather conditions, the atmosphere guides the radio signal over hundreds of kilometers. The signal from a gNB far away then arrives later than the guard period can absorb. Figure 1 shows the two cases side by side.

Cross Link Interference gNB A in DL slot gNB B in UL slot UE A UE B wanted DL wanted UL UE-to-UE CLI UE B UL hits UE A DL gNB-to-gNB CLI Remote Interference aggressor gNB, in DL victim gNB, in UL signal trapped in the atmospheric duct can travel hundreds of km far beyond normal range Same TDD pattern in both cells, but the delay is longer than the guard period

Figure 1. The two interference problems of Release 16. CLI comes from neighbouring cells that are in opposite directions at the same moment. Remote interference comes from cells that use the same pattern but are so far apart that the guard period is not long enough.

  • Left, CLI: gNB A is in a DL slot and gNB B is in an UL slot. UE B transmits UL to gNB B, and the nearby UE A receives that signal on top of its DL. This is UE-to-UE CLI. gNB A's DL also reaches gNB B's receiver, which is gNB-to-gNB CLI.
  • Right, remote interference: both gNBs follow the same pattern. But the aggressor's DL travels through the atmospheric duct and arrives at the victim so late that it overlaps the victim's UL symbols.
  • The victim is always a receiver in the other direction: a DL receiver (UE) hit by UL, or an UL receiver (gNB) hit by DL. This is why both cases are called cross link problems in a wide sense.
  • Different scale: CLI is local, between neighbouring cells. Remote interference involves cells that would normally never see each other.

Cross Link Interference

Let's start with CLI. In TS 38.300 clause 17.2 the definition is simple: when neighbouring cells use different TDD DL/UL patterns, UL transmission in one cell may interfere with DL reception in another cell. Release 16 does not try to remove this interference. It gives the network two tools so that it can see the interference and coordinate around it.

The first tool is coordination between gNBs. The gNBs can exchange their intended TDD DL-UL configurations over Xn, and between CU and DU over F1. With this information, a gNB knows in which symbols its neighbour plans to receive UL, and it can avoid scheduling strong DL near the cell edge in those symbols, or the other way around. The second tool is the UE measurement. The gNB can configure a victim UE to measure how much UL energy from other UEs it receives. This is the new part of Release 16, and most of this page is about it.

Why do we need the UE to measure it ? The gNB knows its own schedule and, with Xn, its neighbour's pattern. But it does not know which of its UEs are close to which UEs of the neighbour cell. UE-to-UE CLI depends on the distance between two UEs, and only the victim UE can sense it. So the victim UE becomes the sensor.

UE-to-UE CLI and gNB-to-gNB CLI

Figure 1 shows two CLI paths, and Release 16 treats them differently. It is easy to assume that the CLI measurement covers both of them, but it covers only one. The UE measures UE-to-UE CLI. Nothing in Release 16 measures gNB-to-gNB CLI over the air, and this gap is one of the things that Release 19 fills for SBFD.

  • UE-to-UE CLI: an aggressor UE in UL, a victim UE in DL. Measured by the victim UE with SRS-RSRP or CLI-RSSI, and reported with RRC measurement reports.
  • gNB-to-gNB CLI: an aggressor gNB in DL, a victim gNB in UL. In Release 16 this is handled by coordination of the intended TDD configurations over Xn and F1. Release 19 adds an explicit report of gNB-to-gNB CLI information between gNBs.
  • Aggressor SRS information comes from the neighbour: to measure SRS-RSRP, the victim UE needs the SRS configuration of the aggressor UE. The serving gNB can ask the neighbour gNB to report the SRS resources that may cause CLI, and then put them in the victim UE's configuration.

SRS-RSRP and CLI-RSSI

Release 16 defines two CLI quantities in TS 38.215. Why two ? Because they answer different questions. SRS-RSRP asks "how strong is this specific aggressor UE at my position ?". CLI-RSSI asks "how much total energy do I receive in these symbols, from anyone ?". The first one needs to know the aggressor's signal. The second one needs only a time and frequency window.

Both are defined only for RRC_CONNECTED and intra-frequency. For FR1 the reference point is the UE antenna connector. If the UE uses receiver diversity, the reported value shall not be lower than the value of any individual branch. This is the same rule as for SS-RSRP, so a CLI value can be compared with an RSRP value from the same UE. Figure 2 shows what each quantity measures on the resource grid.

SRS-RSRP CLI-RSSI one slot, symbols 0 to 13 SRS symbol power on the REs of one SRS resource of the aggressor UE, comb by comb victim UE must know srs-Resource of the aggressor configured window startPosition, nrofSymbols startPRB, nrofPRBs total received power in the window, from all sources including noise no knowledge of the aggressor needed PRB PRB

Figure 2. SRS-RSRP and CLI-RSSI. SRS-RSRP isolates one known aggressor. CLI-RSSI measures everything in a window, so it is simpler to configure but cannot tell who is interfering.

  • SRS-RSRP: the linear average of the power of the resource elements that carry SRS, over the configured bandwidth and the configured measurement occasions. The victim UE has to know the exact SRS resource of the aggressor UE: comb, position, sequence and periodicity.
  • CLI-RSSI: the linear average of the total received power in the configured OFDM symbols and the configured bandwidth, from all sources. This includes serving and non-serving cells, adjacent channel interference and thermal noise.
  • What each one is good for: SRS-RSRP tells the network which aggressor UE is the problem, so the network can schedule those two UEs apart. CLI-RSSI tells the network how much a set of symbols is polluted, for example the symbols where the neighbour has UL and this cell has DL.
  • Report ranges: SRS-RSRP is reported as an integer 0 to 98 (SRS-RSRP-Range-r16), and CLI-RSSI as an integer 0 to 76 (CLI-RSSI-Range-r16). The mapping to dBm is in TS 38.133 clause 10.1.22.

One more thing to notice is the timing. The aggressor UE transmits SRS with its own UL timing, which includes its timing advance toward its own gNB. The victim UE measures with its own DL timing. So the SRS does not arrive exactly at the symbol boundary that the victim expects. For SRS-RSRP this matters, because the UE tries to detect a known sequence. For CLI-RSSI it matters less, because the UE just integrates power over the window.

CLI Measurement Configuration

How does the gNB tell the UE what to measure ? CLI is configured inside the normal RRC measurement framework, with a new type of measurement object. This is a design choice worth noticing. CLI did not get a separate procedure. It reuses measConfig, measId, reportConfig and MeasurementReport, so the whole Release 16 CLI solution is L3 based.

The measurement object for CLI is MeasObjectCLI-r16, added as a new choice in MeasObjectToAddMod. It is different from an NR measurement object in one important way. An NR measurement object describes a frequency with SSBs or CSI-RS of cells. The CLI measurement object describes a list of SRS resources and a list of CLI-RSSI windows, with no cell in it at all.

Following is based on 38.331 v19.4.0 (Release 19)

MeasObjectCLI-r16 ::=                  SEQUENCE {
     cli-ResourceConfig-r16               CLI-ResourceConfig-r16,
    ...
}

CLI-ResourceConfig-r16 ::=          SEQUENCE {
    srs-ResourceConfig-r16              SetupRelease { SRS-ResourceListConfigCLI-r16 }                 OPTIONAL,   -- Need M
    rssi-ResourceConfig-r16             SetupRelease { RSSI-ResourceListConfigCLI-r16 }                OPTIONAL    -- Need M
}

SRS-ResourceListConfigCLI-r16 ::=   SEQUENCE (SIZE (1.. maxNrofCLI-SRS-Resources-r16)) OF SRS-ResourceConfigCLI-r16

RSSI-ResourceListConfigCLI-r16 ::=  SEQUENCE (SIZE (1.. maxNrofCLI-RSSI-Resources-r16)) OF RSSI-ResourceConfigCLI-r16

SRS-ResourceConfigCLI-r16 ::=       SEQUENCE {
    srs-Resource-r16                    SRS-Resource,
    srs-SCS-r16                         SubcarrierSpacing,
    refServCellIndex-r16                ServCellIndex                                                  OPTIONAL,   -- Need S
    refBWP-r16                          BWP-Id,
    ...
}

RSSI-ResourceConfigCLI-r16 ::=      SEQUENCE {
    rssi-ResourceId-r16                 RSSI-ResourceId-r16,
    rssi-SCS-r16                        SubcarrierSpacing,
    startPRB-r16                        INTEGER (0..2169),
    nrofPRBs-r16                        INTEGER (4..maxNrofPhysicalResourceBlocksPlus1),
    startPosition-r16                   INTEGER (0..13),
    nrofSymbols-r16                     INTEGER (1..14),
    rssi-PeriodicityAndOffset-r16       RSSI-PeriodicityAndOffset-r16,
    refServCellIndex-r16                ServCellIndex                                                  OPTIONAL,   -- Need S
    ...
}

RSSI-PeriodicityAndOffset-r16 ::=   CHOICE {
    sl10                                INTEGER(0..9),
    sl20                                INTEGER(0..19),
    sl40                                INTEGER(0..39),
    sl80                                INTEGER(0..79),
    sl160                               INTEGER(0..159),
    sl320                               INTEGER(0..319),
    s1640                               INTEGER(0..639),
    ...
}
  • srs-ResourceConfig-r16: up to 32 SRS resources to measure (maxNrofCLI-SRS-Resources-r16). Each entry is a full SRS-Resource, which is the same IE that configures an SRS for transmission. In other words, the gNB gives the victim UE a copy of the aggressor UE's SRS configuration.
  • srs-SCS-r16: the subcarrier spacing of the aggressor SRS. It can differ from the victim's DL numerology, because the aggressor is in another cell.
  • refBWP-r16 / refServCellIndex-r16: the DL BWP, and the serving cell it belongs to, used to derive the frequency reference point of the SRS resource. If refServCellIndex is absent, the reference is the PCell.
  • rssi-ResourceConfig-r16: up to 64 CLI-RSSI windows (maxNrofCLI-RSSI-Resources-r16). Each window has its own ID, which is what the UE reports later.
  • startPRB / nrofPRBs: the frequency part of the window. nrofPRBs is a multiple of 4. If it is wider than the active DL BWP, the UE assumes the window is inside the active DL BWP.
  • startPosition / nrofSymbols: the time part of the window inside a slot. The UE measures from startPosition to startPosition + nrofSymbols - 1. The window does not cross the slot boundary of the reference SCS.
  • rssi-PeriodicityAndOffset: the slot periodicity of the window, from 10 to 640 slots, with an offset in slots. Note the last choice is spelled s1640 in the ASN.1, not sl640.

The rssi-PeriodicityAndOffset is usually set to match the TDD pattern of the neighbour cell. If the neighbour has UL in slot 8 of every 10 slots, the gNB places a window there with sl10 and offset 8. The victim UE then measures exactly the slot where the conflict happens, and not a random part of the frame.

CLI Reporting

The UE now measures. Then when does it report, and what does the report contain ? CLI reporting has its own report types in ReportConfigNR: cli-Periodical-r16 and cli-EventTriggered-r16. They look like the normal periodic and event types, but the event is new. Event I1 means interference becomes higher than a threshold, and it is the only CLI event in Release 16.

Event I1 has a simple form. The entering condition is Mi - Hys > Thresh, and the leaving condition is Mi + Hys < Thresh, where Mi is the CLI result in dBm without any offset. Compare it with event A2, which triggers when the serving cell becomes worse than a threshold. I1 triggers when the interference becomes worse. There is no neighbour comparison like A3, because a CLI resource is not a cell.

Following is based on 38.331 v19.4.0 (Release 19)

CLI-PeriodicalReportConfig-r16 ::=          SEQUENCE {
    reportInterval-r16                          ReportInterval,
    reportAmount-r16                            ENUMERATED {r1, r2, r4, r8, r16, r32, r64, infinity},
    reportQuantityCLI-r16                       MeasReportQuantityCLI-r16,
    maxReportCLI-r16                            INTEGER (1..maxCLI-Report-r16),
    ...
}

CLI-EventTriggerConfig-r16 ::=              SEQUENCE {
    eventId-r16                                 CHOICE {
        eventI1-r16                                 SEQUENCE {
            i1-Threshold-r16                            MeasTriggerQuantityCLI-r16,
            reportOnLeave-r16                           BOOLEAN,
            hysteresis-r16                              Hysteresis,
            timeToTrigger-r16                           TimeToTrigger
        },
    ...
    },
    reportInterval-r16                          ReportInterval,
    reportAmount-r16                            ENUMERATED {r1, r2, r4, r8, r16, r32, r64, infinity},
    maxReportCLI-r16                            INTEGER (1..maxCLI-Report-r16),
    ...
}

MeasTriggerQuantityCLI-r16 ::=              CHOICE {
    srs-RSRP-r16                                SRS-RSRP-Range-r16,
    cli-RSSI-r16                                CLI-RSSI-Range-r16
}

MeasReportQuantityCLI-r16 ::=               ENUMERATED {srs-rsrp, cli-rssi}

FilterConfigCLI-r16 ::=             SEQUENCE {
    filterCoefficientSRS-RSRP-r16       FilterCoefficient                                       DEFAULT fc4,
    filterCoefficientCLI-RSSI-r16       FilterCoefficient                                       DEFAULT fc4
}

MeasResultCLI-r16 ::=            SEQUENCE {
    measResultListSRS-RSRP-r16       MeasResultListSRS-RSRP-r16                                                         OPTIONAL,
    measResultListCLI-RSSI-r16       MeasResultListCLI-RSSI-r16                                                         OPTIONAL
}

MeasResultListSRS-RSRP-r16 ::=   SEQUENCE (SIZE (1.. maxCLI-Report-r16)) OF MeasResultSRS-RSRP-r16

MeasResultSRS-RSRP-r16 ::=       SEQUENCE {
    srs-ResourceId-r16               SRS-ResourceId,
    srs-RSRP-Result-r16              SRS-RSRP-Range-r16
}

MeasResultListCLI-RSSI-r16 ::=   SEQUENCE (SIZE (1.. maxCLI-Report-r16)) OF MeasResultCLI-RSSI-r16

MeasResultCLI-RSSI-r16 ::=       SEQUENCE {
    rssi-ResourceId-r16              RSSI-ResourceId-r16,
    cli-RSSI-Result-r16              CLI-RSSI-Range-r16
}

SRS-RSRP-Range-r16 ::=                      INTEGER(0..98)

CLI-RSSI-Range-r16 ::=                      INTEGER(0..76)
  • reportQuantityCLI-r16: for periodic reporting, whether the UE reports SRS-RSRP or CLI-RSSI. For event reporting, the quantity follows the choice in i1-Threshold.
  • maxReportCLI-r16: how many resources the UE reports, up to 8 (maxCLI-Report-r16). The UE includes the most interfering resources first, in decreasing order of the L3 filtered result.
  • i1-Threshold-r16: the I1 threshold, given in the SRS-RSRP or CLI-RSSI range. The choice of the threshold type decides which quantity triggers the event.
  • FilterConfigCLI-r16: the L3 filter coefficients, carried as quantityConfigCLI-r16 in QuantityConfig. The default is fc4 for both quantities. For CLI-RSSI, whether the filter is reset at BWP switch is left to the UE.
  • MeasResultCLI-r16: carried as measResultCLI-r16 in MeasResults. Each entry is only a resource ID and a value. There is no cell ID, so the gNB must remember which aggressor UE or which neighbour pattern each resource ID stands for.

That last point is worth thinking about. The report carries "SRS resource 3 is at value 70". It does not carry "UE X in cell Y is interfering". The link between resource 3 and a real aggressor UE exists only in the gNB, which built the configuration from the neighbour's SRS information. So the measurement is only as useful as the coordination behind it. If the neighbour reconfigures its UE's SRS without telling, the victim UE keeps measuring an SRS that no longer exists.

UE capability for CLI

CLI measurement is optional for the UE. A network that plans to use flexible TDD has to check the capability before configuring MeasObjectCLI. The capability also limits how many resources the UE can handle, which is usually smaller than the ASN.1 maximum of 32 SRS resources and 64 CLI-RSSI resources.

  • cli-SRS-RSRP-Meas-r16 / cli-RSSI-Meas-r16: in MeasAndMobParametersFRX-Diff. Support of each measurement type, signalled separately for FR1 and FR2.
  • maxNumberCLI-SRS-RSRP-r16: in MeasAndMobParametersCommon, values n4, n8, n16, n32. The maximum number of SRS resources for SRS-RSRP.
  • maxNumberCLI-RSSI-r16: values n8, n16, n32, n64. The maximum number of CLI-RSSI resources.
  • maxNumberPerSlotCLI-SRS-RSRP-r16: values n2, n4, n8. How many SRS resources the UE can measure in one slot.

Remote Interference Management

Now the second problem. Remote interference comes from atmospheric ducting. Under some weather conditions, the air at higher altitude has a lower density and a lower refractive index than the air below. The radio signal bends back toward the Earth and travels in a layer, much farther than normal. A gNB that is 200 or 300 km away suddenly becomes visible. TD-LTE networks have known this problem for years, and Release 16 brings a solution for NR.

Why is a distant gNB a problem when its signal is weak after so many kilometers ? Because the victim gNB is listening for UL from UEs, which is also weak. And the aggressor is not one gNB. Ducting covers a whole region, so hundreds of aggressor gNBs can add up. The key point is the timing. In a synchronized TDD network, the DL of the aggressor arrives at the victim with a propagation delay. If that delay is longer than the guard period, the aggressor DL lands in the victim's UL symbols. Figure 3 shows this.

victim own pattern DL symbols GP UL symbols aggressor DL as received at the victim aggressor DL overlap propagation delay = distance / c first UL symbols of the victim are hit 300 km gives a delay of about 1 ms. At 30 kHz SCS that is about 28 OFDM symbols, so the overlap can be far longer than any practical guard period. The farther the aggressor, the more UL symbols are hit.

Figure 3. Why a distant gNB hits the UL. The aggressor follows the same pattern, but its DL arrives later by the propagation delay. Whatever part of the delay exceeds the guard period falls into the victim's UL symbols.

  • Same pattern, different arrival time: the aggressor ends its DL at the same absolute time as the victim. But the victim receives the end of that DL only after the propagation delay.
  • The guard period was designed for local distances: a few symbols of GP cover tens of kilometers. A duct of 300 km needs about 1 ms, which is two full slots at 30 kHz SCS.
  • The first UL symbols suffer most: the interference starts at the beginning of the UL period and covers more symbols as the distance grows. This is also a signature that helps to tell remote interference from other interference.
  • The UE is not involved: both the aggressor and the victim are gNBs. So RIM is solved between gNBs, without any RRC configuration to the UE.

To handle this in an organized way, TS 38.300 groups the gNBs into sets. Each cell gets a set ID, and is configured with a RIM-RS (RIM Reference Signal) and the radio resources for that set ID. A cell can have at most one victim set ID and one aggressor set ID, so one gNB can be a victim and an aggressor at the same time. That is natural, because ducting works in both directions.

RIM-RS

The RIM-RS is the only new physical signal of this feature. It is transmitted by a gNB, not by a UE, and it is received by other gNBs. TS 38.211 clause 7.4.1.6 defines it. The details are long, but there are a few points that explain how the whole RIM works, so it is worth going through them.

  • Two types: up to two RIM-RS types can be configured. The first type can convey information, and the second type depends on configuration only.
  • Set ID mapped to a resource: a RIM-RS resource is a triplet of a time index, a frequency index and a sequence index. The set ID determines this triplet, so a receiving gNB can tell which set transmitted the RIM-RS just from where and with which sequence it was detected.
  • Transmitted near the DL/UL switch: the RIM-RS is mapped relative to a configured reference point in the DL/UL switching period. A receiving gNB can therefore estimate how far away the transmitter is from how late the RIM-RS arrives.
  • Periodic, with a common time: the RIM-RS is sent periodically in units of DL/UL switching periods. The sequence changes with the number of transmission periods since 00:00:00 on 1 January 1900, traceable to a common time reference. So all gNBs need the same time base, which they have anyway for TDD synchronization.
  • Limited resources: at most 32 RIM-RS resources can be configured within a 10 ms period, and all RIM-RS resources occupy the same number of RBs.
  • Near-far functionality: optionally, the consecutive switching periods for a RIM-RS type are split into a near half and a far half. This lets the receiver separate close and distant transmitters.

Which gNB sends which type ? My understanding is that the first type is what the victim set sends, because it is the one that can carry information. The second type is then what the aggressor sends back in the wireless framework. I did not find this mapping stated directly in 38.211, so take it as my reading of the frameworks below.

RIM Frameworks

So the victim knows it suffers, and the RIM-RS gives a way to say so over the air. But the victim cannot fix the problem itself. Only the aggressor can, by changing its DL. Then how does the aggressor learn that it is the cause, and how does the victim learn when the problem is gone ? TS 38.300 defines two frameworks for this coordination: a wireless framework and a backhaul framework. In both, all gNBs in a victim set transmit the same RIM-RS with the victim set ID at the same time.

The difference is the way back from the aggressor to the victim. In the wireless framework, the aggressor answers over the air with its own RIM-RS. In the backhaul framework, the aggressor answers with a message through the core network. Figure 4 shows the backhaul framework, because that one has signalling you can see in an NGAP trace.

Victim gNB victim set AMF Aggressor gNB aggressor set 1. UL interference rises 2. RIM-RS with victim set ID, over the air, periodically 3. detect RIM-RS, apply RIM measures 4. UPLINK RIM INFORMATION TRANSFER rIM-RSDetection = rs-detected 5. DOWNLINK RIM INFORMATION TRANSFER AMF forwards it transparently ... ducting ends, the aggressor no longer detects the RIM-RS ... 6. UPLINK RIM INFORMATION TRANSFER rIM-RSDetection = rs-disappeared 7. DOWNLINK RIM INFORMATION TRANSFER 8. stop RIM-RS Wireless framework : steps 4 to 7 are replaced by a RIM-RS from the aggressor, over the air.

Figure 4. RIM backhaul framework. The victim set calls over the air, and each aggressor answers over the backhaul through the AMF. The victim stops its RIM-RS when the aggressors report that the RIM-RS has disappeared.

  • Steps 1 and 2: the victim detects rising UL interference, typically in the first UL symbols, and starts transmitting the RIM-RS of its victim set. All gNBs in the set send the same RIM-RS at the same time, so the signal adds up and reaches farther.
  • Step 3: an aggressor that detects the RIM-RS knows that a duct exists toward that victim set, because the duct works in both directions. It applies RIM measures. The specification leaves these measures to the implementation. Examples are fewer DL symbols before the guard period or lower DL power in those symbols.
  • Steps 4 and 5: the aggressor tells the victim that it detected the RIM-RS. The message goes through the AMF, and the AMF does not interpret it. TS 38.300 says the RIM backhaul signalling is transparent to the core network.
  • Steps 6 to 8: when the duct disappears, the aggressor no longer detects the RIM-RS and reports rs-disappeared. The victim then knows that the remote interference has ended and stops the RIM-RS.
  • Wireless framework: the aggressor answers with a RIM-RS carrying the aggressor set ID instead of a backhaul message. This RIM-RS also tells the victim whether ducting still exists. The victim decides that ducting has ended when it no longer receives any RIM-RS from aggressors.

The backhaul message itself is small. The UPLINK and DOWNLINK RIM INFORMATION TRANSFER messages of TS 38.413 clause 8.16 are non-UE associated, and they carry one IE, RIMInformationTransfer. Following is its definition. The IE names are from 38.413, and the spacing has been restored for readability.

Following is based on 38.413 v19.4.0 (Release 19)

RIMInformationTransfer ::= SEQUENCE {
    targetRANNodeID-RIM     TargetRANNodeID-RIM,
    sourceRANNodeID         SourceRANNodeID,
    rIMInformation          RIMInformation,
    iE-Extensions           ProtocolExtensionContainer { {RIMInformationTransfer-ExtIEs} }  OPTIONAL,
    ...
}

RIMInformation ::= SEQUENCE {
    targetgNBSetID          GNBSetID,
    rIM-RSDetection         ENUMERATED {rs-detected, rs-disappeared, ...},
    iE-Extensions           ProtocolExtensionContainer { {RIMInformation-ExtIEs} }  OPTIONAL,
    ...
}

TargetRANNodeID-RIM ::= SEQUENCE {
    globalRANNodeID         GlobalRANNodeID,
    selectedTAI             TAI,
    iE-Extensions           ProtocolExtensionContainer { {TargetRANNodeID-RIM-ExtIEs} }  OPTIONAL,
    ...
}

SourceRANNodeID ::= SEQUENCE {
    globalRANNodeID         GlobalRANNodeID,
    selectedTAI             TAI,
    iE-Extensions           ProtocolExtensionContainer { {SourceRANNodeID-ExtIEs} }  OPTIONAL,
    ...
}
  • targetRANNodeID-RIM: the victim gNB, as a global RAN node ID with a TAI. The AMF uses it to route the message.
  • targetgNBSetID: the victim set ID that the aggressor detected. The backhaul messages go from one aggressor gNB to one victim gNB, so an aggressor that detects a set sends one message to each victim gNB of that set.
  • rIM-RSDetection: the whole content of the message, rs-detected or rs-disappeared.

One thing I could not find in the text I read is how the aggressor turns a detected set ID into the list of victim gNB addresses. My guess is that OAM provides this mapping together with the set ID configuration, since the sets are semi-static anyway. But I don't want to say this is the specified method.

From CLI to SBFD

Why does a Release 16 feature matter for SBFD ? In SBFD, the gNB transmits DL and receives UL in the same symbol, in different subbands of the same carrier. So the opposite-direction situation of Figure 1 is no longer an exception between two cells. It happens all the time, even inside one cell. A DL UE can sit next to an UL UE of the same cell. This is intra-cell UE-to-UE CLI, and the SRS-RSRP and CLI-RSSI of Release 16 are the natural tools to measure it.

But the Release 16 tools were designed for slow coordination between cells. They are L3 measurements with L3 filtering and RRC reports, which take hundreds of milliseconds. SBFD scheduling decides per slot which UEs share a symbol. So TS 38.300 clause 17.2 in the latest release adds faster and wider tools on top of the Release 16 ones. They are listed below, and the SBFD side is described in Why is interference difficult ? on the SBFD page.

  • L1 CLI reporting: CLI results reported in CSI reports instead of RRC. For SRS-RSRP only aperiodic CSI reporting is supported. For CLI-RSSI, the reporting can be periodic or aperiodic. The resources are new IEs such as CLI-RSSI-MeasResource-r19, configured in the CSI framework.
  • L1 or L3, not both: a UE is not expected to be configured with L1 CLI measurement and reporting and L3 CLI measurement and reporting at the same time.
  • Intra-cell CLI: with SBFD, UE-to-UE CLI can be within the same cell, not only across cells.
  • gNB-to-gNB CLI information: a victim gNB can report gNB-to-gNB CLI related information of its cells to neighbour gNBs, which may then take mitigation actions. This covers the gap that Release 16 left open.
  • UL resource muting: a victim gNB can configure a UE so that, in a symbol with muting, only the even or the odd subcarriers of the PUSCH are used.

So the Release 16 CLI measurement is not an old feature replaced by SBFD. The L3 SRS-RSRP and CLI-RSSI, the measurement object with SRS and RSSI resources, and the idea of the victim UE as a sensor are all still there. Release 19 adds an L1 path next to them. For an interactive view of how the TDD patterns of two cells create CLI, see the TDD Cross-Link Interference web simulation.

Reference

  • 3GPP TS 38.300 V19.4.0 : NR; NR and NG-RAN Overall description; Stage-2. Clause 17.1 (Remote Interference Management), Clause 17.2 (Cross-Link Interference Management)
  • 3GPP TS 38.331 V19.4.0 : NR; Radio Resource Control (RRC) protocol specification. Clause 5.5.4.10 (Event I1), MeasObjectCLI, ReportConfigNR
  • 3GPP TS 38.215 V19.4.0 : NR; Physical layer measurements. Clause 5.1.19 (SRS-RSRP), Clause 5.1.20 (CLI-RSSI)
  • 3GPP TS 38.211 V19.5.0 : NR; Physical channels and modulation. Clause 7.4.1.6 (RIM reference signals)
  • 3GPP TS 38.413 V19.4.0 : NG-RAN; NG Application Protocol (NGAP). Clause 8.16 (RIM Information Transfer Procedures)
  • SBFD, Release 16 (ShareTechnote)