@vmp: what would I do without my QAEs ? Thank you

@Stefan: so, a certain UE can have any number of bearers? ..Let’s say that it is connected to 10 APNs, would it just be able to handle 110 bearers?

@Santosh: hey, thanks for the correction

@Rajeshwar: sry for the late reply, I was on vacation, no Internet access
So:
1. As far as I understand this, no, there is no need for a PCRF if I only do the UE attaching. Still, the PGW would try to find out rules about this UE when it attaches, so that it knows what policies to apply next: like, immediately after attach, the PGW may create dedicated bearers.
Also, according to TS 23.401, the only case where the PCRF is implicated in the attach procedure is in the case of IP-CAN Session Termination/Establishment. I am not so familiar with this IP-CAN thinggie, but it seems that many applications may require this PCRF verification in order for the PGW to have the OK to send an IP address to the UE.
So, in case we are talking about this type of implementations (which I believe should be the rule), the PCRF must exist, as it is the one ordering the PGW to send an IP to the UE or not to let it attach to the network.

2. Well, there are several ways…;the default bearer request is the first to come immediately after attach; there 4 messages exchanged here, from the MME to the SGW (and further on to the PGW): Create Session Request/Response (which attaches partially the network and allows uplink to be sent) and then Modify Bearer Request/Response – which actually creates the full bidirectional default bearer link;
in case of Multiple APN per UE, this works the same, just that the request is for a different APN (different APN string in the Create Session Request that reaches the PGW);

@Vijay: yep, I understand this way also. BUT: the UE won’t be able to create any dedicated bearer in this situation.

@Vijay: you are right at most 10 dedicated bearers per UE

@James: Firstly, a default bearer is a pair of information saved on the eNB, MME, SGW and PGW. At a certain moment in time, all the bearers, including the default one, may not be active – ECM-IDLE mode. When and how you can release a default bearer?

Let’s take the case when the UE is in ECM-CONNECTED, so all its bearers are up all the time:
In this case, “releasing” – if you mean by it “deleting” the default bearer, means detaching from that network-APN. The default bearer can be released when the user loses signal, implicitly; the user can also simple detach from 1 APN, while remaining attached (keeping the default bearers at least) for other APNs. When this happens (via one of the PDN detach procedures, the MME sets a certain flag in the Delete Session message: Operation flag = 1) – this tell the PGW that this UE is detaching from the network.

ECM-IDLE case:
When the UE moves to ECM-IDLE, the network receives another type of message: Release Access Bearer Request. This tells the network that the particular eNB where the UE was/is connected is going to delete all the information about that UE from its local resources. The network deletes the USER-PLANE TEIDs (bearer information for user-plane, for data traffic), regarding that UE.
In this case, if the UE intends to detach itself from the network, it must first exit idle state, return to an active state, and barely then delete the session. You may ask: how does the network know where the UE is at a certain moment in time? – as there is no more data, and the user may travel accross country while in Idle. True, but the UE still signals to the network its position (see Tracking Area Update procedure). This is very important as, if downlink data arrives at the SGW, it must awaken the UE before sending it traffic – the UE is moving from ECM-IDLE to ECM-CONNECTED (re-creating its data traffic bearers). Unless there was the TAU procedure, the SGW won’t know which MME (and further eNB) to signal to get hold of that UE. Even worse, the UE may move out of the coverage area of its current SGW – so the downlink packets may have to reach other SGW – that’s part of the role of the TAU procedure type MME relocation, SGW relocation.

@Donna: let me get back to you on that with a documented response.

@qiuhong: hmmm, I can’t remember precisely where I took this information from an year ago.

But, regarding what you say: TS 36.321 (at least Release 8 – which is now being implemented as 4G), section 6.2.1, there are 2 tables: Table 6.2.1-1 Values of LCID for DL-SCH and Table 6.2.1-2 Values of LCID for UL-SCH : both indicate the following range for the “Identity of the logical channel”: 00001-01010.

While TS 36.331, indeed clarifies: maxDRB INTEGER ::= 11 – Maximum number of Data Radio Bearers

There are 11 bearers available

@Nan: hey. First of all, thanks for the questions. I’ll try to answer them punctually, as far as I know

1. QoS parameters: are always separate. By separate, I mean there are separate IEs for them: GBRU/GBRD (Guaranteed Bit Rate Uplink/Downlink).
There can also be separate TFT (Traffic Flow Template) strings (which are basically Layer 3 – 4 Access Lists) for Uplink and for Downlink.

2. I’ve never seen, nor read any document that described negotiation as separate for Uplink and Downlink traffic. In my opinion, there is no reason this can’t be possible. I believe it is possible to negotiate these bearers separately. You just put, for example, GBRU = 0, and GBRD = 2000 in order to only negotiate values for the Downlink bearer. But then you will have to do more signaling overhead in order to also negotiate the Uplink.
I believe it’s good to just negotiate them both at the same time. (And don’t worry if you want to have separate TFTs, because you can aggregate and add more TFT strings on the same packet).

3. I would say the same as 2. above for the release aspect.

Thanks,

@Santosh: fair enough. It was just using the term “negotiation” for…establishment, or transmission.
Thank you for the attention

Hey.
The total number of bearers a UE can do at a time is 11. And all of them can be Default bearers.
Thanks,

Hey, Ritu

What is the question, more exactly? Why is it simpler to create a dedicated bearer in 4G than in 3G?
Answer may be: because the 4G designers tried to create a simpler design. Simpler is better, more scalable and safer.