 It's some little discussion about the GPRS support in Osmo-KomBB. The question about support was started when we have been doing some testing of Osmo-PCU or so on. And T-RexCon at the moment doesn't support anything related to GPRS. There is why we need GPRS support in Osmo-KomBB. Again, it's testing for... Sorry? Not sure. Oops. Yeah. Okay. It's a TTC testing of PCU and Osmo, blah, blah, blah. It can support researchers who is going to research GPRS. And it's a good feature for Osmo-KomBB, I think. My ideas are listed here. I imagine these like separate layer 2-3 application like mobile, which creates a new network interface, which you can see in the... Ifconfig comment and you can do any routing or filtering wherever you want. And yeah, it also should implement some RLC mark layers of GPRS and other protocol related stuff. And some parts are already in the master of Osmo-KomBB because we have GPRS decode utility there. And we can share them somehow in some library and so on. I don't think we will care about Calypso phones because it's too hard. And we are excited too much things are working differently in DSP, in this mode. And for now, I would like to focus on software-defined radio, physical interface, or even only on virtual interface. In any case, it will work via T-RxCon. And we have more or less flexible shader implemented. And channel coding is also was implemented, but not tested because no higher levels are there. And we can use, I think, GRJ-S-M transceiver because it supports JMSK modulation. Nothing special about GPRS. But for edge, some coding schemes require HPSK modulation, but Fyotr was going to work on it. At least, I think. It's not the high-priority task. It's just some ideas. And I have the following questions. For example, let's imagine we have one GPRS packet data related time slot, and on the BTS site, and as I understand multiple subscribers may use this time slot at the same time, correct? And how a single subscriber can distinguish between data for this subscriber or for other subscribers? You have in the Mac header, you have the TFI, the temporary flow identifier. So, basically, at the TBF establishment, the TBF has a separate number space for uplink and downlink TBFs, but this is now downlink from the phone point of view. So, the TFI is encoded, and based on the TFI, you can demultiplex. So, you can have, I think, in GPRS, you can have up to eight different TBFs sharing one PDCH. And the identifier, basically, you read every Mac header, you check the identifier, you discard everything. That's not for you, and you only filter based on that. Okay, that's clear. And what about transmission at which time I can transmit at which I cannot? How can I understand? May I transmit bursts at the moment or not? There's two different schemes. One is fixed allocation. The other is a dynamic allocation. In dynamic allocation, basically, you have the so-called uplink-stealing flag. So, basically, in every downlink message, then there is the USF is how it's called, the uplink-stealing flag, I think, is what it's called. And in there, we indicate the uplink TFI, which is permitted to transmit, I think, three frame numbers in advance or something like that. So, dynamically, in the downlink messages, the PCU tells the MS which uplink slots are permitted to use for which TBF. That's the dynamic allocation. And in fixed allocation, it's basically part of some, whatever, I think it's packet uplink assignment or some signalling message anyway on the RSC Mac layer. And that signalling message then preallocates you certain frames. But we don't do this in OSMO-VCU. So, for OSMO-VCU testing, that's not needed at least, but in real networks, you may encounter it. I think it's discouraged or even removed from more modern releases of the spec. So, dynamic, I think, is the most important. More flexible. So, if it has some positive, I don't know. If it's important for testing and the SMACON community, I can start working on it as soon as I finish. This is the interface because for now, this is a more important task. If anyone would like to join me, feel free. I found this a few weeks ago, Agilent Understanding General Packet Radio Service. It's 29 pages. It's published in 2001 and it's very concise and contains most of the answers to, I think, those questions. It's pretty, like I said, 29 pages. It's nice, compact information. Thank you. I will read it. Okay. Let me just quickly add some comments. I started to do some PCU tests in TTCN3 and for that I needed some support for TVF-related stuff and in layer one control already, and the two things that I added is one, basically, is this filter on the uplink, no, sorry, on the TFI. So, on the downlink frames, basically, the layer two can state to the layer one, which TFI is currently used and in the, at which time slots, of course, and on the uplink transmission, again, also, you can basically tell the layer one which USF it should transmit something. So, the layer one has a queue of pending frames and when a certain USF appears, it would transmit that and in addition, you also need a transmission of an uplink frame at a fixed frame number because there's some acknowledgments in the RSC MAC protocol where, basically, the downlink message tells you an exact frame number at which you need to send an acknowledgement and so also we can send a frame to the layer one from layer two perspective and say, well, add frame number one, two, three, four, five, six, seven, this must be transmitted and then the layer one will transmit it at a time. So, that's, I think, in a branch still, maybe, of TRXcon, but... Yeah, I think it's easy to implement any other ideas or should we finish? Thanks.