agilent_sep2810

Slide 1: CHRIS KEACH: Hello everyone from around the world and welcome to today's event, How to verify the data in your LTE downlink signal, brought to you by Agilent Technologies, and EE Times. Keach and I'll be your moderator. announcements before we begin. We have just a few I'm Chris

This webcast is designed to be To participate in

interactive between you and the presenters.

the Q & A session, enter questions at any time during this presentation by typing your question in the box on the left-hand side, and then clicking Submit. ask you to fill out a short survey. Later in the program, we'll The survey can be accessed

by clicking on the Survey button on the left-hand side of your interface. The survey will also open up at the conclusion of By submitting this survey, you'll be

the presentation.

providing EE Times and Agilent Technologies with valuable information on how we can improve the webcasts. Those of you

who fully fill out and submit the feedback form will be eligible to win a $75 Amazon.com gift certificate. Agilent will be

giving away two of these $75 Amazon.com gift certificatesone to an attendee of the live event, and one to a viewer of the archive. The winner will be notified via e-mail. Now on to the

presentation.

Joining up today will be Peter Cain, product Welcome, Peter! At this time,

manager at Agilent Technologies.

I'd like to turn the presentation over to you.

PETER CAIN: Thank you, Chris, and welcome to everybody. The construction of

the LTE downlink signal is the most complex that's used so far in the implementation of a cellular system. Making use of the

flexibility provided by OFDMO and MIMO, the formats of the downlink and the uplink are S-signals, defined using a mixture of messages across several layers in the protocol. This

presentation shows in detail how some of the most important message is built up, and how to verify step-by-step whether the signal you're dealing with is constructed according to the 3GPP release 8 standard. The presentation makes extensive use of the

89600 vector signal analysis software application, to show the link between the protocol messages and the actual RF signals they control. Let's take a look at the agenda.

Slide 2: PETER CAIN: We'll start with looking at the downlink in some detail, both examining it from a physical point of view, and the decoded information that describes it. Having explored the construction

of the signal, we will work through a number of examples, associated within the construction, that will highlight how we can verify if the signals are as they should be.

Slide 3: This slide shows some of the examples of where it's useful and valuable to understand the downlink signal, and it ranges from, if you're a baseband signal developer and you need some independent verification, through to situations where you've got low-level interoperability problems, or possibly even that you simply wanted to understand in detail the structure of the downlink signal. The final point relates to one of the many

control loops that are present in the LTE system, and this is in the case of where you've got HARQ processes, and you need to work out if they're operating as you expect.

Slides 4 & 5 Before we begin looking in individual details, let's have a look at the overall structure of the downlink signal, and it starts at the bottom of the slide with the physical channels that I've color-coded because during the presentation, we'll use that color-coding to describe different signal that we see and we examine. That moves up to the transport layers, and then at the And as an example of the

top level, we've got logical channels.

way that you need to look at multiple layers to recover all the information about the signal, I've highlighted how the master information block comes down through the broadcast channel, but the system information block is a message that gets constructed and comes down through the downlink-shared channel.

Slide 6: Something that we've found is that it's important, and very useful, to start with a physical view of the signal, and if you haven't seen this display before, what it shows is what's called a spectrogram, and it identifies how the exact physical nature of the signal changes over time. So the horizontal axis is

frequency, and the black-and-white insets show the spectrum at certain instances during the course of the radio frame, whilst vertical axis is time, allowing us to see how the signal changes during the course of a frame. And it can be particularly useful

to take this view of the signal if you're believing that there's something in the signal that the messages aren't telling you about.

Slide 7: We can zoom in, as I've done here, and identify individual parts of the signal, right down to the reference signal sub-carriers, and we can see the symbol-by-symbol structure.

Slide 8: Zooming back out a little bit, we can relate the itemsonce we get used to the patterns that they show in this display, we can relate different items to locations on the screen, and I've identified everything, from broadcast channels, through to the downlink shared channels. And we'll come back to using this So, this kind of

example as we work through the presentation.

display doesn't require any kind of decoding, but it's a very useful tool to have to ensure that we can get back, on occasions, to exactly what really is present in the signal.

Slide 9: Because it's so useful, I've described here how it is that you create such a spectrogram. You start by recording the signal,

which implies that you capture a small period of time that includes the signal that you're interested in, and you configure an FFT-based spectrum view, according to the setups that I've got here, that will give us good resolution in the frequency domain. Then, finally, you play back that recording, and you

adjust the amplitude scale to get the best mixture of colors.

