The first item of the everybody's wishlist for most of mobile phone engineers would to get a solution that can capture everything (singling, RF signal) in the live and play it back in the lab and duplicate exact live environment within a lab. Based on my experience with evaluating a lot of systems that is claimed to have this kind of capabilty, I haven't seen any of the solution that does exactly what they claims.

There are several solutions/methodologies we can think of (also I personally evaluated in most cases). Personally I am intersted very much in this area, but there no solution like plug-and-play like solution.  In this page, I will talk mostly about duplicating RF channels and I will post a separate pages for Protocol Stack duplication later.

So my recommendations are

i) set the realisitic expectation (meaning very low expectation)

ii) move forward in very small step at a time and accumulate the knowledge and experience over years.

• I/Q Capture and Replay System
• I/Q Capture with Protocol Stack Decoding Capability
• Using UE logs
• Proposed Equipment Setup
• What the 3GPP Channel Models Give You
• Reference

I/Q Capture and Replay System

There are a couple of hardwares that can capture all the RF around the equipmnent in the form of IQ data with high sampling rate (high enough to match the baseband sampling rate for each radio technology) and streaming into high performance hard disk to store signals for long time (even up to a couple of hours of signal). Some companies provides the signal generators that can play back this kind of captured signal.

However, just capture and replay would not be much help to duplicate the exact live nework environment because duplicating the live network environment mean not only RF quality but also protocol sequence. Even the exact same stream of RF signal would influence completely differently differently depending on the status where UE is at in terms of protocol statemachine.

A replay reproduces the waveform, not the channel. The signal generator puts out the sum of everything the capture antenna saw, frozen as one fixed sequence of samples. The DUT cannot influence it, and a second run delivers the same sequence again.

That matters as soon as a number has to be compared with something. 36.101 Annex B defines two kinds of propagation condition for E-UTRA. Annex B.1 defines the static condition, which has no fading in it at all. Annex B.2 defines the fading conditions, and each one is a delay profile plus a maximum Doppler frequency. A replayed capture is neither of those, so no requirement in 36.101 covers a measurement taken on one.

The replay is still worth having as a regression case. A fault seen once in the field can be re-run as often as needed, and the input is identical every time. The replay cannot produce a number that compares with a specification limit, or with a result somebody else measured on a specified condition.

• A replay is one fixed sequence : the DUT cannot change it, and every run repeats it sample for sample.
• 36.101 knows two kinds of condition : Annex B.1 the static one, Annex B.2 the faded ones.
• A replayed capture is neither : so no requirement in 36.101 covers a measurement taken on it.
• Repeatability is what it does give : the same input on every run, which is what a regression case needs.

I/Q Capture with Protocol Stack Decoding Capability

There is some equipment that can capture both I/Q data and Signaling message. This is a kind of Celluar Network Sniffer (like IP Sniffer, WLAN Sniffer). Ideally if you completely analyze the data, you can get both RF channel information and Signaling message.

But in reality, there is some practical problem as described below.

i) I saw a couple of good sniffer, but I haven't seen any of these tools to have signal generator so that we can play back the signal.

ii) These equipment captures not only the signal for the specific DUT and specific BTS, but also the signal for all the other UEs and BTS that are around the equipment. It would not be a trivial to extract the signals directly influence the DUT.

iii) Like every sniffing tools, it can capture all the protocol stacks but it cannot decode full RRC/NAS message if the message is ciphered. Unforutnatley Ciphering is enabled for most (practically) of live network.

Ciphering has a starting point, and the point is worth knowing exactly. 36.331 clause 5.3.4.3 tells the UE to configure lower layers to apply ciphering after the security mode procedure completes. Ciphering is then applied to all subsequent messages received and sent by the UE, except for the SecurityModeComplete message, which is sent unciphered.

Everything before that moment is readable off the air. 36.331 Annex A.6 lists which RRC messages may be sent unprotected, and MasterInformationBlock, Paging, RRCConnectionRequest and RRCConnectionSetup all carry a plus in that column. The annex is informative, but clause 5.3.4.3 is not, and the two agree.

