Model: mrhimanshu/finetuned-bge-m3
Author: mrhimanshu
Pipeline: sentence-similarity
Library: sentence-transformers
Tags: sentence-transformers, safetensors, xlm-roberta, sentence-similarity, feature-extraction, generated_from_trainer, dataset_size:18185, loss:MultipleNegativesRankingLoss, arxiv:1908.10084, arxiv:1705.00652, base_model:BAAI/bge-m3, base_model:finetune:BAAI/bge-m3, text-embeddings-inference, endpoints_compatible, region:us
Base models (finetune): id: BAAI/bge-m3
Card metadata: tags: sentence-transformers, sentence-similarity, feature-extraction, generated_from_trainer, dataset_size:18185, loss:MultipleNegativesRankingLoss
base_model: BAAI/bge-m3
widget: source_sentence: What are the parameters of a Tx-array-carrier?
sentences: ##‌Chapter 7‌‌

#MULT Commands

For more information about the MULT Commands see, the TM500 Command Reference Manual (CRM).
There are three variants of the MULT command:
•MULT
•MULT n
•MULT <ip address of ASC>
The first two are legacy versions that operate when there is no ASC in the system. The third version is the one that must be used if an ASC is deployed, even if the scenario is a single chassis deployment.
If either of the first two (legacy) versions of the MULT command are used with an ASC connected, the system will (most likely) fail and the error message generated is likely to be quite obscure.



##‌Chapter 8‌‌

#Diagnostics and Troubleshooting

This chapter is to assist the administrator with diagnostic tests and issues when configuring and operating the resources with groups and any associated configuration. For example, powering Groups UP and DOWN.
Checking clock ports/cablesTroubleshooting



##‌Checking clock ports/cables‌

Checking clock cables can be used as part of the setup and testing process, but only for ASC SRIO hardware. This is not applicable to ASC V2.
This is a special operating mode that allows the ASC to be used as a cable tester only. It cannot be used to validate that cabling connections from the ASC to connected resources are correctly installed.
To access the ASC Web Interface:
1. Log in to the ASC Web Interface.
2. Select the Test Groups page.
3. Check that no groups are active.
4. Check that at least two external switches are defined.
5. Check that the two external clock parts are assigned to different switches.
6. Set up the groups table with two groups. Each group must be assigned an external port.
7. Add three of the group members to each group.
8. If using seven members, add the Group Master to one of the groups.
9. Turn the groups power on, then activate the groups by locking the resources. This action can only be performed when the resources of the group have been locked.
10.Turn on the clocks for both groups.
Check the clock ports. One group should have flashing LEDs and the other group should have lit, but not flashing, LEDs.
11.Link the flashing clock input, using a clock cable, to test one of the lit (but not flashing) LEDs.
Note: This should include the other external clock input/output. After configuration, all the LEDs should be lit (but not flashing) LEDs.
•If the configuration fails, the clock input may be broken, or the clock cable faulty.
•If some of the configuration fails, the failed clock outputs may be broken.
12.Turn off the clock outputs on both groups.
13.Change over the group with the TM Group Master.
14.Turn the clocks back on for both groups.
15.Change over the group with the TM Group Master.
16.Turn the clocks back on for both groups.
This allows the clock input and output to be tested.



##‌Troubleshooting‌

If you see this symptom when using the MULT command, we recommend you try the solution in the following table:
For more information about the MULT command, see Chapter 2 Installing the ASC into a Test System on page 19.



##‌Appendix A‌‌

Sample Hardware Configurations
A single ASC can be used as part of a cabinet configuration, which comprises a series of TM501 (E500-C cabinet) or TM503 (E500-D cabinet) units, or it can be part of a benchtop configuration, which comprises a series of TM500 units.
E500-D Mk-4.1 cabinet ASC configurationBenchtop ASC configurationTM500-AS Benchtop SystemASC 5G Benchtop SystemExample system connection diagram using ASC V2



##‌E500-D Mk-4.1 cabinet ASC configuration‌

Figure 28 shows how an ASC would be connected to other components in a Mk-4.1 cabinet that contains two TM503 units, two HLP servers, and a 10 Gb Ethernet switch. Note that this configuration would also include both a PDU and RDA unit, but they are not shown in this diagram.
Controlling PC
E500-D MK-4.1 16U Cabinet
(supplied by customer)
10 GBE Switch
10 GBE Switch
10 GBE Switch
TM503 #1 (front sub-chassis)
TM503 #1 (front sub-chassis)
TM503 #1 (front sub-chassis)
TM503 #2 (rear sub-chassis)
TM503 #2 (rear sub-chassis)
TM503 #2 (rear sub-chassis)
1 2 3 4 5 6 7 8 9
1 2 3 4 5 6 7 8 9
1 2 3 4 5 6 7 8 9
1 2 3 4 5 6 7 8 9
1 2 3 4 5 6 7 8 9
1 2 3 4 5 6 7 8 9
ASC
ASC
ASC
HLP Server 2
HLP Server 2
HLP Server 2
HLP Server 1
HLP Server 1
HLP Server 1
Connected to the connection panel on top of the cabinet
The E500 and controlling PC can be local to each other
GbE 1 GbE 2
GbE 1 GbE 2
GbE 1 GbE 2
LNK
LNK
LNK
GbE 1 GbE 2 DBG
GbE 1 GbE 2 DBG
GbE 1 GbE 2 DBG
(for example, in the same room),
DBG
DBG
DBG
Clk
Clk
Clk
12 7
12 7
12 7
CUPM 6 AMC 1
CUPM 6 AMC 1
CUPM 6 AMC 1
Clk
Clk
Clk
12 7
12 7
12 7
CUPM 6 AMC 1
CUPM 6 AMC 1
CUPM 6 AMC 1
LNK
LNK
LNK
or remote (for example, in different buildings)
Logging Clock SRIO
Ethernet
Figure 28 : Example E500-D Mk-4.1 cabinet ASC configuration



##‌Benchtop ASC configuration‌

An example benchtop ASC configuration is shown below in Figure 29. The ASC multi-user benchtop TM500-C connection diagram shown in Figure 30 corresponds to this configuration.
The connections shown in this configuration diagram are for guidance only
For actual connections, refer to Figure 30
ASC
Input V~ USB
Logging Clock SRIO
Ethernet
USB Hub
USB Switch 1 to 6
TM500_1 to TM500_6
1GBE Switch
Controlling PC
Figure 29 : Example benchtop ASC configuration
Note: All front panel Ethernet connections
Optional Loopback
User Access Port
User Access Port
User Access Port
TM500 Boot 192.168.10.100/16
TM500 Boot 192.168.10.100/16
TM500 Boot 192.168.10.100/16
Cell1:E1
Cell1:E1
Cell1:E1
Cell2:E1 Cell3:E1
Cell4:E1 Cell5:E1 Cell6:E1
Cell2:E1 Cell3:E1
Cell4:E1 Cell5:E1 Cell6:E1
Cell2:E1 Cell3:E1
Cell4:E1 Cell5:E1 Cell6:E1
Cell1:E2
Cell1:E2
Cell1:E2
(VLAN 30-35T)
(VLAN 16-21T)
(VLAN 30-35T)
(VLAN 16-21T)
(VLAN 30-35T)
(VLAN 16-21T)
192.168.10.9/16
192.168.10.9/16
192.168.10.9/16
Figure 30 : ASC multi-user benchtop TM500-C connection diagram
Figure 30 : ASC multi-user benchtop TM500-C connection diagram
Figure 30 : ASC multi-user benchtop TM500-C connection diagram
d1000 VLAN – port mapping:
are RJ45, 10/100/1000Gbps (1000BASE-T)
unless otherwise stated
are RJ45, 10/100/1000Gbps (1000BASE-T)
unless otherwise stated
are RJ45, 10/100/1000Gbps (1000BASE-T)
unless otherwise stated
to EPC, 7 x 1Gbps (VLAN 16-21 + 30 untagged)
to EPC, 7 x 1Gbps (VLAN 16-21 + 30 untagged)
to EPC,, Dynamic M-plane mode: The .csv file only contains the base RU configuration advertised by the O-RU to the O-DU over the M-plane, which includes the following aspects:
•Static low-level Tx/Rx endpoints, Tx/Rx arrays
•Capability information:
o The content of the configuration, such as object labels and capabilities can be adapted to match the information expected by the O-DU.
o The user-plane configuration is then provided by the O-DU over the M-plane interface, and the configuration is manually activated by the O-DU as desired.
2. Static M-plane mode: The .csv file contains both the base RU configuration and user-plane configuration required to exchange CU-plane packets over O-RAN Fronthaul interface.
•The user-plane configuration includes the settings which normally would have been configured by the DU over the M-plane, such as:
o Tx/Rx endpoint, which contain the eaxcid and compression settings
o Tx/Rx Array carrier objects
•Processing element objects
In that mode of operation, there is no constraint on the object names. What matters is to define eCPRI stream profiles (eaxcid, VLAN, compression, and numerology) which match those configured in the O-DU.
Tx-array-carrier
Tx-array-carrier
Tx-array-carrier
Tx-Array
Tx-Array
Tx-Array
user-plane-configuration
user-plane-configuration
user-plane-configuration
•name - name
•absolute-frequency-center - nbr-row
•center-of-channel-bandwidth - nbr-columns
•channel-bandwidth - nbr-layers
•active (INACTIVE/SLEEP/ACTIVE) - element spacing
•state (DISABLED/BUSY/READY) - normal-vector-direction
•type (NR/LTE) - position
•duplex scheme - polarization
•band-number
Each instance is created by DU -max-gain .
All RO
•name - name
•absolute-frequency-center - nbr-row
•center-of-channel-bandwidth - nbr-columns
•channel-bandwidth - nbr-layers
•active (INACTIVE/SLEEP/ACTIVE) - element spacing
•state (DISABLED/BUSY/READY) - normal-vector-direction
•type (NR/LTE) - position
•duplex scheme - polarization
•band-number
Each instance is created by DU -max-gain .
All RO
•name - name
•absolute-frequency-center - nbr-row
•center-of-channel-bandwidth - nbr-columns
•channel-bandwidth - nbr-layers
•active (INACTIVE/SLEEP/ACTIVE) - element spacing
•state (DISABLED/BUSY/READY) - normal-vector-direction
•type (NR/LTE) - position
•duplex scheme - polarization
•band-number
Each instance is created by DU -max-gain .
All RO
endpoint-capacity-sharing-group
(all RO)
endpoint-capacity-sharing-group
(all RO)
endpoint-capacity-sharing-group
(all RO)
1 . n
1 . n
1 . n
1 . n
1 . n
1 . n
Low-level-tx-link
Low-level-tx-link
Low-level-tx-link
Low-level-tx-link
Low-level-tx-link
Low-level-tx-link
Low-level-tx-endpoint
Low-level-tx-endpoint
Low-level-tx-endpoint
Low-level-tx-endpoint
Low-level-tx-endpoint
Low-level-tx-endpoint
Static-low-level-tx-endpoint
Static-low-level-tx-endpoint
Static-low-level-tx-endpoint
Static-low-level-tx-endpoint
Static-low-level-tx-endpoint
Static-low-level-tx-endpoint
•name
•processing element
•tx-array-carrier
•low-level-tx-endpoint
•name
•processing element
•tx-array-carrier
•low-level-tx-endpoint
•name
•processing element
•tx-array-carrier
•low-level-tx-endpoint
•name
•name
•name
1- compression
•scs config (frame structure, CP, freq, scs, nbr of prb )
•offset-to-absolute-frequency-center
•e-axcid
1- compression
•scs config (frame structure, CP, freq, scs, nbr of prb )
•offset-to-absolute-frequency-center
•e-axcid
1- compression
•scs config (frame structure, CP, freq, scs, nbr of prb )
•offset-to-absolute-frequency-center
•e-axcid
1 . n
1 . n
1 . n
•name
•tx-arrays-name
•endpoint-type
•capacity-sharing-group
•name
•tx-arrays-name
•endpoint-type
•capacity-sharing-group
•name
•tx-arrays-name
•endpoint-type
•capacity-sharing-group
1 . n
1 . n
1 . n
max-control-sections-per-data-section
max-sections-per-symbol max-sections-per-slot max-beams-per-slot
max-prb-per-symbol
max-numerologies-per-symbol
max-endpoints
.
All RO
max-control-sections-per-data-section
max-sections-per-symbol max-sections-per-slot max-beams-per-slot
max-prb-per-symbol
max-numerologies-per-symbol
max-endpoints
.
All RO
max-control-sections-per-data-section
max-sections-per-symbol max-sections-per-slot max-beams-per-slot
max-prb-per-symbol
max-numerologies-per-symbol
max-endpoints
.
All RO
Each instance is created by DU
Each instance is created by DU
Each instance is created by DU
Each instance is created by DU
Each instance is created by DU
Each instance is created by DU
All RO
All RO
All RO
Relation
Relation
Relation
Low-level-rx-link
Low-level-rx-link
Low-level-rx-link
Low-level-rx-link
Low-level-rx-link
Low-level-rx-link
Low-level-rx-endpoint
Low-level-rx-endpoint
Low-level-rx-endpoint
Low-level-tx-endpoint
Low-level-tx-endpoint
Low-level-tx-endpoint
Static-low-level-rx-endpoint
Static-low-level-rx-endpoint
Static-low-level-rx-endpoint
Static-low-level-rx-endpoint
Static-low-level-rx-endpoint
Static-low-level-rx-endpoint
•name
•name
•name
tx-arrays rx-arrays
relation-type (shared/collocated)
All RO
tx-arrays rx-arrays
relation-type (shared/collocated)
All RO
tx-arrays rx-arrays
relation-type (shared/collocated)
All RO
•name
•processing element
•rx-array-carrier
•low-level-tx-endpoint
•name
•processing element
•rx-array-carrier
•low-level-tx-endpoint
•name
•processing element
•rx-array-carrier
•low-level-tx-endpoint
1 - compression
1 - compression
1 - compression
•scs config (frame structure, CP, freq,
scs, nbr of prb )
•offset-to-absolute-frequency-center
•e-axcid
•scs config (frame structure, CP, freq,
scs, nbr of prb )
•offset-to-absolute-frequency-center
•e-axcid
•scs config (frame structure, CP, freq,
scs, nbr of prb )
•offset-to-absolute-frequency-center
•e-axcid
1 - name
1 - name
1 - name
•rx-arrays-name
•endpoint-type
•capacity-sharing-group
•rx-arrays-name
•endpoint-type
•capacity-sharing-group
•rx-arrays-name
•endpoint-type
•capacity-sharing-group
endpoint-type (all RO)
endpoint-type (all RO)
endpoint-type (all RO)
Each instance is created by DU
Each instance is created by DU
Each instance is created by DU
All RO
All RO
All RO
Each instance is created by DU
Each instance is created by DU
Each instance is created by DU
1 . n
1 . n
1 . n
1 . n
1 . n
1 . n
Rx-array-carrier
Rx-array-carrier
Rx-array-carrier
Rx-array
Rx-array
Rx-array
supported-section-types
supported-frame-structures
managed-delay-support
max-numerology-change-duration max-control-sections-per-data-section max-sections-per-symbol
max-sections-per-slot
.
supported-section-types
supported-frame-structures
managed-delay-support
max-numerology-change-duration max-control-sections-per-data-section max-sections-per-symbol
max-sections-per-slot
.
supported-section-types
supported-frame-structures
managed-delay-support
max-numerology-change-duration max-control-sections-per-data-section max-sections-per-symbol
max-sections-per-slot
.
•name
•nbr-row
•nbr-columns
•nbr-layers
•element spacing
•normal-vector-direction
•position
•polarization
•band-number
•max-gain .
All RO
•name
•nbr-row
•nbr-columns
•nbr-layers
•element spacing
•normal-vector-direction
•position
•polarization
•band-number
•max-gain .
All RO
•name
•nbr-row
•nbr-columns
•nbr-layers
•element spacing
•normal-vector-direction
•position
•polarization
•band-number
•max-gain ., Confirm parameters

 Parameter name| Comment  