Slide 10:

As well as the physical view, of course, what we're interested in now is in a view that gives us a logical assessment of what's in the channel, or what's in the frame, and this is called the detected allocations view, and it shows, using the same colorcoding, the same kinds of signals, but now more with a logical view rather than just plain physical.

Slide 11: If we rotate that detected allocations view, and place it alongside the spectrogram, if we go from left to right, we can actually see the connection between these. In the spectrogram,

the red highlights higher power signals, the green, lower powers, and blue the lowest, or the noise in this case. And as

we go from left to right, we can see everything, from how the primary and secondary sink, a broadcast channel at the top, map across down though to the shared-channel allocations that are about midway down, and that we'll come back to and examine in more detail later.

Slide 12: So, that's given us a quick view of several ways to assess what's present in the signal. Now let's start considering what

the downlink signal is going to contain.

Slide 13: And, for the mobile and the basestation, the eNB to work together, this is a list of most of the information that's going to have to be shared to do that. So for example, it could be

telling the UE, Have a label, it's uplink transmission, so the eNB knows where they're coming from. In the downlink, it could

be telling the UE receiver, there's a spatially-multiplexed signal. Or, more simply, which points in frequency and time it

should be looking for certain signals that are being sent to it. Earlier on, I'd mentioned that there are a number of control loops, including HARQ and transmit power, and information for these signals has to be sent as well. So, there's a huge amount

of data that has to be sent to configure the receiver and the transmitter in the mobile.

[slides 14 through 16 blank]

Slide 17: I'm going to start with the broadcast channel, which is part of the information that's used to do this. The table shows on the

left the many items of information that we'll be looking for, from the system frame number through the signal bandwidth and how many transmitters are being used...and we also want to make

sure that the CRC check for this channel is correct, so that we can confirm that the coding has been constructed properly.

Slide 18: If we look at the display of the analyzer for the broadcast channel, which is marked in green, we start at the top by just confirming that the radio modulation is correct, so this is using a constellation...the signal is transmitted as QPSK. can see there are a couple of situations where, although the signal is going to be maybe recovered correctly, there is an issue, because the constellation points don't line up with the expected references. This could be, for example, if you've We

chosen the wrong number of inputs in your receiver for the number of transmitters being used, or if the power for the broadcast channel, relative to the reference signals, has been set incorrectly. In the center of the screen, we see the

detected allocations, showing the broadcast in subframe 0, in green, and at the bottom, we see the information that's been recovered in the analyzer, that is letting us understand what it is that we've got in front of us.

Slide 19: Something that I'll be making extensive use of is the ability to filter out these individual signals. So in the signal we just

looked at, there was a lot more than broadcast channels being transmitted, but by using the controls as shown here, we can actually select individual items to examine them in more detail. So with a broadcast channel, we know broadly what kind of signal we're dealing with in terms of bandwidth, and of course, although I haven't mentioned it so far, we'll be looking to make sure that we've got the ability to analyze either FDD, or TDD. In these slides, I'll be concentrating on FDD, but [matrix?] analysis applies to the TDD signal too.

Slide 20: And moving on from the broadcast channel, we come to the CFI, or the control frame indicator. Now this is evidence of some of

the versatility in the downlink signal construction, because the control frame indicator tells us how big the control channel itselfhow much space it's going to be and where it's going to be transmitted. So the CFI is the preliminary indication of Looking

where the UE will find out what its instructions are.

at the lower half of this trace, it's possible to zoom right in to individual subcarriers, to identify exactly where the signal is being transmitted, and that's what's shown in the zoomed-in resource element group block.

Slide 21:

From the control frame indicator, we move on to the PDCCH, which contains the downlink control information, so this really is the most essential item for the mobile to be able to correctly recover, and it has to be encoded correctly, otherwise the whole system won't be able to operate properly. Again, it's As

transmitted as QPSK, shown in the constellation at the top. we move to the center of the screen, though, we can see that

there's a variety of different transmission arrangements that it can take in terms of the allocations, and in fact it could take anything from one, two, or three different symbols, depending on how much information's to be sent, and how robust the signal has been codedhow strong the coding has been.

Slide 22: When we combine the two displays of detected allocations as shown here, we can see how they both are initially aligned at the beginning of each subframeso in the first part of the subframe, both the CFI and the downlink control information will be sent at the same time. Then, if the control information

takes up more time than is available, it will move on to the second and possibly the third signal. In the inset, we can see

that it's not always the case the DCI's going to be transmitted. If there aren't downlink transmissions taking place, then there's no need to send that information there to describe it.