That divides the extraction list rather than defeating it. A sniffer can read the system information and the connection setup. It cannot read an RRCConnectionReconfiguration, because the same annex says the message shall not be sent unprotected before security activation if it is used to perform handover or to establish SRB2, SRB4 and DRBs. The useful configuration therefore arrives ciphered.

• Ciphering starts at the security mode procedure : 36.331 clause 5.3.4.3 applies it to every message after that.
• SecurityModeComplete is the last message in the clear : the clause names it as the one exception.
• MIB, Paging and the connection setup stay readable : 36.331 Annex A.6 marks all of them as sendable unprotected.
• The reconfiguration does not : the same annex rules it out once the message carries handover, SRB2, SRB4 or a DRB.
• A sniffer sees the opening and loses the rest : which is the precise form of the third problem listed above.

Using UE logs

Another method is to use UE log. Theorectially, if you have following information with very good time resolution, you can generate the signal pretty close to the live network environment.

< LTE >

• RSRP
• RSRQ
• RSSI
• SNR
• Fading Parameters (Doppler Shift, Number of Delay taps, Delay/Loss/Angle of Arrival for each Taps)

< WCDMA/HSPA>

• EcNo
• EcIo
• SNR
• Fading Parameters (Doppler Shift, Number of Delay taps, Delay/Loss/Angle of Arrival for each Taps)