---|---  
RETURN_CODE| Number to indicate success/failure of request.See MCI return
codes.  
RETURN_TEXT| Text to indicate success/failure of request.


Examples:
The command with Context Group Type for ‘CA’ set to 0, and 2 Radio Contexts with Ids 0 and 1 in the ‘Radio Context List’ looks as below:
SRCG 0 CA 0 1
The command with Context Group Type for ‘MUMIMO’ set to 1, and 4 Radio Context with Ids 2, 3, 4 and 5 in the ‘Radio Context List’ looks as below:
SRCG 1 MUMIMO 2 3 4 5
The command with Context Group Type for ‘TOPOLOGY’ set to 3, and 2 Radio Context with Ids 8, and 9 in the ‘Radio Context List’ looks as below:
SRCG 3 TOPOLOGY 8 9


‌2.1.33 SASS‌‌
Set Conditional Assert state
Scope
This platform command is supported in all modes.
Description
This command sets the state for one or more groups of Conditional Asserts.
If a Conditional Assert is disabled and the condition fails, the following happens:
•A warning Error Notification indication will be issued on the MCI
•The TM500 will attempt to recover from the error condition – although the recovery is best efforts and may cause transient or sustained changes in behaviour
If a Conditional Assert is enabled and the condition fails, the behaviour is the same as if it were a critical assert.
All Conditional Asserts are disabled by default in formal releases and enabled by default in test releases
Syntax
SASS <STATE> <CASSERT SPECIFIER>
Request parameters

 Parameter name| Type| Allowed Values| Default  
---|---|---|---  
Min| Max  
STATE| Enum[String]| -| -| -  
ENABLE = Change the the state of the specified Conditional Assert(s) to be
enabledDISABLE = Change the the state of the specified Conditional Assert(s)
to be disabled  
CASSERT_SPECIFIER| String| -| -| -  
A single Conditional Assert group, or a glob-style expression of groups to
enable, e.g.:• DTE.GENERAL.INVALID_CONTEXT_DATAThis will enable or disable the
single Conditional Assert group• DTE.GENERAL.*This will enable or disable all
Conditional Asserts within the DTE.GENERAL submodule• DTE.*This will enable or
disable all Conditional Asserts within the DTE module• *This will enable or
disable all Conditional Asserts in the system


Confirm parameters

 Parameter name| Comment  
---|---  
RETURN_CODE| Number to indicate success/failure of request.See MCI return
codes.  
RETURN_TEXT| Text to indicate success/failure of request.


Example
Note that the effect of multiple SASS commands is cumulative. That is, if you want to enable all
C-assert, apart from CA.RADIOSEL.INVALID_REF_CLK, you can use the following two commands:
1. SASS ENABLE *
2. SASS DISABLE DTE.GENERAL.INVALID_CONTEXT_DATA
SASS ENABLE * C: SASS 0x00 Ok
SASS DISABLE DTE.GENERAL.INVALID_CONTEXT_DATA C: SASS 0x00 Ok
GASS
C: GASS 0x00 Ok
All conditional asserts are enabled except for:
DTE.GENERAL.INVALID_CONTEXT_DATA
If a disabled Conditional Assert fails, the ERNO emitted is of the form:
I: ERNO 0x00000000 CASS 0x00000008 <module>.<submodule.<group>: “<assert string>” at <location in code>
For example:
I: ERNO 0x00000000 CASS 0x00000008 DTE.GENERAL.INVALID_CONTEXT_DATA: "For
UeIndex: 1320,DeId: 1,Duplicate DL DefaultBearerId: 3 Detected " at line 5594 of
../cm_fw_app/dte/code/dte_pppoe.c


‌2.1.34 GASS‌‌
Get Conditional Assert state
Scope
This platform command is supported in all modes.
Description
This command queries the state of Conditional Asserts in the system.
Syntax
GASS
Request parameters
None
Confirm parameters

 Parameter name| Comment  
---|---  
RETURN_CODE| Number to indicate success/failure of request.See MCI return
codes.  
RETURN_TEXT| Text to indicate success/failure of request.  
CASSERT_STATUS_TEXT| Text Describing the state of Conditional Asserts in the
system


Example
GASS
C: GASS 0x00 Ok
All conditional asserts are enabled except for:
DTE.GENERAL.INVALID_CONTEXT_DATA


‌2.1.35 LCAP‌‌
Configures and enables the capturing and export of received and transmitted packet data logs.
Scope
This command is supported in all modes. This is currently supported for ORAN operation only.
Description
This command configures and enables the capturing and export of received and transmitted packet data logs as per the configuration parameters.
This command is available for use after the SCFG command has been used.
The command is designed to be flexible and extensible to address the current and future needs for such configuration.
Note: The captured log file is transferred to the ftp root folder on the controller PC.
Syntax
LCAP <PARAMETERS>
Request parameters

 Parameter name| Type| Allowed Values| Default  
---|---|---|---  
Min| Max  
COMMAND CLASS| String| -| -| -  
Class of command and defines the command and parameters are applicable to what
type of TM500 product.Options are:ORU  
CLASS IDENTIFIER| String| -| -| -  
If the COMMAND CLASS = "ORU", this parameter provides the RU name.  
TRAFFIC SOURCE| String| -| -| -  
Defines the type of traffic to be logged (conditional mandatory
parameter)Options are:TCP (S-plane and M-plane packets capture using tcpdump)
DPDK (CU plane packets capture using DPDK)NETCONF (M-plane Netconf logs)When
the command is issued after SCFG and this is not provided, DPDK option is used
by default.  
BUFFER SIZE| Int| -| -| -  
Configures the size of buffer (in megabytes) for log capture (conditional
mandatory parameter)10 means 10MB size is configured for the capture buffer
200 means 200MB size is configured for the capture buffer Minimum buffer size:
10MB (10)Maximum buffer size: 5000MB (5000)For TRAFFIC SOURCE = TCP and this
parameter is not provided, the system configures 10MB by defaultFor TRAFFIC
SOURCE = DPDK and this parameter is not provided, the system configures 200MB
by defaultFor TRAFFIC SOURCE = NETCONF, this parameter is not used and is
ignored if provided.Note: If this parameter is provided, the parameter
“TRAFFIC SOURCE” must be provided by the user.



 Parameter name| Type| Allowed Values| Default  
---|---|---|---  
Min| Max  
PORT IDENTIFIER| String| -| -| -  
If the COMMAND CLASS = "ORU", this parameter provides the port on which the
logging/capture to be enabled (conditional mandatory parameter)“ORU1-P1” –
configures the first ethernet port – for ORAN operation only“ORU1-P2” –
configures the second ethernet port – for ORAN operation onlyIf the COMMAND
CLASS = "ORU" and this is not provided, ORU1-P1 is used by defaultFor TRAFFIC
SOURCE = NETCONF, this parameter is not used and is ignored if provided.Note:
If this parameter is provided, the parameter “BUFFER SIZE” must be provided by
the user.  
FLOW IDENTIFIER| String| -| -| -  
Configures the specific flows for log capture (optional parameter) For COMMAND
CLASS = “ORU”:This is the list of eAXCIds provided as a string of comma
separated integer values for more than one flows. And a single value provided
as string with single integer value.If this is not provided, the system
captures the logs for all the flows associated with the configured ports on
the configured RU.For TRAFFIC SOURCE = NETCONF, this parameter is not used and
is ignored if provided.Note: If this parameter is provided, the parameter
“PORT IDENTIFIER” must be provided by the user.


Confirm parameters

 Parameter name| Comment  
---|---  
RETURN_CODE| Number to indicate success/failure of request.See MCI return
codes.  
RETURN_TEXT| Text to indicate success/failure of request.





##‌2.2 Error recovery and reset commands‌

The test mobile provides a number of different reset mechanisms that can be used to recover from various types of error. The error recovery commands are as follows:
•Hardware reboot – see RBOT
•Soft reset – see RSET
This command causes a soft reset and allows the mode to be changed using SCFG.



##‌2.3 SWL Commands‌

The Software License Component (SWL) is a component of the test mobile. MCI commands are provided to configure the license options of test mobile variants.
These commands can be used in any mode, but only after STRT is issued. The general syntax for these commands is:
FORW SWL COMMAND [PARAMETER1 PARAMETER2 … PARAMETERn]
2.3.1 GetStatus2.3.2 GetSystemID2.3.3 SetKey, source_sentence: How can the software use the radio card to evaluate the carrier leakage of the radio cards?
sentences: Parameter name| Type| Allowed Values| Default  
---|---|---|---  
Min| Max  
[>> Access Point Name]| String| 3| 100| No UE provided APN  
UE provided Access Point Name to be set in ESM Information Response during
Attach procedure.  
[>> PAP User Name]| String| 1| 18| No UE provided User Name  
UE provided PAP User Name for PAP Authentication Request to be set in ESM
Information Response during Attach procedure.  
[>> PAP Password]| String| 1| 18| No UE provided Password  
UE provided PAP Password for PAP Authentication Request to be set in ESM
Information Response during Attach procedure.  
[>> CHAP Authentication Selection Mode| Enum| 0| 1| CHAP not supported  
0 = CHAP Scripted Mode1 = Reserved.Note that PAP and CHAP are mutually
exclusive.  
>> Choice ‘CHAP Authentication Selection Mode’ is 0  
(>>> CHAP Challenge Value| String| 1| 60|  
UE provided Chap Challenge Value for CHAP Authentication Request to be set in
ESM Information Response during Attach procedure.The string contains a
hexadecimal number representing up to 30 octets (2 characters per byte).  
>>> CHAP Challenge Name| String| 1| 30|  
UE provided Chap Challenge Name for CHAP Authentication Request to be set in
ESM Information Response during Attach procedure  
>>> CHAP Response Value| String| 1| 60|  
UE provided Chap Response Value for CHAP Authentication Request to be set in
ESM Information Response during Attach procedure.The string contains a
hexadecimal number representing up to 30 octets (2 characters per byte).  
>>> CHAP Response Name)]| String| 1| 30|  
UE provided Chap Response Name for CHAP Authentication Request to be set in
ESM Information Response during Attach procedure



 Parameter name| Type| Allowed Values| Default  