10

So in the inset, you can see there are some of the subframes that don't have any transmission here, and that won't be happening. Obviously in a real, loaded-up network, it's

unlikely to see so much of that.

Slide 23: If we move back out again...as I mentioned earlier, some of the information the mobile needs is just a label in order to know where it should be listening, or what signal it should be listening for, or how it should be identifying its own transmissions to the base station, and that's where the RNTI comes in. Looking at the left-hand column of the table, we can And the bulk of

see that there's a variety of different types.

these, actually, are going to be used for sending transport, or user information. But some note for use later, we can see

there's some, such as the system information RNTI, at the bottom of the page, that are transmitted with a rather noticeable FFFF, and we'll come back to why that's useful. The other thing to

note here is that there are some possibilities for overlap between the RNTIs, and it's something that we will need to account for when we come to confuging the analyzer for certain types of signal.

Slide 24:

11

If we go back to the display on the VSA of a signal that does have downlink information, we can see how the RNTI is reported, and by a quick check of the value that's been recovered with the part of the table that I've reproduced at the top, we can see that that would be shared-channel information that's being transmitted.

Slide 25: Something else that is necessary to be sent is the information that actually describes the DCI, and here we can see the control channel element offset value, and the aggregation level. It's

potentially a little confusion, because we've got an arrow, and an Aarrow stands for the aggregation level; we'll come to A in a moment. But what the arrow indicates is how much coding we're

putting on to the signal to protect it from corruption within the channel.

Slide 26: There are a lot of different ways that we can send this downlink control information, and the table here shows those that are used for the downlink parts of the signal. they play varies too. And, the role that

So, some of them, for example, the 2 and

2A would be associated with MIMO transmissions; 1A is one that we'll see pretty frequently, and is a compact form, or

12

relatively compact form, that is used for a number of things shown in the right of the table here, from the resource block assignments and the transmit power controller, or the TPC, amongst others.

Slide 27: There are also DCI formats that are specific for the uplink, and these are shown in the red color. In particular, we've got DCI

format 0, which again, we would expect to see very often, and will identify straightaway an uplink transmission. At the

bottom of the table, we can see there are some more specific ones for transmit power control, under 3 and 3A.

Slide 28: Here we have an example of one of the DCI formats, and the payload length, which is actually what's referred to in the specification as A, and these two items go together to let the mobile know what it's dealing with when it needs to recover this signal. So, if you'll recall from the previous slide, format 1A

will identify a SISO downlink transmission.

Slide 29: Here, in this example, I've got a combination of downlink and uplink, and so, as the slide indicates, we can tell at a glance

13

what we've got in this signal by using this decoded information. We have a mixture of SISO in the downlink and uplink signals, and the table on the chart reminds us what those choices will be. If we had SISO, then we'd be expecting to see a 2 in the

format.

Slide 30: As well as that format information, there's also a relationship with the transmission mode, or what kind of transmitter-antenna arrangements are used in the basestation. And, working from

right to left in this case, we can see how those things tie up. And, the kind of use that we'd put this information to is just to verify, when we're looking at different signals, that the transmission formats are what are expected. And there can also

be situations where it helps us understand, if we are getting decoding problems, as to whether we've configured our receiver correctly. Sometimes the receiver may not yet be fully capable

of recovering all parts of the signal, and this would be a way to confirm the kind of signal we were putting into it.

Slide 31: If we move on to other parts of the signal, there's actually, for the eagle-eyes amongst you, a typo in this slideit's downlink assignments, and I've identified those. This is the

14

spectrogram again, of course, and I've identified those in the two block boxes on the left-hand side of the screen.

Slide 32: When we go back to the information that's been recovered from the control channel, we can see, in the zoomed-in part of the picture, what it is that we're dealing with here, and in fact, we can tell that we do have a MIMO signal, based on the information we've got. We can also understand the assignments The

that have been given for that signal in the value of NPRB.

value of 25 in this case tells us that we'd be using the entire spectrum for a certain period of time in a 5 megahertz channel.

Slide 33: There are a variety of different ways that the description of the resource block, or the space and time that will be used for the transmissions, can be described. And again, these relate to

the formats of the downlink control information itself, listed in the left-hand column. And depending on the channel

condition, or the type of control that the eNB wants to have over the signal, a number of these could be chosensome probably will be more common then others. In fact, the 2(L) rather than

the MIMO, with the localised structure of the signal.

15

