Thursday, February 24, 2011
Tuesday, February 22, 2011
Thursday, January 27, 2011
KASME derivation
If the UE moves to a different MME in a different PLMN, then new-MME is not expected to use the AV from the old-MME.
The SN-ID used for the KASME derivation contains the MCC and MNC, hence it is not possible to use the same security parameters.
Here is the KASME derivation.
The SN-ID used for the KASME derivation contains the MCC and MNC, hence it is not possible to use the same security parameters.
Here is the KASME derivation.
Tuesday, January 25, 2011
Thursday, December 16, 2010
Indirect Data Forwarding Tunnel.
* Indirect data forwarding is needed only in case there is no Userplane available between source eNB- Target eNB/Target-Rnc.
* Indirect tunnel is created between
Source eNB - Source SGW - Target SGW - Target eNB.
*Used for forwarding the buffered traffic from old-eNB, Here MME can select a new SGW to forward this traffic.
i.e Source eNB -- New SGW - Target SGW - Target eNB.
The New SGW being selected acts just a next-hop router.
* Indirect tunnel is created between
Source eNB - Source SGW - Target SGW - Target eNB.
*Used for forwarding the buffered traffic from old-eNB, Here MME can select a new SGW to forward this traffic.
i.e Source eNB -- New SGW - Target SGW - Target eNB.
The New SGW being selected acts just a next-hop router.
Tuesday, October 12, 2010
GTPv2 vs GTPv1 Header
There is no major difference between v1 and v2 header apart from introducing the new fields in v2 and the removal of Extension-header, Flags for Sequence number and N-PDU.
* Piggy backing Flag - When this flag is set in create session response then it means there is a create bearer request which is piggybacked in the same GTP message.
*Since GTPv2-C is designed for Control, there is no need to have a N-PDU which is required during Inter RAT RAU.
Hence strip that.
* TEID need not be present in the case of GTP Echo messages. So this is stripped in v2.
*Sequence number field is mandatory in V2.
* Piggy backing Flag - When this flag is set in create session response then it means there is a create bearer request which is piggybacked in the same GTP message.
*Since GTPv2-C is designed for Control, there is no need to have a N-PDU which is required during Inter RAT RAU.
Hence strip that.
* TEID need not be present in the case of GTP Echo messages. So this is stripped in v2.
*Sequence number field is mandatory in V2.
| + | Bit 0-2 | 3 | 4 | 5-7 | 8-15 | 16-23 | 24-31 | |||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | Version | Piggybacking flag (P) | TEID flag (T) | Spare | Message Type | Total length | ||||||||||||||||||||||||||
| 32 | TEID (only present if T=1) | |||||||||||||||||||||||||||||||
| 64 (32 if TEID not present) | Sequence number | Spare | ||||||||||||||||||||||||||||||
Saturday, September 18, 2010
MBR GBR APN-AMBR
Let me put my views on AMBR GBR UEAMBR APN-AMBR with an example.
Consider that we have two applications running in your UE. [Video call and an email client].
Two bearers one for a video call and one for email client.
Here we need the video call to be very interactive in the sense the delay has to be less.
So I cannot have the bearers to be the same. Need some way to distinguish.
For this purpose we are having the videocall bearer as a GBR bearer and the email client as Non-GBR.
MBR - > This is to restrict the traffic flow in a particular bearer. If the traffic exceeds this then it will be dropped.
Mostly in GBR bearers , MBR will be equal to GBR.
In GBR bearers the restrictions will be in a bearerwise. [i.e MBR].
There is no sharing of the bearer. If there are 2 GBR bearers, one is idle then the other GBR bearer cannot share this.
Here I want to make a note – Only a dedicated bearer can be a GBR bearer.
Non-GBR bearers:
All default-bearers will be Non-GBR bearer. Here sharing of the bearer bw is possible.
From this its clear this is a kind of group bearers.
Consider that I have a email client , a download application and browser is running using Non-GBR bearer1,bearer2 and bearer3.
Non-GBR bearer1 & 2 are using the apn APN1 and 3 using APN2.
As we are aware that we can restrict the traffic to max in Non-GBR bearer,
Is it possible to restrict the traffic based on APN ?
Yes we have APN-AMBR to restrict based on APN.
This can be applied in UE and PGW.
Sharing is possible in the sense, if the email application is not using the bw, the download application takes the max APN-AMBR to it.
Where is it mentioned? It is specified in HSS. It is sent in ULA for each APN.
Also available with PGW - Gx.
Yes, it is possible to restrict the traffic per UE wise, - using UE AMBR.
Where is it applied? In eNB
It is subscribed in HSS. Send in ULA. Intimated to eNB in initial context setup message.
Offcourse MME can stretch the UE-AMBR to the subscribed UE-AMBR. But usually there is no point to set the subscribed value If the sum of APN AMBRs are less than the subscribed one.
Hope this one clarifies.
NON GBR
/+++++++++++++++++++++++++++++++++++++++++
|______DEFAULT____APN1_______________________|
| APN-AMBR1
UEAMBR |__________________APN1_______________________|
|__________________APN2_______________________| APN-AMBR2
| DEDICATED |
/+++++++++++++++++++++++++++++++++++++++++
GBR | DEDICATED MBR | GBR
|+++++++++++++++++++++++++++++++++++++++++
Consider that we have two applications running in your UE. [Video call and an email client].
Two bearers one for a video call and one for email client.
Here we need the video call to be very interactive in the sense the delay has to be less.
So I cannot have the bearers to be the same. Need some way to distinguish.
For this purpose we are having the videocall bearer as a GBR bearer and the email client as Non-GBR.
MBR - > This is to restrict the traffic flow in a particular bearer. If the traffic exceeds this then it will be dropped.
Mostly in GBR bearers , MBR will be equal to GBR.
In GBR bearers the restrictions will be in a bearerwise. [i.e MBR].
There is no sharing of the bearer. If there are 2 GBR bearers, one is idle then the other GBR bearer cannot share this.
Here I want to make a note – Only a dedicated bearer can be a GBR bearer.
Non-GBR bearers:
All default-bearers will be Non-GBR bearer. Here sharing of the bearer bw is possible.
From this its clear this is a kind of group bearers.
Consider that I have a email client , a download application and browser is running using Non-GBR bearer1,bearer2 and bearer3.
Non-GBR bearer1 & 2 are using the apn APN1 and 3 using APN2.
As we are aware that we can restrict the traffic to max in Non-GBR bearer,
Is it possible to restrict the traffic based on APN ?
Yes we have APN-AMBR to restrict based on APN.
This can be applied in UE and PGW.
Sharing is possible in the sense, if the email application is not using the bw, the download application takes the max APN-AMBR to it.
Where is it mentioned? It is specified in HSS. It is sent in ULA for each APN.
Also available with PGW - Gx.
Yes, it is possible to restrict the traffic per UE wise, - using UE AMBR.
Where is it applied? In eNB
It is subscribed in HSS. Send in ULA. Intimated to eNB in initial context setup message.
Offcourse MME can stretch the UE-AMBR to the subscribed UE-AMBR. But usually there is no point to set the subscribed value If the sum of APN AMBRs are less than the subscribed one.
Hope this one clarifies.
NON GBR
/+++++++++++++++++++++++++++++++++++++++++
|______DEFAULT____APN1_______________________|
| APN-AMBR1
UEAMBR |__________________APN1_______________________|
|__________________APN2_______________________| APN-AMBR2
| DEDICATED |
/+++++++++++++++++++++++++++++++++++++++++
GBR | DEDICATED MBR | GBR
|+++++++++++++++++++++++++++++++++++++++++
Subscribe to:
Comments (Atom)