---|---|---|---  
Min| Max  
[>> PCO Extension Request])| Int| 0| 0x23f| 0  
Bit 0 = P-CSCF IPv4 Address Request Bit 1 = IM CN Subsystem Signalling Flag
Bit 2 = P-CSCF IPv6 Address Request Bit 3 - Ipv4 Link MTU RequestBit 4 - NON
IP Link MTU RequestBit 5 - APN Rate Control. As defined in 10.5.6.3, this is
used for future enhancement of support of PCO not defined thus far. Sent
unciphered in the PDN Connectivity Request or sent ciphered using the ESM
information request procedure.Bit 6 - DNS Server IPv4 Address Request (NR
Only, not supported at present in LTE)Bit 7 - DNS Server IPv6 Address Request
(NR Only, not supported at present in LTE)Bit 8 - IP address allocation via
NAS signalling (NR Only, not supported at present in LTE)Bit 9 - MSISDN
Request  
Choice 'Selection Mode' is 1 (Manual Selection)Perform PLMN selection with the
given PLMN. If no PLMN is given then PLMN selection is performed with USIM
PLMN if available. If PLMN selection fails then the UE performs a scan and
returns the list of available PLMNs.  
(PDN Identity| Int| 0| 7| 0  
Pdn Id for default EPS Bearer is always 0.  
[PDN Type]| Enum| 0| 5| 0  
0 = IPv41 = IPv62 = IPv4v6 (both)The following option is only available for
NB-IoT. 4 = NonIPThe following option is only available for NB-IoT and CAT-M.5
= No PDN  
[PLMN]| String| 5 digits| 6 digits|  
PLMN to use.PLMN is provided in a string of 5 or 6 decimal digits.The leading
3 digits provide the Mobile Country Code (MCC).The next 2 or 3 digits
(depending on 'MNC length') provide the Mobile Network Code (MNC).



 Parameter name| Type| Allowed Values| Default  
---|---|---|---  
Min| Max  
[DNS Server IPv4 Address Request]| Enum| 0| 1| 0  
0 = DNS Server IPv4 Address Request Protocol Configuration Option not sent1 =
DNS Server IPv4 Address Request PCO sent  
[IPv4 Address Allocation via DHCP])| Enum| 0| 1| 0  
0 = IPv4 address allocation via DHCPv4 Protocol Configuration Option not sent1
= IPv4 address allocation via DHCPv4 PCO sentWhen the network allocates an
IPv4 address the DHCPv4 ADDRESS ALLOCATION IND is output.  
Choice 'Selection Mode' is 2 (Manual Scan)Scans and returns a list of
available PLMNs for manual selection.


Confirm parameters

 Parameter name| Comment  
---|---  
RETURN_CODE| Number to indicate success/failure of request.See MCI return
codes.  
RETURN_TEXT| Text to indicate success/failure of request.




‌3.13.2 NasConfigEmmDeregister‌‌
Deregister the NAS from network
Scope
Activation time is controlled by the Activate command.
Description
This command requests NAS to deregister from the network.
The activation indication is returned when the deregistration process has completed.
The results of the NAS deregistration are provided in a separate indication message, which is also used for network initiated deregistration.
Syntax
FORW MTE NASCONFIGEMMDEREGISTER <PARAMETERS>
Request parameters

 Parameter name| Type| Allowed Values| Default  
---|---|---|---  
Min| Max  
Deregister cause| Enum| 0| 2|  
0 = Normal1 = Switch off2 = Silent switch off. Cause the UE to deregister with
no signaling to emulate loss of power.


Confirm parameters

 Parameter name| Comment  
---|---  
RETURN_CODE| Number to indicate success/failure of request.See MCI return
codes.  
RETURN_TEXT| Text to indicate success/failure of request.




‌3.13.3 NasAptConfigPlmnSelection‌‌
Configure NAS to select a specific PLMN
Scope
Activation time is controlled by the Activate command.
Description
APT command to configure the NAS to select a specific PLMN during registration. This applies to both a real or simulated USIM.
Syntax
FORW MTE NASAPTCONFIGPLMNSELECTION <PARAMETERS>
Request parameters

 Parameter name| Type| Allowed Values| Default  
---|---|---|---  
Min| Max  
Force PLMN| String| 5 digits| 6 digits|  
Force use of a particular PLMN. Initial registration is attempted to the
specified PLMN.PLMN is provided in a string of five or six decimal digits.The
leading three digits provide the Mobile Country Code (MCC).The next two or
three digits (depending on 'MNC length') provide the Mobile Network Code
(MNC).  
[> Radio Access Type]| Enum[Int]| 0| 4| 3  
Radio Access TypeValues 0, 1 and 2 are reserved for future use.3 = NG-RAN4 =
SATELLITE NG-RANNote: This parameter is not used for LTE (4G).


Confirm parameters

 Parameter name| Comment  
---|---  
RETURN_CODE| Number to indicate success/failure of request.See MCI return
codes.  
RETURN_TEXT| Text to indicate success/failure of request.




‌3.13.4 NasAptConfigCapability‌‌
Configure NAS capabilities, including authentication and security options
Scope
Activation time is controlled by the Activate command.
Description
APT command to configure the NAS capabilities and the ciphering/integrity algorithms supported as reported to the network.
If the command is not issued then the 3GPP defaults apply.
Syntax
FORW MTE NASAPTCONFIGCAPABILITY <PARAMETERS>
Request parameters

 Parameter name| Type| Allowed Values| Default  
---|---|---|---  
Min| Max  
[| Enum| 0| 4| 3  
> NAS Security options]| 0 = No Authentication procedure and no NAS security
> mode procedure is expected. Any received authentication request or security
> mode command is ignored.  
| 1 = No NAS security mode procedure is expected. Any received security mode
command is ignored. Authentication procedure is expected.  
| 2 = NAS security mode is expected but message contents are ignored. Security
mode procedure completes but no NAS ciphering or integrity is started.
Authentication procedure is expected. NAS security headers are not used.  
| 3 = NAS security mode is expected and UE acts on contents starting NAS
integrity and ciphering if configured. Authentication procedure is expected.
NAS security headers are used.  
| This is 3GPP defined behavior and is the default if the command is not used.  
| 4 = NAS security mode is expected. Authentication procedure is not expected., Confirm parameters

 Parameter name| Comment  
---|---  
RETURN_CODE| Number to indicate success/failure of request.See MCI return
codes.  
RETURN_TEXT| Text to indicate success/failure of request.




‌5.2.9 Msg4BypassContentionResolution‌‌
Configures RACH Message 4 Contention Resolution Bypass
Scope
E500 supported.
This command can be used any time. The effects of this command are immediate. The command can be used in all modes.
The command only applies to the current Radio Context (set via SetRadioContext) and applies to all UEs in the Radio Context.
Description
This command was provided for use when TM500 was not 3GPP compliant regarding the HARQ result transmitted on receipt of RACH Message 4 (containing the RRCConnectionSetup message).
The 3GPP compliant behavior, now supported by default, is for a DTX to be sent if:
•UE contention resolution fails or
•A CRC error occurs while performing UE contention resolution.
The previous default behavior of the TM500 was to always send a DTX as the HARQ result for this message. The TM500 appeared to failed UE contention resolution, even if the contention resolution was successful and the RRCConnectionSetup message was passed to higher layers.
This test command was provided to bypass the UE contention resolution HARQ behavior to configure the required behavior pending resolution of this issue.
As the TM500 is now 3GPP compliant, with regard to this issue, the recommendation is that this command should not be used and is deprecated in a future release.
Syntax
FORW L1 MSG4BYPASSCONTENTIONRESOLUTION <PARAMETERS>
Request parameters

 Parameter name| Type| Allowed Values| Default  
---|---|---|---  
Min| Max  
Bypass contention resolution| Enum| 0| 2| 1  
0 = MSG4 HARQ result is always DTX.1 = 3GPP compliant.2 = MSG4 HARQ result is
always the DL-SCH CRC result. DTX does not apply if contention resolution
fails.


Confirm parameters

 Parameter name| Comment  
---|---  
RETURN_CODE| Number to indicate success/failure of request.See MCI return
codes.  
RETURN_TEXT| Text to indicate success/failure of request.




‌5.2.10 MacTriggerSCell‌
Trigger SCell Activation
Scope
Applicable to all modes except HARQ mode. The effects of this command are immediate.
Description
This L2 test command is used to manually trigger activation/deactivation of SCCs.
Syntax
FORW L2 MACTRIGGERSCELL <PARAMETERS>
Request parameters

 Parameter name| Type| Allowed Values| Default  
---|---|---|---  
Min| Max  
UE id| Int| 0| 31|  
SCC Control| Int| 0| 127|  
A bit field controlling the activation/deactivation of SCCs 1-6.Bit 0:1 = SCC1
active Bit 1:1 = SCC2 active Bit 2:1 = SCC3 active Bit 3:1 = SCC4 activeBit
4:1 = SCC5 active (applicable for R13) Bit 5:1 = SCC6 active (applicable for
R13) Bit 6:1 = SCC7 active (applicable for R13)  
Subframe (Optional)| Int| 0| 9| Immediate  
The subframe to apply the SCC control.If omitted, it applies immediately.


Confirm parameters

 Parameter name| Comment  
---|---  
RETURN_CODE| Number to indicate success/failure of request.See MCI return
codes.  
RETURN_TEXT| Text to indicate success/failure of request.




‌5.2.11 SetPortMapping‌
Configures the Port Mapping Information
Scope
This command must be issued before cell search. The effects of this command are immediate. The command can be used in all modes.
Description
This command is used to control the port mapping feature.
The FORW L1 SETRADIOCONTEXT command is used to enable a per cell setting to be defined.
Syntax
FORW L1 SETPORTMAPPING <PARAMETERS>
Request parameters

 Parameter name| Type| Allowed Values| Default  
---|---|---|---  
Min| Max  
Port mapping mode| Enum| 0| 2| 0  
0 = port mapping disabled1 = port mapping automatically2 = port mapping
manually  
Port mapping options - only required if 'Port mapping mode' is 2, otherwise
omit completely.  
Switch cell search port| Enum| 0| 1| 0  
0 = NO, PSS and SSS is on RX_0. cell search is only on RX_01 = YES, PSS and
SSS is on RX_1. cell search is only on RX_1  
Switch FFT receiving port| Enum| 0| 1| 0  
0 = NO, TX port 0 is on RX_0, TX port 1 is on RX_1, transmission port match
with receiving antenna, downlink signal processing can directly use the
receiving FFT data.1 = YES, TX port 0 is on RX_1, TX port 1 is on RX_0,
transmission port is not match with receiving antenna, downlink signal
processing should switch the receiving FFT data.


Confirm parameters

 Parameter name| Comment  
---|---  
RETURN_CODE| Number to indicate success/failure of request.See MCI return
codes.  
RETURN_TEXT| Text to indicate success/failure of request.




‌5.2.12 UlPowerCappingMode‌‌
Configures the UL Power Capping
Scope
E500 supported.
The effects of this command are immediate. The command can be used in all modes.
Description
This command is used to control UE power capping. When enabled the following is performed:
•“Power class capping” occurs before adding “Poffset”.
•An additional capping (only on the upper range, for example limit to max +13dBm per UE by default) is carried out to avoid Ptx go beyond the 23dBm in case of misconfiguarations, and to avoid electrical issues for the attached device (eNB or other).
•The lower power limitation (set at -50dBm) is removed.
The setting applies to all UEs in the radio context/cell last selected using FORW L1 SETRADIOCONTEXT to configure for multiple cells.
Correct setting of the UL power requires UL power capping to be enabled and this is now the default setting.
Syntax
FORW L1 ULPOWERCAPPINGMODE <PARAMETERS>
Request parameters

 Parameter name| Type| Allowed Values| Default  
---|---|---|---  
Min| Max  
Power capping on/off| Enum| 0| 1| 1  
0 = Power capping disabled1 = Power capping enabled  
UE power allowance| Int| 0| 23| 13  
UE power allowance in dBm.The value to cap the UE specific UL channel
transmission power.


Confirm parameters

 Parameter name| Comment  
---|---  
RETURN_CODE| Number to indicate success/failure of request.See MCI return
codes.  
RETURN_TEXT| Text to indicate success/failure of request.




‌5.2.13 SetDlFftBitShift‌
Scope
This command is only applicable in Standalone NB-IOT mode. The effects of this command are immediate.
Description
It controls the bit shift used at the output of the FFT in the FPGA in the radio.
Syntax
FORW L1 SetDlFftBitShift <PARAMETERS>
Request parameters

 Parameter name| Type| Allowed Values| Default|  
---|---|---|---|---  
Min| Max|  
mode| Boolean| 0| 1| 0|  
0 = Automatic1 = Manual|  
The following two parameters are required only if the Manual mode is selected|  
bitShiftSettingMode| Enum| 0| 2| 0|  
1 = Absolute value2 = Adjust current valueFor absolute value: Set FFT shiftFor
adjust: Adjust the current FFT shift|  
value| Int| -16| 16|  
This indicates by how many bits DL FFT shift operation is adjusted|


Confirm parameters

 Parameter name| Comment  
---|---  
RETURN_CODE| Number to indicate success/failure of request.See MCI return
codes.  
RETURN_TEXT| Text to indicate success/failure of request.




‌5.2.14 EnableRealPMIMeasurement‌
Scope
This command can be used any time. The effects of this command are immediate.
Description
This special command can be used to enable or disable the real PMI measurement for a given Radio Context which can be set by SetRadioContext command after issuing this command.
All the beams in the MU-MIMO will have the same kind of PMI reporting behaviour whether real or simulated PMI. Also all UEs in a beam will report the same PMI when real PMI is enabled.
Syntax
FORW L1 ENABLEREALPMIMEASUREMENT <Parameter
Request parameters

 Parameter name| Type| Allowed Values| Default  
---|---|---|---  
Min| Max  
EnableFlag| Boolean| 0| 1| 0  
0 = Real PMI reporting disabled1 = Real PMI reporting enabledNote: You can
enable/disable the real PMI measurement for the given radio Context.


Confirm parameters

 Parameter name| Comment  
---|---  
RETURN_CODE| Number to indicate success/failure of request.See MCI return
codes.  
RETURN_TEXT| Text to indicate success/failure of request., ##‌Table 1 - Carrier leakage performance as tested in 36.521-1 and effect on one RB adjacent to the centre frequency