Slide 34: So, if we look at another view of the signalin this case, extended now out to five frames rather than just to one, we can see a mix of activity as we go from one frame to the next, so, actually, in the first frame, there weren't any transmissions, there was no control frame information or PDCCHI there. As we

move across to the right, we can see there are two resource blocks down at the bottom half of the detected allocations; further across, a few frames later, we can see again two resource allocations, but now spaced out in time rather than in frequency. And then, finally, and interestingly, you'll notice Now, all that's happened

on the final frame, there's a gap.

here is that the format would be 0, indicating that there's an uplink transmission here. So, because we are looking only at

the downlink, that would explain why we don't see an allocation in the downlink signal.

Slide 35: This picture shows the difference between the localized and the distributed allocations, which are identified in the center of the chart, in the format. And, when it comes to the distributed

signal, we can see what's happened is that the resource allocation has been spread out in frequency. So, the

implication would be that the base station has concluded from an

16

assessment of the channel, maybe with help from the UE, that it's better and more likely to be successful in sending the signal if it applies some frequency diversity.

Slide 36: As we move on in the analysis of the signal, we can look at some of the commands that are sent to the uplink, and in this case, we're able to see the difference between hopping, for the resource allocations in the uplink, whether it's turned on or off. Using a spectrogram again, but this time on an uplink

signal, we can very clearly see the difference between the hopped PUSCH, at the top, and the non-hopped at the bottom. And

according to the instruction, we'd expect to see the non-hopped for this case, based on that DCI recovery.

Slide 37: Something else, of course, that's very important for the mobile to be able to understand in receiving signals, or to know when it sends them, is what moduation complexity it should use in the transmissions. There are three basic physical possibilities,

from QPSK to 64QAM, but there are many more possibilities in the level of coding strength that's applied, and these are listed in the chartthere are slight differences between the uplink and the downlink, but we can see we've got many possibilities to

17

choose from here, and of course, to correctly recover the data, we're going to have to make sure we pick out the right one.

Slide 38: In this example, we've got a mixture again of an uplink and a downlink signal. The uplink is the format 0, the downlink is

1A, and if we look at the MCS values, we can tell we've got a mixture of QPSK in the downlink, and 16QAM in the uplink.

Slide 39: Further along, we move into information describing the flow of packets, so here we've got the information telling us whether there's new data coming from the downlink, or what the redundancy version is. Because we'll be in a position to deal

with spatially-multiplexed signals, we also at this point are telling the system which layer is being used for that particular part of the signal. So, in a normal live signal, we would

expect this information to be changing pretty regularly.

Slide 40: Further on, we can see the transport block size, and this is a very important value, because it does vary a lotwell, it varies directly according to the MCS value that's chosen. Of course,

the stronger the coding protection you put in, the less data

18

you're going to be able to get through.

But, this can give us a We will

pretty direct indication of what the throughput is.

have to take account of whether there's [three?] transmissions taking place, but otherwise, every millisecond, looking at the transport block size, we can work out what the expected throughput will be at that point.

Slide 41: We also get information that is controlling the mobile, or the UE, from a higher control plane; here we are seeing whether the mobile is being requested to give CQI responses, or channel quality indication responses. So we all have these situations

that we're recovering the signal in the downlinkwe'd expect to look for an appropriate response from the mobile.

Slide 42: And something else that's very important from the point of view of decoding, of course, is CRC checking, and I liken the CRC to the baseband developer's equivalent to EVM. EVM lets the radio

engineer get a quick check of whether everything is OK when it comes to the performance of the transmitter, and in this case, the CRC gives a high-level view of whether everything's working out correctly in the coding of the signal. So, a very important

item to be able to identify, and again, we can see that there's

19

a layer of information here, depending on what kind of transmission we're expecting.

Slide 43: We mentioned HARQ earlier; one of the other power...the control systems that's involved, and essential to all mobile or cellular systems is of course the transmit power. Here we can see a

table that gives us an indication of what the possibilities are. The transmit power controls generally send relative values, so the basestation can regularly correct the power, and the mobile will use that in conjunction with a lot of locally available information to determine its transmit power. The values do

change somewhat depending on the way the signal's sent, and whether it's a shared channel or a control channel.

Slide 44: Looking at the recovered information, we can see, first of all, by identifying the DCI format 0 for the uplink, and then the transmit power commands, what it is that's being sent to the mobilein this case, the TPC equals 1, just means that it should keep the power the same. That could also be a way to make sure

that the mobile really is doing that, and it's not deciding to do something different.

20