In most of  UE log provided by chipset vendor would give you RSRQ, RSRP,EcNo (At least, I am pretty sure that at least one logging tool has the capability, but haven't tried the logging tool from all the chipset vendor). However, not sure of SNR. We can make some inference about SNR from RSRQ, but explicit print out of SNR will be more helpful.

The tricky part is Fading Parameters. As far as I know, there is no UE logging tool to provide these information. In case of Radio technology like CDMA, WCDMA that use Rake Reciever, there has been some discussion that it may be possible to calculate most of the fading parameters like (Number of Delay Taps, Loss, Delay for each taps) from Rake Reciever information. But I haven't seen any commercialized solution yet.  However, even with this we are still missing with the information of Doppler Shift, Angle of Arrival. In short, I haven't seen any solid technology/means to extract Fading parameters from any data. Some vendor claim they provide engineering service to extract these information from the captured I/Q Data and some vendor claim that they have software tool to estimate these from UE side log, but I haven't got a chance to verify them.

Proposed Equipment Setup

When it comes to simulating live network radio environment, following type of setup is mostly used. Since UE performance is influenced not only by high layer signaling and physical channel condition. We need to both information to simulate those environment more accurately. Even with you have all the information about physical channel conditioin, you need a flexible network simulator to let UE running in sync with a specific physical channel condition. When you try to duplicate the signaling side, don't try to extract and reflect every single signaling messages. It would take too long time/effort, probably end up with failure even with the effort depending on situation. My recommendation is to pick a certain time frame (usually relatively short time frame where there is not so complicated mobility and the time frame) and focus on only one specific cells that is currently in service with the UE and try to get the information only on following RRC message and some MAC information (in case of LTE).  

Again, more tricky part is to simulate physical Radio Channel part. As I mentioned above, there is no solid/easy solution in the industry to extract all the channel information directly from live capture. Still the most common practice is to use those information from 3GPP test spec or Carrier test spec. I know those fading parameter from the spec cannot be accurate model and cannot reflect the unqiue situation for a specific cell at specific timing, but these are the most practical means at hand as of now. If you are really interested in duplicating the live network situation, my recommendation is to start with 3GPP/Carrier test setup first and keep tweaking the parameters over years of try-and-error/experience. It will be very interesting task as an engineer and will be an important intellectual property when you have accumulated those knowlege, but don't put it in the weekly or monthly plan list submitted to your manager :)

Figure 1 puts the whole setup in one frame. A network simulator drives the signalling, a channel simulator sits between it and the DUT, and the arrows down the right hand side show where each channel parameter might come from. The two round icons carry as much of the argument as the boxes do.

Figure 1. The split down the right hand side is the argument of this page. Two of the five sources are marked with an OK sign and three with a question mark, and the three carrying the question mark are exactly the ones that would come from the live network.

• The UE protocol log feeds the network simulator : a green arrow runs from the log down into the extraction list, and a second one runs from there into the simulator.
• The extraction list names five items : MIB/SIB, RRC Connection Setup, RRC Connection Reconfig for LTE, Radio Bearer Setup for WCDMA, and MAC Scheduling Info for LTE.
• The channel simulator takes its inputs from elsewhere : five orange arrows reach it from the right, and none of them comes through the network simulator.
• Two of those five sit under the OK sign : 3GPP Spec and Carrier Spec.
• Three sit under the question mark : UE Log, I/Q Capture and Air Sniffer.
• The question itself is spelled out at the bottom : Doppler Shift, Number of Delay Taps, Power loss for each taps, Angle of Arrival and Phase Angle.

One item in Figure 1 does not appear in the text above it. Phase Angle is in the picture's list of fading parameters and nowhere in the prose, and the section below shows that 36.101 has no parameter for it either.

What the 3GPP Channel Models Give You

The advice above ends on the 3GPP models without saying what is inside them. Three delay profiles and one Doppler number cover all of it, and the section below lists every tap in them.

36.101 Annex B.2.1 defines the three profiles, chosen to represent low, medium and high delay spread. Each profile is a list of taps, and each tap carries an excess delay and a relative power. Table B.2.1-1 gives the shape of all three, and it is reproduced below.

A naming rule supplies the rest. 36.101 Annex B.2.2 says the conditions are written as EPA, EVA or ETU followed by a number, and that the number is the maximum Doppler frequency in Hz. EPA5 is therefore the Extended Pedestrian A profile at 5 Hz, and ETU300 is the Extended Typical Urban profile at 300 Hz. Table B.2.2-1 in the same annex reads Void, so the naming rule is all the annex gives.

The taps themselves are what a channel emulator loads. Figure 2 draws all three on one delay axis, at the values Tables B.2.1-2 to B.2.1-4 give.

Figure 2. All three profiles on one delay axis, so the difference in span is visible rather than stated. EPA finishes inside 410 ns and ETU runs to 5000 ns, which is more than twelve times the span.

Spatial correlation is configured on a separate axis. 36.101 Annex B.2.3.1 says the parameters α and β define the spatial correlation between the antennas at the eNodeB and the UE, and Annex B.2.3.2 gives five settings for them in Table B.2.3.2-1.

Two things follow for anyone trying to match one live cell. The models carry no angle of arrival and no phase angle, so two of the five items in Figure 1 have no parameter to set in a 36.101 configuration. The Doppler frequency is also a single number for the whole channel rather than a value per tap, which is a coarser description than a real multipath environment.

• Three profiles cover the delay axis : EPA, EVA and ETU, at 7, 9 and 9 taps.
• The number after the name is the Doppler : 36.101 Annex B.2.2 writes the condition as the profile plus the maximum Doppler frequency in Hz.
• There is no table of permitted combinations : Table B.2.2-1 reads Void in 36.101 v20.0.0.
• Correlation is set separately : five settings from Low to High, given as α and β in 36.101 Table B.2.3.2-1.
• Angle and phase are not in the model at all : two of the five parameters Figure 1 asks about have no parameter to set in a 36.101 configuration.

Reference

Two specifications carry the checkable part of this page. The radio one supplies the channel models, and the RRC one settles which messages a sniffer can still read.

[1] 36.101 : 3GPP - E-UTRA; User Equipment radio transmission and reception, v20.0.0. Annex B.1 gives the static propagation condition. Annex B.2.1 gives the three delay profiles and every tap in them, Annex B.2.2 the naming rule, and Annex B.2.3 the correlation matrices.

[2] 36.331 : 3GPP - E-UTRA; Radio Resource Control, v19.3.0. Clause 5.3.4.3 says where ciphering starts. Annex A.6, which is informative, lists the RRC messages that may be sent unprotected.