TM500 scenario
The section Real world scenario on page 47 showed that, in a real world scenario involving standard compliant UEs, the carrier leakage interference will affect the uplink throughput performance. When it comes to using TM500, the effect of the carrier leakage of the radio cards also needs to be evaluated. This requires explaining i) how the carrier leakage is specified and measured and ii) how the software uses the radio card.
When it comes to how carrier leak is specified and measured, for the TM500 MBR, C-MBR and C-MBR 600 radio cards this is done when transmitting a -10.7 dBFS digital signal at maximum calibrated analog gain, producing +16 dBm wanted signal output power in dedicated mode (0 dBm in combined mode when the gain is limited to avoid self-interference). In those circumstances, the carrier leak level is ≤-40 dBc, which is equivalent to:
•≤-50.7 dBFS digital power.
•≤-24 dBm and ≤-40 dBm absolute output power in dedicated and combined mode, respectively.
As for how the radio card is used during normal operation, the current version of the MUE test software configures the transmitter at maximum analog gain, which results in the values of absolute carrier leak power provided above. Any uplink level changes required by the eNB under test are implemented by increasing or reducing the level of the digital baseband. This means that the relative carrier leak and therefore the uplink C/I depend on the setup attenuation, artificial noise level setting and eNB receiver target power or SNR.
In MUE, the crest factor of the signal is 3 dB higher and for fading an additional back-off of 7 dB is needed. I.e. there is ≈10 dB extra back-off compared with the calibration scenario. This corresponds to a maximum digital drive level of -20.7 dBFS. Table 2 and Table 3 provide the relative carrier leakage that can be achieve depending on the baseband drive level for 10 MHz and 20 MHz channel bandwidth, respectively. The calculation is obtained for i) full allocation and ii) the number of RBs allocated to one UE for carrier leak testing in 36.521-1.

 Baseband drive level| Output power| Carrier leakage  
---|---|---  
Full allocation (dBFS)| Per RB (dBFS/RB)| Full allocation (dBm)| Per RB
(dBm/RB)| dBFS| Full allocation (dBc)| 12 RB allocation (dBc)  
-21| -41| +6| -14| ≤-51| ≤-30| ≤-24.2  
-22| -42| +5| -15| ≤-51| ≤-29| ≤-23.2  
-23| -43| +4| -16| ≤-51| ≤-28| ≤-22.2  
-24| -44| +3| -17| ≤-51| ≤-27| ≤-21.2  
-25| -45| +2| -18| ≤-51| ≤-26| ≤-20.2  
-26| -46| +1| -19| ≤-51| ≤-25| ≤-19.2  
-27| -47| 0| -20| ≤-51| ≤-24| ≤-18.2  
-28| -48| -1| -21| ≤-51| ≤-23| ≤-17.2  
-29| -49| -2| -22| ≤-51| ≤-22| ≤-16.2  
-30| -50| -3| -23| ≤-51| ≤-21| ≤-15.2  
-31| -51| -4| -24| ≤-51| ≤-20| ≤-14.2  
-41| -61| -14| -34| ≤-51| ≤-10| ≤-4.2



##‌Table 2 - Relationship between baseband drive level and relative carrier leakage. 10 MHz channel bandwidth (50 RBs)


 Baseband drive level| Output power| Carrier leakage  
---|---|---  
Full allocation (dBFS)| Per RB (dBFS/RB)| Full allocation (dBm)| Per RB
(dBm/RB)| dBFS| Full allocation (dBc)| 18 RB allocation (dBc)  
-21| -41| +6| -14| ≤-51| ≤-30| ≤-23  
-22| -42| +5| -15| ≤-51| ≤-29| ≤-22  
-23| -43| +4| -16| ≤-51| ≤-28| ≤-21  
-24| -44| +3| -17| ≤-51| ≤-27| ≤-20  
-25| -45| +2| -18| ≤-51| ≤-26| ≤-19  
-26| -46| +1| -19| ≤-51| ≤-25| ≤-18  
-27| -47| 0| -20| ≤-51| ≤-24| ≤-17  
-28| -48| -1| -21| ≤-51| ≤-23| ≤-16  
-29| -49| -2| -22| ≤-51| ≤-22| ≤-15  
-30| -50| -3| -23| ≤-51| ≤-21| ≤-14  
-31| -51| -4| -24| ≤-51| ≤-20| ≤-13  
-41| -61| -14| -34| ≤-51| ≤-10| ≤-3



##‌Table 3 - Relationship between baseband drive level and relative carrier leakage. 20 MHz channel bandwidth (100 RBs)

Table 2 and Table 3 show that if the setup loss is too low, therefore forcing the baseband drive level down, then the relative carrier leak performance is poor resulting in degraded C/I performance. On the other hand, maximizing the baseband drive level by either increasing the setup loss, the level of artificial noise or both gives the best results.
© 2022, VIAVI Solutions Inc.
For further information please contact:
VIAVI Solutions www.viavisolutions.com/wirelessvalidation
< Previous | Contents, source_sentence: What is the effect of MPDCCH StartSF CSS RA on M-PDCCH common search space?
sentences: Confirm parameters

 Parameter name| Comment  
---|---  
RETURN_CODE| Number to indicate success/failure of request.See MCI return
codes.  
RETURN_TEXT| Text to indicate success/failure of request.




‌3.5.38 PhyConfigPrachCommonBR‌‌
Configure PRACH physical channel for bandwidth reduced operation
Scope
Activation time is controlled by the Activate command.
The command applies to the selected Cell using the SetUEContext command for the cell common UE designated using the optional ‘Cell Id’ and ‘Downlink carrier frequency’ parameters.
Description
Configure PRACH physical channel parameters for bandwidth reduced operation.
Syntax
FORW MTE PHYCONFIGPRACHCOMMONBR <PARAMETERS>
Request parameters

 Parameter name| Type| Allowed Values| Default  
---|---|---|---  
Min| Max  
Root Sequence Index| Int| 0| 837|  
The range 0..837 is supported for Preamble formats 0..3.For TDD the range
0..137 is supported for Preamble format 4.The parameter is an input for the
preamble sequence generation named as RACH_ROOT_SEQUENCE, see TS 36.211
section 5.7.2.  
High Speed Flag| Bool| 0| 1|  
0 = Normal (unrestricted preamble set)1 = High Speed (restricted preamble
set)The parameter is an input in the calculation of cyclic shift, see TS
36.211 section 5.7.2.  
Zero Correlation Zone Config| Int| 0| 15|  
The parameter (NCS configuration) is an input in the calculation of cyclic
shift, see TS 36.211 section 5.7.2.:• table 5.7.2-2 for preamble format 0..3•
table 5.7.2-3 for preamble format 4  
Number of RSRP Threshold Items| Int| 1| 3|  
The size of the RSRP Threshold PRACH Information List.The criterion for BL UEs
and UEs in CE to select PRACH resource set. Up to 3 RSRP threshold values are
signalled to determine the CE level for PRACH. See TS 36.213 and TS 36.321.  
For each Item in the RSRP Threshold PRACH Information List



 Parameter name| Type| Allowed Values| Default  
---|---|---|---  
Min| Max  
{> RSRP Threshold PRACH}| Int| 0| 97|  
Reference Signal Received Power threshold for PRACH. The reporting range of
RSRP is defined from -140 dBm to -44 dBm with 1 dB resolution, see TS 36.133.  
Number of PRACH Parameters CE Items| Int| 1| 4|  
The size of the PRACH Parameters List.Configures PRACH parameters for each CE
level. The first entry in the list is the PRACH parameters of CE level 0, the
second entry in the list is the PRACH parameters of CE level 1, and so on.  
For each Item in the PRACH Parameters CE List  
{> PRACH Configuration Index| Int| 0| 63|  
The PRACH Configuration Index is an input to calculating the random access
resource:• table 5.7.1-1 for frame structure type 1 preamble format 0..3•
table 5.7.1-2 for frame structure type 2 preamble format 4Full details of
preamble time and frequency resource selection are given in TS 36.211 section
5.7.1.  
> PRACH Frequency Offset| Int| 0| 94|  
The PRACH frequency offset n RA is an input to calculating thePRBoffsetrandom
access resource for each CE, see TS 36.211 section 5.7.1.For TDD the value
range is dependent on the value of prach-ConfigIndex.  
> Num Repetition Per Preamble Attempt| Enum| 0| 7|  
0 = n11 = n22 = n43 = n84 = n165 = n326 = n647 = n128Number of PRACH
repetitions per attempt, See TS 36.211.  
> Number of MPDCCH Narrowbands To Monitor| Int| 1| 4|  
The size of the MPDCCH Narrowbands To Monitor List.  
> For each Item in the MPDCCH Narrowbands To Monitor List



 Parameter name| Type| Allowed Values| Default  
---|---|---|---  
Min| Max  
{>> Narrowband}| Int| 1| 16|  
This field indicates the index of the narrowband to monitor for MPDCCH.  
> MPDCCH Num Repetition RA| Enum| 0| 8|  
0 = r11 = r22 = r43 = r84 = r165 = r326 = r647 = r1288 = r256Maximum number of
repetitions for M-PDCCH common search space (CSS) for RAR, Msg3 and Msg4, see
TS 36.211.  
> PRACH Hopping Config| Enum| 0| 1|  
0 = On1 = OffCoverage level specific frequency hopping configuration for
PRACH.  
[>> PRACH Starting Subframe]| Enum| 0| 7|  
0 = sf21 = sf42 = sf83 = sf164 = sf325 = sf646 = sf1287 = sf256PRACH starting
subframe periodicity, expressed in number of slots available for preamble
transmission (PRACH opportunities), see TS36.211. Value sf2 corresponds to 2
subframes, sf4 corresponds to 4 subframes and so on. EUTRAN configures the
PRACH starting subframe periodicity larger than or equal to the Number of
PRACH repetitions per attempt for each CE level
(numRepetitionPerPreambleAttempt).



 Parameter name| Type| Allowed Values| Default  
---|---|---|---  
Min| Max  
[>> Max Num Preamble Attempt CE]}| Enum| 0| 6|  
0 = n31 = n42 = n53 = n64 = n75 = n86 = n10Maximum number of preamble
transmission attempts per CE level. See TS 36.321.  
[> MPDCCH StartSF CSS RA]| Enum| 0| 7|  
This parameter indicates the starting subframe configuration for M-PDCCH
common search space (CSS), including RAR, Msg3retransmission, PDSCH with
contention resolution and PDSCH with RRCConnectionSetup. see TS 36.211 and TS
36.213. Value v1 corresponds to 1, value v1dot5 corresponds to 1.5, and so on.  
[> PRACH Hopping Offset]| Int| 0| 94|  
f PRACHThe PRACH Hopping offset PRB,hop is an input to calculating the
randomaccess resource, see TS 36.211 section 5.7.1.



 Enum Value| FDD Cell Integer Value| TDD Cell Integer Value  
---|---|---  
0| sf1| sf1  
1| sf1.5| sf2  
2| sf2| sf4  
3| sf2.5| sf5  
4| sf4| sf8  
5| sf5| sf10  
6| sf8| sf20  
7| sf10| spare1



 Enum Value| FDD Cell Integer Value| TDD Cell Integer Value  
---|---|---  
0| sf1| sf1  
1| sf1.5| sf2  
2| sf2| sf4  
3| sf2.5| sf5  
4| sf4| sf8  
5| sf5| sf10  
6| sf8| sf20  
7| sf10| spare1



 Enum Value| FDD Cell Integer Value| TDD Cell Integer Value  
---|---|---  
0| sf1| sf1  
1| sf1.5| sf2  
2| sf2| sf4  
3| sf2.5| sf5  
4| sf4| sf8  
5| sf5| sf10  
6| sf8| sf20  
7| sf10| spare1



 Enum Value| FDD Cell Integer Value| TDD Cell Integer Value  
---|---|---  
0| sf1| sf1  
1| sf1.5| sf2  
2| sf2| sf4  
3| sf2.5| sf5  
4| sf4| sf8  
5| sf5| sf10  
6| sf8| sf20  
7| sf10| spare1



 Enum Value| FDD Cell Integer Value| TDD Cell Integer Value  
---|---|---  
0| sf1| sf1  
1| sf1.5| sf2  
2| sf2| sf4  
3| sf2.5| sf5  
4| sf4| sf8  
5| sf5| sf10  
6| sf8| sf20  
7| sf10| spare1



 Enum Value| FDD Cell Integer Value| TDD Cell Integer Value  
---|---|---  
0| sf1| sf1  
1| sf1.5| sf2  
2| sf2| sf4  
3| sf2.5| sf5  
4| sf4| sf8  
5| sf5| sf10  
6| sf8| sf20  
7| sf10| spare1, MCH2| x86 HLP| x86 HLP| x86 HLP| | C64DSP(not used)| | | | Radio module 2| Radio module 1|   
---|---|---|---|---|---|---|---|---|---|---|---  
MCH1| x86 HLP| C66DSP1| C66DSP2| C66DSP3| | | | | 



 MCH2| x86 HLP| x86 HLP| x86 HLP| | C64DSP(not used)| | | | Radio module 2| Radio module 1|   
---|---|---|---|---|---|---|---|---|---|---|---  
MCH1| x86 HLP| C66DSP1| C66DSP2| C66DSP3| | | | | 



 MCH2| x86 HLP| x86 HLP| x86 HLP| | C64DSP(not used)| | | | Radio module 2| Radio module 1|   
---|---|---|---|---|---|---|---|---|---|---|---  
MCH1| x86 HLP| C66DSP1| C66DSP2| C66DSP3| | | | | 



 MCH2| x86 HLP| x86 HLP| x86 HLP| | C64DSP(not used)| | | | Radio module 2| Radio module 1|   
---|---|---|---|---|---|---|---|---|---|---|---  
MCH1| x86 HLP| C66DSP1| C66DSP2| C66DSP3| | | | | 



 MCH2| x86 HLP| x86 HLP| x86 HLP| | C64DSP(not used)| | | | Radio module 2| Radio module 1|   
---|---|---|---|---|---|---|---|---|---|---|---  
MCH1| x86 HLP| C66DSP1| C66DSP2| C66DSP3| | | | | 