Slide 45: If we go back to the spectrogram, and look again at the downlink allocations, if we look carefully, we can see that there's actually a difference in color between these. Now what that

tells us is that there's a difference in power between those.

Slide 46: We can confirm whether the transmission is being sent as we expect by looking back at the decoded information trace, and we can see indeed that one of those resource allocations has been bound to be 3dB lower than the other. So, we can spot the

change in signal physically, and we can also measure that, and align the results to one of the correct values that the basestation should be using.

Slide 47: As we move on to HARQ, actually, there's of course both downlink and uplink HARQ processes, and here I'm looking at the uplink HARQ. There's two different ways we can assess what's happening

here, and one of them's a little unusual, but gives you pretty good visual indication of what's going on, and that's to take the pairs of symbols that are sent, to control the system in the uplink, and to despread the IQ. We've got three possibile

choices of information, so it could be acknowledged, not

21

acknowledged, or off, which gives us this rather interesting 9QAM display. And, we can map where the constellation should

fit according to the choices of information, and in this case, as we'll see on the next slide, everything is OK, because we've got acknowledgments, or the processes are turned off. If we

look at the lower half of the display, we can see the same information represented digitally, by one process being acknowledged, and one of the others being off.

Slide 48: Now, it's beyond the scope I've got time for to go into the detail of this mapping process, but the picture here shows in a little more detail how that despread IQ function works, and the different combinations that we might expect depending on where we see the signals. Essentially, if we see the signals in the

lower left quadrant, that implies that the processes are all passing, or switched off.

Slide 49: As well as the uplink, we can find information about the downlink HARQ processes. asynchronous. And, unlike the uplink, these are

Towards the right of the slide, we can see a

number of different values for HARQ processes that have been recovered here, and you can see that the numbering scheme isn't

22

synchronousit's depending on how the transmission, successfully or otherwise, made it across. But it does give us, again, using

the information from the PDCCH, information that lets us understand how well the system's operating, and, in fact...for example, if we've got a highly complex signal, with 64QAM, and we're checking throughput, then we could use this kind of information to ensure that everything's moving through as fast as it should, and that there aren't any bottlenecks or buffering problems.

Slide 50: While I've given an indication of a fair bit of the information that is present in the downlink control channel, I'm not going to go through every single item. But, in the table here, we can Some of these, as others

see other parameters that are sent.

earlier, are dependent on which DCI format that we've got, and the table's there for reference, to go back to see what it is that the...whether the signals are being sent where we expected, or to confirm that they're being sent at all.

Slide 51: So, that's our tour through the downlink. What I'd like to do

now is to look at a number of troubleshooting examples, because this is where we can then put the knowledge we've got to use,

23

and try to figure out if we can get to the bottom of problems, when the mobile and the basestation aren't interoperating correctly.

Slide 52: So, there's six different examples that I've got, starting with a CRC failure in the broadcast channel. And we've then got a

number of different, progressively more complex situations to recover. So let's start with the broadcast channel.

Slide 53: And what we can see here is that the VSA hasn't been able to recover the broadcast channel. At this point, we don't know

why, but there's a problem that has presented the CRC correctly being decoded, so we're showing it as being invalid.

Slide 54: Now, the way that we can get to the bottom of this is to look at the intermediate information that's shown here, and what it involves is looking at either the raw symbols, or the decoded symbols. And generally, what we'll do is to start with the raw

symbols, so this means to undo, or don't rely on the coding, temporarily, but go back to the start of the signal generation in the baseband, and check that the bits that are being sent

24

here are what were originally presented to the coding system. It's possible to go beyond that, and to check through each stage, through the de-scrambling and rate-matching. But the

most effective place to start is to go with the information that's presented on the symbols trace.

Slide 55: And that technique of recovering information from different traces is something that will apply to a lot of the digital decoding corrections that we're looking to address. In the

second example, we move on to an issue with the downlink control information. And, the question as we look at this, is, there's

something wrong with this picture, and what is it?

Slide 56: Well, for the sharp-eyed, again, you may have noticed already that whilst we have four subframes where we should be transmitting signals, we've only managed to recover three of those DCI's. Again, we don't know immediately what it is that's

causing that, but we want to check whether something really is banned from being transmitted in that fourth part of the signal. And a way we can do this is to go back to some of the measurements that have been used for checking the radio performance.

25

Slide 57: And here I'm showing the error-vector magnitude versus time display in the top part of the trace, and if you look at the lower left-hand side, you can see I've checked the box marked unallocated. What this means is that the analyzer will look

for anything that it can find, and if it's nothing correctly coded, it will show it as an error. So we do have a signal

there, and the issue is that the coding information to describe the allocation isn't correct.

Slide 58: This ability to switch from the logical to the physical is very important when it comes to being able to identify different kinds of problems that you start off, typically, not knowing exactly what it is that's going wrong. Here, again, we've gone

to the Symbols trace to isolate the DCI that was associated with that missing allocation, and, it turns out, in this particular case, that the coding error was due to a corruption in the data field.

Slide 59: For the third example here, where the DCI is decoding OK, and we're getting a lot of the information we've seen before, but

26

when we get through to looking at what's happening to the downlink shared channel, we're getting a CRC failure. And the

root cause of this problemif we look at the broadcast channel information in green, we can see that we've got two transmit signals, and what we realized here was, we only hadwe're using one input channel to measure it. So, because the control

information is sent as a diversity signal, we can recover all that with only one input channel, but when it comes to recovering the MIMOthe spatially-multiplexed signal, we need as many inputs as there are transmission layers, so that's why we've got this problem here.

Slide 60: In the fourth example, we've got another situation where we're failing with CRC errors, but now, it is only SISO signal, but we do know that it's got a high modulation order.

Slide 61: So, before we get too involved checking out the contents of the digital part of the signal, which we may need to do, it's always useful to go back to the analog views, and check whether the signal itself has the fidelity we need. When we look at the

constellation for this signal, we can tell it's very far from being entirely happy, by the lack of clarity with 64QAM shown in

27

the constellation, and if we look at the error-vector spectrum, we can get further understanding of what's happeningit's a mixture of poor noise, and there's even a specific item of spurious interference, that's marked in the left-hand, taller of those red rectangles. So, we talked a lot about the digital

coding that's involved in the signal, but we mustn't forget that there's times when it could be that it's not that's the problem. We should always choose to move backwards and forwards from the analog and digital domain, to make sure we're looking in the right place for the problem.

Slide 62: The fifth example takes us into a slightly different dimension, because what's happening here is that we're in a situation where the mobile can't find the basestation, and we need to go and check that the description the basestation is giving of itself is what the mobile's been programmed to expect, in a case for example where the mobile is working in any kind of programmatic configuration. I mentioned very early on the RNTI'ssome of

them are quite explicit and obvious, and the system information block is one of those. So what's happening here is that we're

identifying the FFFF as a tag, and taking the information that we've decoded from thatit's shown here in the orange rectangle on subframe five, where system information block one lives.

28

We're then using a macro facility in the analyzer, and running it in conjunction with an external ASN1 decoder to get all the way back to recovering the system information. So, this is

extending the capability of the analyzer, but in a particularly useful wayto identify the high-level information describing the signal.

Slide 63: Something else that we can do if we make use of external capability is to apply further filtering to the signal. We've

seen how we can apply filtering to individual components in the downlink control. Here, we're taking information from the

recovered signal and using an external spreadsheet to filter out and look for particular parts of the signal. And towards the So when

bottom of that spreadsheet, you'll see the CRC failure. there, as quite often can be the case, there're sort of

relatively irregular CRC failures, you can use this kind of technique, or, it's even possible to create a macro to trigger on just CRC failures, so that you can then go and examine them in more detail.

Slide 64: So, I said earlier on, there was a lot of information that the UE needs to know about, and hopefully, you've seen, as I've

29

shown, the information in the tables here is stuff that we can recoverits what we can recover from the analysis of the downlink signal.

Slide 65:

Slide 66: When we look at the solutions that Agilent's able to bring to bear on these problems, we've been making extensive use of the Agilent VSA, the 89600 with these two options for FDD and TDD, as shown here.

Slide 67: There are other tools which include the signal generation and Signal Studio, which has advanced capabilities to construct pretty complex signals that marry the capability, or align with the capability in the VSA.

Slide 68: And, for those involved in system design work, we have SystemVue, which has different options depending on whether you're wanting to explore the creation of different kinds of signals or whether you're more into verification.

30

Slide 69: And finally, as we go to the real-time generation of signals for testing the mobile, we have the 6621A, again with a number of different options, for everything from RF analysis to protocol logging, that will act as an eNB itself.

Slide 70: So, it's been a pretty quick tour through the downlink signalI hope you've been able to follow...of course the slides are available for review afterwards. But in summary, we've seen