Tier 2
Tier 1
A hardware thermal upgrade (increased ventilation) is required when the TM500 Platform C is used in this configuration. Do not operate the instrument in this configuration until the upgrade has been performed. See Thermal upgrade on page 51.
A hardware thermal upgrade (increased ventilation) is required when the TM500 Platform C is used in this configuration. Do not operate the instrument in this configuration until the upgrade has been performed. See Thermal upgrade on page 51.
A hardware thermal upgrade (increased ventilation) is required when the TM500 Platform C is used in this configuration. Do not operate the instrument in this configuration until the upgrade has been performed. See Thermal upgrade on page 51.
Slot 1 Slot 2 Slot 3 Slot 4 Slot 5 Slot 6 Slot 7 Slot 8 Slot 9 Slot 10 Slot 11 Slot 12

##Connections

HSS A HSS B
HSS A HSS B
HSS A HSS B
‌Figure 28 - Mk-3 WCDMA Load Tester (2-cell benchtop system)
Note that the C64 DSP card in slot 6, tier 2 is not required for WCDMA load testing
‌Figure 28 - Mk-3 WCDMA Load Tester (2-cell benchtop system)
Note that the C64 DSP card in slot 6, tier 2 is not required for WCDMA load testing
‌Figure 28 - Mk-3 WCDMA Load Tester (2-cell benchtop system)
Note that the C64 DSP card in slot 6, tier 2 is not required for WCDMA load testing
HSS A
HSS A
HSS A
HSS B
HSS B
HSS B
LED
LED
LED
LED
LED
LED
LED
LED
LED
LED
LED
LED
The Ethernet and serial connections are shown in Figure 28.



##‌Mk-3 WCDMA Load Tester (4-cell benchtop system)‌

#Cards/modules required

•2 MCH • 4 x86 HLP
•6 C66 DSP • 2 MBR radio modules

##Card/module positions

‌Table 48 - Card positions (HW104 configuration) - Supports up to 4 cells

 MCH2| x86 HLP| x86 HLP| x86 HLP| | | C66DSP4| C66DSP5| C66DSP6| Radio module 2| Radio module 1|   
---|---|---|---|---|---|---|---|---|---|---|---  
MCH1| x86 HLP| C66DSP1| C66DSP2| C66DSP3| | | | | 



 MCH2| x86 HLP| x86 HLP| x86 HLP| | | C66DSP4| C66DSP5| C66DSP6| Radio module 2| Radio module 1|   
---|---|---|---|---|---|---|---|---|---|---|---  
MCH1| x86 HLP| C66DSP1| C66DSP2| C66DSP3| | | | | 



 MCH2| x86 HLP| x86 HLP| x86 HLP| | | C66DSP4| C66DSP5| C66DSP6| Radio module 2| Radio module 1|   
---|---|---|---|---|---|---|---|---|---|---|---  
MCH1| x86 HLP| C66DSP1| C66DSP2| C66DSP3| | | | | 



 MCH2| x86 HLP| x86 HLP| x86 HLP| | | C66DSP4| C66DSP5| C66DSP6| Radio module 2| Radio module 1|   
---|---|---|---|---|---|---|---|---|---|---|---  
MCH1| x86 HLP| C66DSP1| C66DSP2| C66DSP3| | | | | 



 MCH2| x86 HLP| x86 HLP| x86 HLP| | | C66DSP4| C66DSP5| C66DSP6| Radio module 2| Radio module 1|   
---|---|---|---|---|---|---|---|---|---|---|---  
MCH1| x86 HLP| C66DSP1| C66DSP2| C66DSP3| | | | | 



 MCH2| x86 HLP| x86 HLP| x86 HLP| | | C66DSP4| C66DSP5| C66DSP6| Radio module 2| Radio module 1|   
---|---|---|---|---|---|---|---|---|---|---|---  
MCH1| x86 HLP| C66DSP1| C66DSP2| C66DSP3| | | | | 



 MCH2| x86 HLP| x86 HLP| x86 HLP| | | C66DSP4| C66DSP5| C66DSP6| Radio module 2| Radio module 1|   
---|---|---|---|---|---|---|---|---|---|---|---  
MCH1| x86 HLP| C66DSP1| C66DSP2| C66DSP3| | | | | 



 MCH2| x86 HLP| x86 HLP| x86 HLP| | | C66DSP4| C66DSP5| C66DSP6| Radio module 2| Radio module 1|   
---|---|---|---|---|---|---|---|---|---|---|---  
MCH1| x86 HLP| C66DSP1| C66DSP2| C66DSP3| | | | | 



 MCH2| x86 HLP| x86 HLP| x86 HLP| | | C66DSP4| C66DSP5| C66DSP6| Radio module 2| Radio module 1|   
---|---|---|---|---|---|---|---|---|---|---|---  
MCH1| x86 HLP| C66DSP1| C66DSP2| C66DSP3| | | | |, Examples:
1. System scope to show the Beam management procedure information and stats for mobility between radio contexts (RCs) when configured (when MU-MIMO or MBB is configured in TM500) for the overall system. This example considers the following for mobility among RCs:
•4 RCs RC0, RC1, RC2 & RC3
•40 UEs in the system and 10 UEs configured initially on each RC
•UE0-UE9 on RC0 as UE group 0
•UE10-19 on RC1 as UE group 1
•UE20-29 on RC2 as UE group 2
•UE30-39 on RC3 as UE group 3
•All UEs on RC0 moving to RC1 (RC0->RC1), All UEs on RC2 moving to RC3 (RC2->RC3)
FORW MTE GETNRUEBEAMEVENTSTATS [0] []
C: FORW 0X00 OK MTE GETNRUEBEAMEVENTSTATS SCOPE: SYSTEM ID: ALL
ELAPSED_TIME: 454.9 S L1_BEAM_MANAGEMENT:
[P1 PROCEDURE]

 [SSB Index]| [COUNT]  
---|---  
0| 1000  
1| 1000  
2| 1000  
3| 1000  
4| 500  
5| 200  
6| 200



 [SSB Index]| [COUNT]  
---|---  
0| 1000  
1| 1000  
2| 1000  
3| 1000  
4| 500  
5| 200  
6| 200



 [SSB Index]| [COUNT]  
---|---  
0| 1000  
1| 1000  
2| 1000  
3| 1000  
4| 500  
5| 200  
6| 200



 [SSB Index]| [COUNT]  
---|---  
0| 1000  
1| 1000  
2| 1000  
3| 1000  
4| 500  
5| 200  
6| 200


[P2 PROCEDURE]
[Mobility event count across RCs]

 [RC Id]| [COUNT]  
---|---  
0| 0  
1| 10  
2| 0  
3| 10



 [RC Id]| [COUNT]  
---|---  
0| 0  
1| 10  
2| 0  
3| 10


2. Cell scope to show the Beam management procedure information and stats for mobility between radio contexts (RCs) when configured (when MU-MIMO or MBB is configured in TM500)for a given range of Radio Contexts
FORW MTE GETNRUEBEAMEVENTSTATS [1] [0-1] C: FORW 0X00 OK MTE GETNRUEBEAMEVENTSTATS SCOPE: CELL ID: 0-1
ELAPSED_TIME: 454.9 S L1_BEAM_MANAGEMENT:
[P1 PROCEDURE]

 [SSB Index]| [COUNT]  
---|---  
0| 1000  
1| 1000  
2| 1000  
3| 1000  
4| 500  
5| 200  
6| 200



 [SSB Index]| [COUNT]  
---|---  
0| 1000  
1| 1000  
2| 1000  
3| 1000  
4| 500  
5| 200  
6| 200



 [SSB Index]| [COUNT]  
---|---  
0| 1000  
1| 1000  
2| 1000  
3| 1000  
4| 500  
5| 200  
6| 200



 [SSB Index]| [COUNT]  
---|---  
0| 1000  
1| 1000  
2| 1000  
3| 1000  
4| 500  
5| 200  
6| 200


[P2 PROCEDURE]
[Mobility event count across RCs] [RC Id] [COUNT]
0 0
1 10
3. UE group scope to show the Beam management procedure information and stats for mobility between radio contexts (RCs) when configured (when MU-MIMO or MBB is configured in TM500)for a given range of UE groups
FORW MTE GETNRUEBEAMEVENTSTATS [2] [0-2] C: FORW 0X00 OK MTE GETNRUEBEAMEVENTSTATS SCOPE: UE_GROUP ID: 0-2 ELAPSED_TIME: 454.9 S L1_BEAM_MANAGEMENT:
[P1 PROCEDURE]

 [SSB Index]| [COUNT]  
---|---  
0| 1000  
1| 1000  
2| 1000  
3| 1000  
4| 500  
5| 200  
6| 200



 [SSB Index]| [COUNT]  
---|---  
0| 1000  
1| 1000  
2| 1000  
3| 1000  
4| 500  
5| 200  
6| 200



 [SSB Index]| [COUNT]  
---|---  
0| 1000  
1| 1000  
2| 1000  
3| 1000  
4| 500  
5| 200  
6| 200



 [SSB Index]| [COUNT]  
---|---  
0| 1000  
1| 1000  
2| 1000  
3| 1000  
4| 500  
5| 200  
6| 200


[P2 PROCEDURE]
[Mobility event count across RCs]

 [RC Id]| [COUNT]  
---|---  
0| 0  
1| 10  
2| 0  
3| 10



 [RC Id]| [COUNT]  
---|---  
0| 0  
1| 10  
2| 0  
3| 10


4. UE scope to show the Beam management procedure information and stats for mobility between radio contexts (RCs) when configured (when MU-MIMO or MBB is configured in TM500)for a given range of UE groups
FORW MTE GETNRUEBEAMEVENTSTATS [3] [0-3] C: FORW 0X00 OK MTE GETNRUEBEAMEVENTSTATS SCOPE: UE ID: 0-3
ELAPSED_TIME: 454.9 S L1_BEAM_MANAGEMENT:
[P1 PROCEDURE]

 [SSB Index]| [COUNT]  
---|---  
0| 1000  
1| 1000  
2| 1000  
3| 1000  
4| 500  
5| 200  
6| 200



 [SSB Index]| [COUNT]  
---|---  
0| 1000  
1| 1000  
2| 1000  
3| 1000  
4| 500  
5| 200  
6| 200



 [SSB Index]| [COUNT]  
---|---  
0| 1000  
1| 1000  
2| 1000  
3| 1000  
4| 500  
5| 200  
6| 200



 [SSB Index]| [COUNT]  
---|---  
0| 1000  
1| 1000  
2| 1000  
3| 1000  
4| 500  
5| 200  
6| 200


[P2 PROCEDURE]
[Mobility event count across RCs]

 [RC Id]| [COUNT]  
---|---  
0| 0  
1| 4  
2| 0  
3| 0




‌3.3.11 GetRuStats‌‌
Get the O-RAN RU Stats information
Scope
The command is available in all modes. The effects of this command are immediate.
Description
This command is used to retrieve the O-RAN RU statistical information. The stats are reset/cleared by the SCFG and ClearStats commands.
If you do not specify a “RU Name” parameter in SELR, the stats shall be displayed with an internally generated RU name when the ALL option is used with GetRuStats.
This command retrieves a snapshot of counters from various stages of processing. The values presented are for indicative purpose only and may not necessarily align to an observation boundary.
Syntax
FORW MTE GETRUSTATS <PARAMETERS>
Request parameters

 Parameter name| Type| Allowed Values| Default  