just how dynamic the LTE signal is, and that's one of the facilities the VSA analysis brings for us now is to cope with that dynamic nature of the signal, so it recovers all the resource allocations to identify all different components throughout the frame, and on consecutive frames. We've seen

also how basic spectrum and time can give us a basic fast check on what's happening. And, all the other items on the slide here

show us just how much we can glean from the information that's presented on the downlink control channel, all the way down to the system information block, in point six.

Slide 71: So now, having presented that, I'd like to move over to the question-and-answer session.

31

CHRIS KEACH: Thank you, Peter. In a moment, we'll begin today's Q & A, but The survey should now be open

first, let's go over the survey. in a new window.

If you do not see the feedback form at this

time, please launch it by clicking on the survey button on the left-hand side of your screen. Atendees who fully complete and

submit the form are eligible to win a $75 Amazon.com gift certificate. The winner will be notified via e-mail. Now let's

proceed with our survey questions.

Our first question for you:

How often do you use the messaging content of the RF signal? Your answers here can be never, rarely, about 10% of the time, or often. Our second question for you: How often do Never,

you need to look at both the downlink and uplink? rarely, about 10% of the time, or often.

Our third

question for you: Are you most interested in the downlink or uplink? And your answers here can be d/l, u/l, both Our fourth question is And here

separately, or both, simultaneously.

a two-parter: Which processes are of most interest?

you would check all that apply: synchronization and connection, or network entry; handovers and higher layer functions; control loops, meaning timing, power, MCS, and HARQ; or sweep or idle modes, or other. And four-b, the second part of that

question, is, If it's an other, please specify what that is.

32

Our fifth question for you: How do you normally connect to the e-Node B and / or UE? Is it a cabled connection, radiated, or

an antenna connection, a general [all-fare?] with a faded channel? Just check the answer there that applies for you.

And then our sixth question for you: Are you interested in purchasing one of the following solutions: the SystemVue LTE Baseband Verification; the Signal Studio for FDD, the Signal Studio for TDD; the Signal Generator; the Spectrum Analyzer; the Signal Analysis software for FDD; or the Signal Analysis software for TDD. Our seventh question for you: What is your

time-frame for purchasing any of the products selected above: within the next three months, in four to twelve months, in thirteen to 24 months, over 24 months from now, or unknown. And our eighth and final question for you: Which of the following best describes the budget funding status for your test solution: is it approved, in process, plan to request, plan to rent or lease, don't know, or none. please press the Submit Now, to complete the form,

button at the bottom of the page. Your participation in

Thank you for filling out the survey.

this survey provides Agilent Technologies and EE Times with important information which helps us to improve future webcasts. And now on to the question-and-answer portion of our event. a reminder, if you have a question for our presenter, simply enter your question at this time in the text box on the leftAs

33

hand side, and then click the Submit button. many questions as possible today. our first question.

We'll get to as

Let's get started today with

And our first question for Peter is: Is Peter?

the transport block size measured in bits or bytes?

PETER CAIN: Thanks Chris. And so the answer to this, in the information we

present, is that it's measured in bits, and it was shown in one of the slides, as we recalled, it's something that's useful to help us figure out what the throughput will be. answer's in bits. So, the

CHRIS KEACH: Fantastic. And, our next question for you: In slides 25 and

26, what is the value of a, and why does it change?

PETER CAIN: So, the value a, or the letter a, stands for the payload length. As we mentioned, there's the possibility of confusing it with aggregation, but it's the payload length, and it varies according to the complexity of the DCI signal.

CHRIS KEACH:

34

OK, fantastic.

And, our next question for you: In another

slide, 23, what does 'very compact' mean?

PETER CAIN: OK, well, if I went to describe this in a lot of detail, we'd probably be here for quite some time, so I'm going to give a slightly shortened answer. referring to. So, this is the slide that we were

What it means in practice is that you can't do So, it's going to take up less space in

everything with it.

frequency and time, but as we see in the slide, it's not as capable in terms of the information that you send with it, so it's compact, or very compact, because it's not using much in the way of resource, but it's constrained by the information that can be sent it.

CHRIS KEACH: OK, and with that, What are the red items in slide 18?

PETER CAIN: Let's just go back to that slide. So, this is early on in the

presentation where we were looking at the information that's shown in the detected allocations. So again, this shows from

left to right the radio frame, and the information that's been recovered. The red information, the red items are actually the

35

HARQ.

That's where the HARQ information would be sent.

Now, in

fact, as it turns out, unlike the other information, because these locations are predetermined, we show those whether there's a transmission or not. And what we know is that you wouldn't be So, it's