---|---|---|---  
Min| Max  
[| String| -| -| -  
RU Name| Defines the requested RU Name for the display stats.  
]| A special option “ALL” displays the requested information sequentially for
the first 32 RUs. If RU Name is not specified by the user the default is ALL.  
| NOTE: If you do not specify a “RU Name” parameter in SELR the stats shall be
displayed with an internally generated RU name when the ALL option is used
with GetRuStats.  
[| Bool| 0| 1| 0  
Per EAXCID Stats| Displays stats on a per EAXCID basis  
]|, source_sentence: Which ports are used for user access?
sentences: 99.0.7/16
192.168.10.72/16
(VLAN 10U)
(VLAN 10U)
(VLAN 10U)
10.99.0.1/16
10.99.0.1/16
10.99.0.1/16
EPC User 1
EPC User 2
EPC User 3
EPC User 4
EPC User 5
EPC User 6 EPC User 1B
EPC User 1
EPC User 2
EPC User 3
EPC User 4
EPC User 5
EPC User 6 EPC User 1B
EPC User 1
EPC User 2
EPC User 3
EPC User 4
EPC User 5
EPC User 6 EPC User 1B
(VLAN 16U)
(VLAN 16U)
(VLAN 16U)
ETH 24
ETH 23
ETH 22
ETH 21
ETH 1
ETH 24
ETH 23
ETH 22
ETH 21
ETH 1
ETH 24
ETH 23
ETH 22
ETH 21
ETH 1
(VLAN 36U) (VLAN 17U)
(VLAN 18U) (VLAN 11U) (VLAN 19U)
(VLAN 20U)
(VLAN 12U)
(VLAN 21U)
(VLAN 30U)
(VLAN 36U) (VLAN 17U)
(VLAN 18U) (VLAN 11U) (VLAN 19U)
(VLAN 20U)
(VLAN 12U)
(VLAN 21U)
(VLAN 30U)
(VLAN 36U) (VLAN 17U)
(VLAN 18U) (VLAN 11U) (VLAN 19U)
(VLAN 20U)
(VLAN 12U)
(VLAN 21U)
(VLAN 30U)
192.168.10.12/16
192.168.10.12/16
192.168.10.12/16
10.99.0.2/16
10.99.0.2/16
10.99.0.2/16
TSEC1 TSEC2
TSEC1 TSEC2
TSEC1 TSEC2
10.99.0.3/16
10.99.0.3/16
10.99.0.3/16
ETH 2
ETH 3
ETH 2
ETH 3
ETH 2
ETH 3
TSEC0
Master Debug Slave1 Debug
TSEC0
Master Debug Slave1 Debug
TSEC0
Master Debug Slave1 Debug
(VLAN 16-21T)
(VLAN 30-35T)
(VLAN 16-21T)
(VLAN 30-35T)
(VLAN 16-21T)
(VLAN 30-35T)
FOC 1
FOC 1
FOC 1
FOC 2
FOC 2
FOC 2
(VLAN 16-21T) (VLAN 13U)
(VLAN 30-35T) (VLAN 39U)
(VLAN 30-35T) (VLAN 16-21T)
(VLAN 10-15 + 30-35T)
(VLAN 16-21T) (VLAN 13U)
(VLAN 30-35T) (VLAN 39U)
(VLAN 30-35T) (VLAN 16-21T)
(VLAN 10-15 + 30-35T)
(VLAN 16-21T) (VLAN 13U)
(VLAN 30-35T) (VLAN 39U)
(VLAN 30-35T) (VLAN 16-21T)
(VLAN 10-15 + 30-35T)
ETH 4
ETH 4
ETH 4
10.99.0.4/16
10.99.0.4/16
10.99.0.4/16
ETH 5
ETH 5
ETH 5
192.168.10.42/16
192.168.10.42/16
192.168.10.42/16
TSEC1
TSEC2
TSEC1
TSEC2
TSEC1
TSEC2
ETH 15
ETH 15
ETH 15
ETH 16
ETH 16
ETH 16
TSEC0
Master Debug Slave1 Debug
TSEC0
Master Debug Slave1 Debug
TSEC0
Master Debug Slave1 Debug
(VLAN 16-21 + 36-41T)
(VLAN 16-21 + 36-41T)
(VLAN 16-21 + 36-41T)
(VLAN 14U)
(VLAN 14U)
(VLAN 14U)
10.99.0.5/16
10.99.0.5/16
10.99.0.5/16
(VLAN 15U)
(VLAN 1, 36-41T)
(VLAN 15U)
(VLAN 1, 36-41T)
(VLAN 15U)
(VLAN 1, 36-41T)
10.99.0.6/16
10.99.0.6/16
10.99.0.6/16
TSEC1
TSEC1
TSEC1
TSEC2
TSEC2
TSEC2
(VLAN 1, 36-41T)
(VLAN 1, 36-41T)
(VLAN 1, 36-41T)
TSEC0
Master Debug Slave1 Debug
TSEC0
Master Debug Slave1 Debug
TSEC0
Master Debug Slave1 Debug
192.168.10.70/16
192.168.10.70/16
192.168.10.70/16
Mngt port 192.168.10.200/16
192.168.10.201/16
Mngt port 192.168.10.200/16
192.168.10.201/16
Mngt port 192.168.10.200/16
192.168.10.201/16
192.168.10.10/16
192.168.10.10/16
192.168.10.10/16
ETH 19
ETH 19
ETH 19
(VLAN 37U)
(VLAN 37U)
(VLAN 37U)
User (LAN/WAN) TM500 Boot
192.168.10.100/16
User (LAN/WAN) TM500 Boot
192.168.10.100/16
User (LAN/WAN) TM500 Boot
192.168.10.100/16
192.168.10.22/16
192.168.10.22/16
192.168.10.22/16
ETH 20
ETH 20
ETH 20
192.168.10.20/16
192.168.10.20/16
192.168.10.20/16
TSEC1
TSEC1
TSEC1
(VLAN 38U)
(VLAN 38U)
(VLAN 38U)
ETH 18
ETH 17 ETH 6 ETH 7
ETH 8
ETH 9
ETH 18
ETH 17 ETH 6 ETH 7
ETH 8
ETH 9
ETH 18
ETH 17 ETH 6 ETH 7
ETH 8
ETH 9
TSEC2
TSEC2
TSEC2
192.168.10.32/16
192.168.10.32/16
192.168.10.32/16
User 1
User 2
User 3
User 4
User 5
User 6
User 1
User 2
User 3
User 4
User 5
User 6
User 1
User 2
User 3
User 4
User 5
User 6
TSEC0
Master Debug Slave1 Debug
TSEC0
Master Debug Slave1 Debug
TSEC0
Master Debug Slave1 Debug
192.168.10.30/16
192.168.10.30/16
192.168.10.30/16
TSEC1
TSEC1
TSEC1
D1000 Core
D1000 Core
D1000 Core
TM503 #1
TM503 #1
TM503 #1
TSEC2
TSEC2
TSEC2
TM503 #2
TM503 #2
TM503 #2
TSEC0
Master Debug Slave1 Debug
TSEC0
Master Debug Slave1 Debug
TSEC0
Master Debug Slave1 Debug
192.168.10.40/16
192.168.10.40/16
192.168.10., ##‌Check the Interfaces‌

Check that the configured interfaces are available and seen by the server. Run the command ifconfig to confirm all physical interfaces are available and have the correct dummy IP address as specified in the netplan .yaml file.
Check the status of the ethx devices on the VM to ensure they are listed, and status is Active. To do this, on the VM run the command:
/opt/ng4t/bin/dpdkdevbind.py -s
The output should look similar to the following example:
Network devices using kernel driver
===================================
0000:00:03.0 'Virtio network device 1000' if=eth0 drv=virtio-pci unused= *Active* 0000:00:04.0 'X550 Virtual Function 1565' if=eth1 drv=ixgbevf unused= *Active* 0000:00:05.0 'X550 Virtual Function 1565' if=eth2 drv=ixgbevf unused= *Active* 0000:00:06.0 'X550 Virtual Function 1565' if=eth3 drv=ixgbevf unused= *Active* 0000:00:07.0 'X550 Virtual Function 1565' if=eth4 drv=ixgbevf unused= *Active* 0000:00:08.0 'X550 Virtual Function 1565' if=eth5 drv=ixgbevf unused= *Active* 0000:00:09.0 'X550 Virtual Function 1565' if=eth6 drv=ixgbevf unused= *Active* 0000:00:0a.0 'X550 Virtual Function 1565' if=eth7 drv=ixgbevf unused= *Active* 0000:00:0b.0 'X550 Virtual Function 1565' if=eth8 drv=ixgbevf unused= *Active* 0000:00:0c.0 'Virtio network device 1000' if=eth9 drv=virtio-pci unused=
47000/503 Issue 2
© 2024, VIAVI Solutions Inc. All rights reserved.



##‌Server Commands ng40forcecleanup and ng40restartall‌

If the scenario will still not start, or one or more of the ethx devices are not available it will be necessary to run server commands to force clean the configuration and restart all services.
To do this click on the Server button on the top right corner, under the navigation bar:
First run the ng40forcecleanup all command then try to start/re-start the scenario. If the scenario still will not start, run the ng40restartall command, then run the command sudo netplan apply from a Linux command line, then run the server command ng40forcecleanup all.
Start/re-start the scenario.



##‌Check Network Connectivity‌

•Check the network connectivity with ping between the MeNB Relay and other components e.g., the 5G CU (SUT) and the TM500. For example, check if it is possible to ping between the MeNB Relay and the TM500 (w1 interface), the MeNB and the 5G CU (X2 interface), and between the MeNB Relay and MME (s1 interface).
•Check the routing table. A typical routing table may look like the following:
‌Figure 51 Routing Table
•Check the gateway is reachable, if a gateway is required and has been configured.
•Using wireshark, check if sctp is working on an interface e.g., check sctp on the x2 interface to confirm the connectivity is working between the MeNB Relay and the 5G CU.
10
10
10

##Software Update



‌The MeNB Relay component comes preconfigured with a KVM host plus three VMs (Users), and pre-installed with the required software version and configuration. However, it will be necessary to update the software periodically, e.g., to apply an update patch or to apply an installer (for major updates).‌
If the installation is being incremented periodically, the patch update would be good for almost all occasions, especially if there are no significant changes in the configuration template. For larger updates i.e., to apply major changes it may be necessary to update via the installer, such as if updating from release v2.47 to v2.49.
A directory should be created for storing any software patch updates and installers. E.g., create the directory /home/viavi/install.
Software patch updates take the form: TeraVMpatch_BNC_<version>_YY-MM-DD-<time>
An example patch TeraVMpatch_BNC_23-02-13-0313.
BNC: indicates this patch is intended for Ubuntu Bionic (18.04) 23: Is the year
02: Is the month the update was built 13: Is the day the update was built
An installer will have the form: TeraVMinstall_BNC_<version>_online_YY-MM-DD-<time>
An example installer TeraVMinstall_BNC_v249b_online_22-11-22_10-50. BNC: indicates this patch is intended for Ubuntu Bionic (18.04)
v249a: The installer version number 22: Is the year
11: Is the month the update was built 22: Is the day the update was built
online: The installer assumes internet availability on the target server and will install any required Ubuntu .deb packages from online.
47000/503 Issue 2
© 2024, VIAVI Solutions Inc. All rights reserved.
Installing an Update patchUpdating the HostUpdating with the InstallerInstaller DownloadUpdate a KVM HostUpdating the VMsConfiguration UpdateManual Configuration UpdateCustomer Provided Configuration



##‌Installing an Update patch‌

To install a software patch update, ensure you have obtained the correct update patch, and the update is deployed to the host and all VMs. The update needs to be applied to all VMs and the host. Use the following procedure to update each VM one at a time.
•Check the permissions of the patch update file, if necessary change the permissions to be executable e.g.,
chmod 755 TeraVMpatch_BNC_23-02-13-0313
•Shutdown the running scenario (assembly)
•Now run the patch update install. Go to the directory where the patch update is stored, and run the install e.g.,
cd /home/viavi/install
sudo ./TeraVMpatch_BNC_<version>_YY-MM-DD-<time>
•After the installation is complete, check the setup with the command ng40version. You will see the new installed patch and all applicable packages, that would have been updated. E.g.:
‌Figure 52 Example Output of ng40version Command on MeNB User (VM)
It is important that all the packages have the letter ii at the beginning, indicating they are correctly installed. If the letters are anything other than ii, e.g. rc this means an error was encountered during the installation.
Check for internet access and re-run the patch install. It may be necessary to check the install log to determine the install error(s). A zip file with local repository localrepo.tar.gz can be deployed to install any missing packages.
It may also be necessary to unzip the patch update file to re-install missing/corrupted ng40 packages. It is advised to seek assistance from VIAVI/ng4T support in the above situation.
•After a successful update install restart the scenario assembly.
Note: The software can be rolled back to the previous version simply by running the patch update for the previous version.



##‌Updating the Host‌

After the VMs have been updated the host needs to be updated. The host has the KVM installation and VIAVI Control Centre and GUI packages.
•Shutdown all the VMs. You can use either the virt-manager gui or the command line option.
•Run the update install on the host as was done on the VMs:
cd /home/viavi/install
sudo ./TeraVMpatch_BNC_<version>_YY-MM-DD-<time>
After updating the host, check the output of the command ng40version. It should appear similar to the following:
‌Figure 53 Example Host ng40version Command Output
•Restart each VM, one at a time. When the VM is restarted and running, restart the scenario., ‌Grounding the system‌‌‌‌
‌The equipment consists of multiple instruments, each instrument contributing to an overall ground (earth) leakage that exceeds the limiting value allowed by BS EN 61010-1:2010. An additional ground connection is therefore provided to the equipment rack. This must be connected* to a suitable ground connection within the building installation at all times while the equipment is in operation. If in doubt, check that the additional ground connection is making satisfactory contact before switching on the equipment. Failure to ground the equipment may expose you and others to hazardous voltage levels.
A ground (earth) lead is fitted to the equipment and must be connected to a suitable ground point prior to any other electrical connection. An additional ground connection is therefore provided to the equipment rack. This can be disconnected while moving the cabinet but MUST be replaced before opening cabinet doors, mounting or removal of any modules, or making any external connections. See Installing the E500 42U 5G Network Tester on page 98.
•An additional ground connection is not required so long as equipment is connected through a mains socket/plug that complies with IEC 60309.


‌Grounding the system‌‌‌‌
‌The equipment consists of multiple instruments, each instrument contributing to an overall ground (earth) leakage that exceeds the limiting value allowed by BS EN 61010-1:2010. An additional ground connection is therefore provided to the equipment rack. This must be connected* to a suitable ground connection within the building installation at all times while the equipment is in operation. If in doubt, check that the additional ground connection is making satisfactory contact before switching on the equipment. Failure to ground the equipment may expose you and others to hazardous voltage levels.
A ground (earth) lead is fitted to the equipment and must be connected to a suitable ground point prior to any other electrical connection. An additional ground connection is therefore provided to the equipment rack. This can be disconnected while moving the cabinet but MUST be replaced before opening cabinet doors, mounting or removal of any modules, or making any external connections. See Installing the E500 42U 5G Network Tester on page 98.
•An additional ground connection is not required so long as equipment is connected through a mains socket/plug that complies with IEC 60309.


‌Transportation‌‌
Take great care when transporting the cabinet. Only move it on its castors if the ground is completely even and level, and free of any features that might prevent the castors from rolling freely. The embedded-to-castors mounting pads must be fully raised before attempting to move the cabinet. Moving the cabinet on its castors requires a minimum of three people to ensure stability during transportation.
Use a fork-lift truck, chain hoist or professional movers to move it over uneven and/or sloping ground. The E500-D cabinet is too heavy to roll up or down a ramp.
Before using a lifting device to transport the cabinet, ensure that:
•All external cabling to the equipment is removed and the mains cable/plug is secured.
•Any covers are fitted and secured.
•The cabinet is secured to the fork-lift truck before moving.
Verify that the doors along the route to the installation location are wide and tall enough to accommodate the cabinet on its castors.
Cabinet Stabilizer to increase the footprint of the cabinet
Mounting Pad Adjustment
Mounting Pad
Castor
Note: the use of the stabilizers increases the depth of the cabinet by 73 mm.
If there is not sufficient space to accommodate the extra cabinet length, the stabilizing bars can be removed provided that:
•the cabinet is in its final location,
•it will not be moved anymore, and
•the caster mounting pads are lowered.
Stability
Ensure that the equipment is installed on a stable, level surface. Use the pad embedded in each castor (see above) to support and level the cabinet. The cabinet stabilizers increase the footprint of the cabinet to improve stability.
Stability
Ensure that the equipment is installed on a stable, level surface. Use the pad embedded in each castor (see above) to support and level the cabinet. The cabinet stabilizers increase the footprint of the cabinet to improve stability.
Stability
Ensure that the equipment is installed on a stable, level surface. Use the pad embedded in each castor (see above) to support and level the cabinet. The cabinet stabilizers increase the footprint of the cabinet to improve stability.


‌Cabinet Anchoring‌‌
Ensure that the cabinet is correctly mounted within the particular building depending on the installation seismic zone.
High tensile strength rating fasteners and anchors should be used to secure the cabinet base to the concrete floor. Alternatively, high tensile strength pre-tensioned steel cables can be used to secure the 4 eyes (loops) on the top of the cabinet to the ceiling/roof of the building.


‌Toxic hazards‌‌
Some of the components used in this equipment may include resins and other materials that give off toxic fumes if incinerated. Take appropriate precautions when disposing of these items.


‌RF hazard‌‌
Noise hazard
This equipment may produce sound pressure levels that exceed the recommended maximum 85 dBA. Operators may need to wear protective earpieces when working with the equipment.
Noise hazard
This equipment may produce sound pressure levels that exceed the recommended maximum 85 dBA. Operators may need to wear protective earpieces when working with the equipment.
Noise hazard
This equipment may produce sound pressure levels that exceed the recommended maximum 85 dBA. Operators may need to wear protective earpieces when working with the equipment.
Do not disconnect RF cables that are carrying high levels of RF power. High voltages, which can cause RF burns, may be present at the end of the unterminated cables due to standing waves. Switch off any source of RF power before disconnecting cables from the equipment.


‌Suitability for use‌‌‌‌‌
The equipment is intended for use in applications as specified in its accompanying documentation. This equipment has been designed for connection to a network for testing voice and/or data facilities. Use of the equipment for purposes other than these are not recommended and the manufacturer does not take any responsibility for any use of this equipment other than that for which it is intended. Use of this equipment in a manner not specified, or when it is damaged, may impair the protection provided.


‌Suitability for use‌‌‌‌‌
The equipment is intended for use in applications as specified in its accompanying documentation. This equipment has been designed for connection to a network for testing voice and/or data facilities. Use of the equipment for purposes other than these are not recommended and the manufacturer does not take any responsibility for any use of this equipment other than that for which it is intended. Use of this equipment in a manner not specified, or when it is damaged, may impair the protection provided.


‌Damaged Cables‌‌
Damaged AC supply cables are dangerous. Regularly inspect them for damage and do not use if damage is evident or suspected. Do not use equipment where damage to components carrying line voltage (for example, power inlet, line cord) is suspected.


‌Isolating Equipment‌‌‌
A switch/circuit breaker must be incorporated into the fixed wiring that supplies the equipment. The switch/circuit breaker must be rated and approved according to the regulations of the country of use. The switch/circuit breaker must not be part of the supply cord and must not interrupt the protective earthing conductor.
The disconnecting device for the equipment is either the AC supply plug or the switch/circuit breaker incorporated into the fixed wiring. If used as the disconnection device, the switch/circuit breaker must be identified as the disconnection device.
Position the equipment rack so that the disconnection device can be easily accessed in an emergency.
See also Powering down the cabinet on page 15.


‌Removing and installing components in a server‌
If you need to replace a component in a server, observe the following safety precautions:
•Take appropriate anti-static precautions when handling components. Use an anti-static mat and wrist strap when working with servers with the cover removed and when handling components.
•The R730 and R740 servers are too heavy for a single person to remove/install in a cabinet. Ensure that at least two people, working together, perform this procedure.
•Do not operate a server with the cover wholly or partially removed. This could put you at risk of electric shock and cause (overheating) damage to the server and/or components in the server.
Loose cables
When configured for use, the system has a number of loose interconnecting cables that could damage the equipments if they are snagged. When working near the equipment, take care that cables do not catch on your clothing or person.
Loose cables
When configured for use, the system has a number of loose interconnecting cables that could damage the equipments if they are snagged. When working near the equipment, take care that cables do not catch on your clothing or person.
Loose cables
When configured for use, the system has a number of loose interconnecting cables that could damage the equipments if they are snagged. When working near the equipment, take care that cables do not catch on your clothing or person.



##‌Avoiding damage to the equipment‌

Mechanical protection
Take care to ensure all RF components are secured and protected from movement or mechanical impact to prevent damage.
Mechanical protection
Take care to ensure all RF components are secured and protected from movement or mechanical impact to prevent damage.
Mechanical protection
Take care to ensure all RF components are secured and protected from movement or mechanical impact to prevent damage.
Loose cablesMechanical protectionGeneral RF connector careConnecting and torqueing SMA connectorsConnecting and torqueing N connectorsElectrostatic discharge (ESD)VentilationPowering down the cabinetCleaning, source_sentence: What are the features of TMLite?
sentences: Confirm parameters

 Parameter name| Comment  
---|---  
RETURN_CODE| Number to indicate success/failure of request.See MCI return
codes.  
RETURN_TEXT| Text to indicate success/failure of request.




‌3.4.5 NrPhyOverridePdcchInfoForPdsch‌‌
Override the information signalled on PDCCH that is used for decoding the scheduled PDSCH transmission
Scope
This command is available in PDCP mode. This is an Activate-dependent command.
Description
This command is used to override the information signalled on PDCCH. The parameters given in this command are used in decoding the scheduled PDSCH replacing the information signalled on PDCCH.
The command is applied to the specified Radio Context.
Note: This command is currently only supported for 1 UE (UE Id: 0).
Syntax
FORW MTE NRPHYOVERRIDEPDCCHINFOFORPDSCH <PARAMETERS>
Request parameters

 Parameter name| Type| Allowed Values| Default  
---|---|---|---  
Min| Max  
[| Int| 0| 3| 0  
Start Symbol| Provides the starting symbol S relative to the start of the slot
allocated for  
]| the PDSCH.  
| Corresponds to the spec 38.212 Section 7.3.1.2 and 38.214, Section  
| 5.1.2.1.  
[| Int| 1| 14| 1  
Number of Symbols]| Provides the the number of consecutive symbols L counting
from the symbolS allocated for the PDSCH  
| Corresponds to the spec 38.212 Section 7.3.1.2 and 38.214, Section 5.1.2.1.  
[| Int| 0| 0xFFFF| 0xFFFF  
Frequency Domain ResourceAssignment Bitmap| Provides the resource block
assignment in frequency domain as indicated by the resource allocation field
in the detected PDCCH DCI  
]| Corresponds to the spec 38.212 Section 7.3.1.2 and 38.214, Section 5.1.2.2.



 [Modulation and Coding Scheme ( IMCS )]| Int| 0| 31| 0  
---|---|---|---|---  
Provides the index to the modulation and coding Scheme.Corresponds to the spec
38.212 Section 7.3.1.2 and 38.214 Section 5.1.3.1  
[Redundancy Version]| Int| 0| 3| 0  
Redundancy Version.Corresponds to the spec 38.212 Section 7.3.1.2  
[VRB-to-PRB Mapping]| Enum| 0| 1| 0  
Indicates the mapping scheme for mapping of virtual resource blocks to
physical resource blocks.0 = Non-Interleaved1 = InterleavedCorresponds to the
spec 38.212 Section 7.3.1.2  
[Number of DMRS Ports| Int| 1| 12| 1  
Provides the number of DMRS ports.  
For each entry of the ‘Number of DMRS Ports’  
{> Port Id}]| Int| 1000| 1011| 1000  
Port id for the reception of DMRS.  
[Antenna Port]| Int| 0| 63| 0  
Antenna Port(s) as defined in 3GPP-38.212 Tables 7.3.1.2.2-1/2/3/4  
[Modulation and Coding Scheme TB2 (Imcs)]| Int| 0| 31| 0  
Provides the index to the modulation and coding Scheme.Corresponds to the spec
38.212 Section 7.3.1.2 and 38.214 Section 5.1.3.1Note: This parameter shall
only be applied in TM500 if the ‘Modulation and Coding Scheme’ parameter above
for TB1 is present in the command.  
[Redundancy Version TB2]| Int| 0| 3| 1  
Redundancy Version. 2 bits as defined in Table 7.3.1.1.1-2


Confirm parameters

 Parameter name| Comment  
---|---  
RETURN_CODE| Number to indicate success/failure of request.See MCI return
codes.  
RETURN_TEXT| Text to indicate success/failure of request.




‌3.4.6 NrPhyOverridePdcchInfoForPusch‌
Override the information signalled on PDCCH that is used for scheduling PUSCH transmission
Scope
This command is available in PDCP mode. This is an Activate-dependent command.
Description
This command is used to override the information signalled on PDCCH. The parameters given in this command are used in scheduling PUSCH replacing the information signalled on PDCCH.
The command is applied to the specified Radio Context.
Note: This command is currently only supported for 1 UE (UE Id: 0).
Syntax
FORW MTE NRPHYOVERRIDEPDCCHINFOFORPUSCH <PARAMETERS>
Request parameters

 Parameter name| Type| Allowed Values| Default  
---|---|---|---  
Min| Max  
[Number of Symbols]| Int| 4| 14| 4  
Provides the number of consecutive symbols L counting from the symbol
Sallocated for the PUSCHCorresponds to the spec 38.212 Section 7.3.1.1 and
38.214, Section 6.1.2.1.  
[Frequency Domain Resource Assignment Bitmap]| Int| 0| 0xFFFF| 0xFFFF  
Corresponds to the spec 38.212 Section 7.3.1.1 and 38.214, Section 6.1.2.2.  
[Modulation and Coding Scheme () IMCS]| Int| 0| 31| 0  
Modulation and Coding Scheme.Corresponds to the spec 38.212 Section 7.3.1.1
and 38.214 Section 6.1.4.1 Note: Currently allowed range of this parameter:0 -
9 – If the user has set the value 0 (64 QAM) for the ’MCS-Table’ parameter in
command NrPhyConfigPusch.0 - 4 - If the user has set the value 1 (256 QAM) for
the ’MCS-Table’ parameter in command NrPhyConfigPusch.



 [Redundancy Version]| Int| 0| 3| 0  
---|---|---|---|---  
Redundancy Version.Corresponds to the spec 38.212 Section 7.3.1.1  
[Number of DMRS Ports| Int| 1| 12| 1  
Provides the number of DMRS ports.  
For each entry of the ‘Number of DMRS Ports’  
{> Port Id}]| Int| 0| 11| 0  
Port id for the reception of DMRS.Note that currently, the maximum value of 3
is supported for the Port Id.  
[Antenna Port]| Int| 0| 63| 0  
Antenna Port(s) as defined in 3GPP-38.212 Tables 7.3.1.2.2-1/2/3/4  
[Precoding and number of layers]| Int| 0| 63| 0  
Precoding information and number of layers, bit-width value calculated
according to 3GPP-38.212 - 7.3.1.1.2.  
[PTRS-DMRS association]| Int| 0| 3| 0  
Indicate the association between PTRS port(s) and DMRS port(s)  
[DMRS sequence initialization]| Int| 0| 1| 0  
0 = transform precoder is enabled1 = transform precoder is disabled


Confirm parameters

 Parameter name| Comment  