able to transmit something else over the top of those.

the HARQ information, and they're a little bit special inasmuch as they have a fixed location.

CHRIS KEACH: All right, well thank you, Peter. And, our next question for

you: How can I relate the position of the raw symbols with the sub-carrier locations?

PETER CAIN: All right, this is a very good question, and something that I perhaps didn't bring out. I'm just going to see if I can find a

slide here that would help us understand this, because as we've seen, there are a variety of different ways that we can analyze the signal, whether it's in the physical or the decoded. this particular display perhaps doesn't show it directly. And, I'll

look for another one too, but what we're going to do is to use the markers. So if we have a display that lets us see the

physical part of the signal, and we apply a marker to that trace, if you take the situation where you've got a symbol trace

36

perhaps rather than a constellation as I've shown here, and you also apply a markerif you couple the markers, you can track the information between the two situations, so...very powerful tool in understanding just where something's going wrong. Typically,

with the data, it means that you'd need to be looking at the raw data rather than the encoded, but even so, a great way to move around the signal. A combination I use quite often is the

detected allocations, and symbol information, in order to make use of that facility.

CHRIS KEACH: All right, Peter, our next question for you then is, How can I try out this software?

PETER CAIN: OK, that's quite an easy one. In fact, what you do is you would You'll

go to the Agilent website, www.agilent.com/find/LTE.

find links to the VSA, and it's possible to download a version that has demonstration signals. You can run it in the

demonstration mode, you can see all the things that we've seen here with some examples of both coded and unencoded signals, and you'll be able to work through and understand just what it can show you doing that.

37

CHRIS KEACH: And our next question for you, Peter: What's the difference between a transport channel and a physical channel?

PETER CAIN: Well, in a simple way, what we can do is to say, it depends on which trace that you're using the VSA. If you're using the

symbols trace, it will show the physical channel, so that's the closest to the transmission and is where you'd start if you wanted to get to the bottom of CRC failures. The transport

channel is a more encoded version of that, and there is a trace that will also show that information described as the decoded symbols, and you can pick what you can show on that trace, in terms of whether it's the fully coded, or the descrambledthere's a variety of different levels that you can recover that. But it's a question of where in the stack you

are...so, depends where we are here in the different parts of the protocol stack...but also, when it comes to displaying the signal, it's a question of which trace we use, and what we want to identify. So, going back to one of the examples that we

use...this shows the differentthe physical and the transport information.

CHRIS KEACH:

38

OK, well thank you, Peter!

That looks like about all the time Peter, I want to get any quick

we have for questions for today.

final thoughts that you might have.

Slide 72: PETER CAIN: Well, I appreciate everybody's time in joining us today, and understand that the LTE signal is very complexI've only had the chance to scratch the surface, really, in describing it herehopefully that's helped. I've made some references here

that were in the slides, if you care to download themthey include references to a book, or even a video clip that we've created recently that shows, for example, in more detail, the recovery of the SIB. So, I hope this has proven useful and you And, I'd

can find ways to put the analysis software to use.

also like to thank Craig Grimley, a colleague here at Agilent, and others, in creating the material for the presentation.

Slides 73-76: CHRIS KEACH: All right, well thank you again Peter, and I'd like to thank everyone for attending today's event, How to verify the data in your LTE downlink signal, brought to you by Agilent Technologies and EE Times. This presentation will be available

39

shortly in an on-demand format.

You can also access this

presentation at any time for your review, by visiting EETimes.com's on-demand webcast page. You can also download a

PDF copy of the presentation slides from the on-demand interface. If you're viewing the archived version of the

seminar, and have a question about any of the material today, please contact today's presenter at the following e-mail address: that's Peter_Cain@agilent.com. I'd also like to remind Please

you to please fill out and submit your webcast survey.

click on the Survey button on the left-hand side of your interface to launch it if you've not submitted it already. Those who completely fill out and submit the feedback form are eligible to win a $75 Amazon.com gift certificate. Agilent will

be giving away two $75 Amazon.com gift certificates; one to a viewer of the live and event and one to a viewer of the archive. The winner will be notified via e-mail. copyright 2010 by EE Times. This webcast is

The presentation materials are

owned by or copyright by Agilent Technologies, which is solely responsible for their content. The individual speaker is solely For a current

responsible for his content and opinions.

schedule of live and on-demand events, please visit us at www.EETimes.com. I'm Chris Keach. Thank you for joining us,

and have a great day.

40

END OF AUDIO FILE

41