---|---  
RETURN_CODE| Number to indicate success/failure of request.See MCI return
codes.  
RETURN_TEXT| Text to indicate success/failure of request., High Level Tech Spec
AS2 spec can further scale with optimizations (for example beyond 36 CC, 24 MU-MIMO layers, More RU etc)
Data rates can be optionally extended to beyond 25Gbps with NIC UG
viavisolutions.com
Common SW & Tools across deployments allows seamless transition
viavisolutions.com
© 2022 VIAVI Solutions Inc. 7
E500-AS2 Development Themes & Examples
For discussion purposes only
viavisolutions.com
VIAVI//Restricted
© 2022 VIAVI Solutions Inc.
Proprietary and Confidential
System Throughput
CA & MIMO
Density Increase
O-RU
16-24 Layers
Latency Decrease
E500 AS2
URLLC
# UEs
Performan ce
Additional FR2 UEs
24 Layer MU-MIMO
Multi Pcell per CA Group
Increased Tx
/UEs per Slot
System Level LTE/NR UEs
Increased # RedCap UEs
Time Sensitive Logging
36-48
Carriers
12 CC CA
50Gbps
25Gbps
Extending the functionality and performance of the current systems
Deployment Agnostic Software Solution
One Application Software across multiple deployments
Common SW deployed onto whatever platform is needed to achieve the test
Same RANtoCoreTM Application Software: Features, Automation…
TM500
TM500 AS2
Rack
Rack
x86
SW architecture supports private cloud deployment
Access from anywhere, anytime, scale when needed etc
Soft
Mk4.1, MK4.3 CLA/AS
E500 Mk4.1, MK4.3 CLA/HYB/AS
E500 AS2
Soft UE
USEoft
USEoft
USEoft
UCSEoonfttai
nUeErs
Cloud Performance & Scale
Future-Proof Roadmap & Performance
Leading roadmap commitment on all deployment models
Rel-16, Rel-17, Rel-18…
Performance optimizations on all deployments
Test Features: e.g. channel models evolved to support Rel-16 indoors scenarios
AS2 with evolved solution architecture pushes the performance envelope
At least double #CC, #Layers, for high process demanding numerologies
Higher system throughput
Increase in supported aggregated bandwidth and combinations
Lower latency while still maintaining high #UE & #SE
More users (up to 12 users per cabinet)
Higher spec servers in AS2 vs AS
Enabling support for higher-end use cases in the future
Greener
Evolve E500 solution, AS2, has reduced power consumption/per bit /per throughput vs existing deployments
Around 34% reduced power rating per carrier as compared to E500 Mk4.3 SVR(AS).
Additionally, we are working on developing software-oriented E500 power-saving solutions for all the existing install base.
Saving is achieved when servers in the E500 partition are in an idle state.
Servers that are not selected into an E500 ASC group will go to (or remain in) a ‘sleep’ mode (low power states).
Initial in-house measurement shows ~10% power saving at an E500 Mk4.3 SVR(AS) in an idle state after enabling this solution.
Questions
Will the AS2 support more Blind Decodes than AS?
o How much more?
o Increased Tx /UEs per Slot
► Blind Decodes should no longer be an issue on any of the 5G Systems. So there are no plans to increase this further unless absolutely necessary
► The Tx\UEs per Slot is already much higher than Ericsson requires but with AS2 we aim to increase this further without impacting K Values
AS2 will support “Rel-16, Rel-17, Rel-18…”, what about AS?
► Please refer to the main VIAVI message on the roadmap – Exec Summary slide from the main deck.
How do we explain “Future Proof” (AS was also “Future Proof”)?
► The AS system still remains future proof. 3GPP features and roadmap is developed on the AS systems. Keeping in mind that AS technology is equal to MK4.3 this is already 6 years and keeps on delivering.
► Same as above
Size/footprint aspects
► ?
Exec Summary
VIAVI is committed to
Support the 3GPP feature roadmap on all the system variations.
Provide common software across all the hardware deployments.
Preserve and re-use existing investment by offering upgrade paths to uplift the performance further.
Provide evolved solutions to support additional performance needs.
More clarification regarding “Secure product”
Will we keep up with new BIOS versions from DELL
► The current process is not different for AS2. So this is a general H/W question for all the available systems that have servers.
Upgrade from AS to AS2?
► Radio card can be re-used between the 2 systems. Different approaches will have to be explored as long as they are commercially viable.
Can AS2 be rack mounted, i.e. no cabinet?
► Yes. Currently not available but we are working to release the ability of having a rack mounted system
36 CC 4x4
o Any limitation on BW when using 36 CC?
► This is in feasibility and design phase. Most likely some of the Carriers will have to be reduced BW but currently TBD. Further communications to be follow once feasibility work is completed
Data rates, is it correct that if DL only can achieve 25 Gbps?
► The current NIC installed in the system is 25Gbps. There is however an additional slot available to add an additional NIC taking the overall TP to 50Gbps.
VIAVI//Restricted
Other topics
List of selling points and benefits with AS2 -> See next slide
o Success factors from other customers
AS2 Configuration Options
o Can the old RDAs be reused -> Open for discussion
o What are the use cases / justifications for Standalone AS2 versus AS -> Covered through the slides
Do the TK3500 include both RDA and Core-Em?
o How to sell with or without Core-Em -> The H/W is Core-Em ready without any additional cost to Ericsson. Enabling the feature is only a s/w license (optional TK)
URLLC
o Time Sensitive logging -> As part of TSN the TM500 will have to improve the logging performance in order to provide higher granularity.
Selling Points for AS2
Increased Capacity on a Cabinet Level
On a Cabinet we increase from 12CC to 24CC. This is possible due to the higher performance servers used (additional MIPS) and S/W extensions
Reduced Power Consumption per Carrier
Look at power values in the Matrix
Ability to support large configs under Single user
12CC 4x4 Single User vs 3 Users on AS (2 users on AS requires additional H/W)
Scaling on Aggregated Layers for MU-MIMO and CA
AS: Up to 8 Carriers or 16Layers (with some exceptions on the layers for FR1 only)
AS2: 12 Carriers or 24 Layers for FR1 and FR2
Additional Users
3 users on AS vs 12 users on AS2 -> Provides better mapping of the H/W to different types of deployments and use cases.
What is High Density and Double Density?
The Radio Card available in the E500-AS system supports 200MHz of Carrier BW.
E500 can utilise this additional BW by allowing 2 contiguous(in frequency) Carriers to be connected on the same Radio – also referred to as Channelization of Carriers
This allows to double the amount of Carriers connected to each Radio Card
For 4x4 Carriers all the antenna ports are shared between 2 Carriers.
For 2x2 there are 2 sets of 2 Carriers in each Radio -> 4 Carriers 2x2 per PRC
FE SERVER
20 MHz 20 MHz 5 MHz 10 MHz
20 MHz
20 MHz
Centre Freq.
20 MHz
20 MHz
FES
200 MHz 200 MHz
What is High Density and Double Density? (cont)
In order to get the maximum benefit of this Radio capability, the BaseBand requirements should also be condensed
For “High Density” a 4x4 Carrier can be hosted by a single BBS (instead of 2)
4 BBS + 2 Radios can support 2 Carriers 4x4 in a standard config
With 4x4 HD the same H/W can support 4 Carriers 4x4
While for “Double Density” 2 Carriers 2x2 (with reduced BW) can share the same BBS
4 BBS + 2 Radios can support 4 Carriers 2x2 in a standard config
With DD the same H/W can support 8 Carriers 2x2
TM500 Double Density (DD)
In the standard E500 architecture, one baseband server (BBS) provides for 1CC 2x2
Double Density provides improved hardware utilization, enabling less hardware for smaller systems, applicable primarily for NR
Double Density:
provides for 2CC 2x2 20MHz per BBS (up to 4CC per PRC)
is applicable on a per-user basis – max 8CC 2x2 per user
is applicable to NR
Example benefits – improved hardware utilization:
2 BBS can support 4CC
4 BBS will support 8CC
Additional CC for existing hardware
Spectrum sharing capability is a pre-requisite
Standard Config: 1 HL Server, 4 BB Servers

 PRC 0| | PRC 1  
---|---|---



 HL SERVER  
---  
BB SERVER 0  
BB SERVER 1  
BB SERVER 2  
BB SERVER 3  
PRC 0 PRC 1FE SERVER 0, ##‌About this Document‌

PurposeIntended AudienceSupplied Documentation



##‌Purpose‌

The TMLite Features User Guide is designed for E500 release NLA 8.8.0 supporting TMLite, a TM500 platform and its features.
NOTE: All beta and non-commercial releases should be uninstalled before installing this release.



##‌Intended Audience‌

This document is intended to be used by Development Engineers and Project/ Engineering Management.



##‌Supplied Documentation‌

For the complete list of supplied documentation, refer to the Supported Documents section in the E500 Release Notes NLA 8_8_0_45000-533.



##‌1 Introduction‌

1.1 Hardware Compatibility1.1.1 Supported Hardware Platforms



##‌1.1 Hardware Compatibility‌

1.1.1 Supported Hardware Platforms


‌1.1.1 Supported Hardware Platforms‌
For TM500 benchtop systems:

 Benchtop Hardware Configuration/ Number of Radio Cards| Max Number of 2x2
Cells| Max Number of 4x4 Cells| Access Concentrator (ACE) Required  
---|---|---|---  
TMLite (TK1071)| 1*| 1| No  
TMLite2 (HW721)| 1~| 1~| No  
*Also supports upto 2 cells, but with a maximum BW of 20 MHz per cell.^Also supports upto 4 4x4 cells when 4x4-HD and PRC Spectrum Sharing (Channelisation) are used.^^ Also supports upto 8 2x2 FDD 20 MHz cells when 2x2-DD and PRC Spectrum Sharing (Channelisation) are used.** Either one NR cell plus one LTE cell per server or upto two NR cells per server~ NR Cells (LB and MB) only.





##‌2 TMLite (Single Server Systems)‌


 Released in| NLA_4_58_0  
---|---  
License required| TK1071  
FML status| FML1 in NLA_4_58_0  
Supported platform| HW704 that supports 1CC 2x2 and 1CC 4x4 NR SA under
license bundle TK5510 NOTE: Interconnect to Mk3 TM500 benchtop is not
applicable on HW704.  
Description| TMLite, a new TM500 platform, utilizes a single server and each
server supports only one NR cell. The NR cell can support the following
aspects: FR1 (Numerology 0 or 1) or FR2 (Numerology 3) Upto 32 UEs 2x2 UL
and DL MIMO 4x4 DL MIMO for Numerologies 0 and 1 only K1 and K2 values:o For
2x2 SA (NR only cell): Numerology 0: K1 >= 1 and K2 >= 1 Numerology 1: K1 >=
1 and K2 >= 2 Numerology 3: K1 >= 2 and K2 >= 3o For 4x4, SA and all NSA
permutations using interconnect to Mk3 TM500 Benchtop (4x4 and 2x2): Single
UE testing supports the same K1 and K2 values as 2x2 SA above 32 UE testing
requires K1 >= 4 and K2 > = 4NOTE: TMLite can be connected to a Mk3 TM500
benchtop system to facilitate NSA (ENDC) testing and NSA 4x4 DL MIMO for
Numerology 3 connected to a Mk3 TM500 benchtop is not supported.  
Limitations| This feature does not support the following aspects: 4x4 DL MIMO
for Numerology UL DST-S-OFDM Fast fading Flexible PDCCH monitoring


2.1 NSA on a TMLite2.2 2CC 2x2 NR Cells on TMLite2.3 5G O-RAN FH NR SA 1CC 4x4 on TMLite



##‌2.1 NSA on a TMLite‌


 Description| TMLite supports 1 LTE cell (AoS Architecture) and 1 NR cell with
the following configurations: Upto 20MHz bandwidth per carrier (i.e., max NR
carrier bandwidth is 20MHz) Upto 2 layers in DL and 2 layers in UL Upto 32
UEs Numerologies 0 (LB) and 1 (MB) on NR carrier SA support on the single NR
cell NSA support using both carriers (LTE anchor provided by AoS cell)  
---|---  
|



 Limitations| This feature does not support the following aspects: 4x4 DL MIMO
for Numerology UL DST-S-OFDM Fast fading Flexible PDCCH monitoring  
---|---





##‌2.2 2CC 2x2 NR Cells on TMLite‌


 Description| TMLite supports two NR cells with the following configurations:
Upto 20MHz bandwidth per carrier (i.e., maximum NR carrier banwidth is 20MHz)
Upto 2 layers in DL and 2 layers in UL Upto 32 UEs 2CC DL and UL CA
Numerologies 0 (LB) and 1 (MB) on NR carrierNOTE: Both NR carriers must be the
same Numerology, either 2 Numerology 0 carriers or 2 Numerology 1 carriers.  
---|---  
Limitations| This feature does not support the following aspects: 4x4 DL MIMO
for Numerology UL DST-S-OFDM Fast fading Flexible PDCCH monitoring





##‌2.3 5G O-RAN FH NR SA 1CC 4x4 on TMLite‌


 Released in| NLA_5_16_0  
---|---  
License required| TK5522  
FML status| FML1 in NLA_5_16_0  
Supported platform| E500-AS2, such as HW700 (O-RAN only) or HW704 (ORAN/RF)  
Description| This feature provides support for O-RAN FH in following aspects:
SA 1CC 2x2 as well as 4x4 NR FR1, TDD/FDD, and SU-MIMO  
Limitations| This feature does not support the following aspects: NB restart
with ORAN 2CC or higher configurations More than 32 UEs





##‌3 Soft UE_TMLite2‌

3.1 TMLite2 256 UE O-RAN Bundle (4CC – 256 UE)3.2 TM500 5G O-RAN FH OPT 7-2 – Dedicated Port Per RU Link3.3 Supported Soft UE Licenses



##‌3.1 TMLite2 256 UE O-RAN Bundle (4CC – 256 UE)‌


 Released in| NLA_6_18_0  
---|---  
License required| TK5541  
FML status| FML1 in NLA_6_18_0  
Supported platform| E500-AS2 (HW721) platform  
Description| This feature supports the following functionalities: ORAN and
RF CONF SYSTEM SWUE ON is needed before STRT For 2x2 MB and 4x4 MB (15kHz
and 30kHz), 100MHz BW:o MCS 27o 256 QAMo 256 UEs per system and 256 UEs per
CCo Maximum 2CC on one servero Maximum 4CC on two servers using InfiniBand  
Limitations| This feature has the following limitations: Excludes MU-MIMO
Benign PDCCH configuration (maximum number of decodes 2000) The SE per slot
is limited to 32, but only 8 PUSCH per slot per HWI. minK values are one more
than AS2 single server solution DL decoding capability is 3~4dB worse than
AS2 single server K1 and K2 values:o For Numerology 0, minK1 = 2 and minK2 =
2o For Numerology 1, minK1 = 3 and minK2 = 3





##‌3.2 TM500 5G O-RAN FH OPT 7-2 – Dedicated Port Per RU Link‌


 Released in| NLA_8_4_0  
---|---  
License required| TK2222  
FML status| FML1 in NLA_8_4_0  
Supported platform| E500-AS2 (HW720/ HW721) platform  
Description| This feature supports the following functionalities: eCPRIlink
on dedicated physcial port per carrier/ RU for SoftUEo Dedicated NIC
(Mellanox) for eCPRI with 2x port Dedicated NIC (Mellanox) for RDA
(RTRTK1167)



 | NOTE: SoftUE can support 2CCs with 2RUs on single server with each RU a
dedicated port.  
---|---



< Previous | Contents

##‌3.3 Supported Soft UE Licenses‌
pipeline_tag: sentence-similarity
library_name: sentence-transformers
Likes: 0 | All-time downloads: 2480
Created: 2025-03-20 13:16:24