Friday, March 18, 2011
Friday, February 18, 2011
EPS Bearer - PART3
This article is about ARP,UE-AMBR and APN-AMBR QoS level parameters:
The ARP shall contain information about the priority level (scalar), the pre-emption capability (flag) and the pre-emption vulnerability (flag). The primary purpose of ARP is to decide whether a bearer establishment / modification request can be accepted or needs to be rejected due to resource limitations (typically available radio capacity for GBR bearers). The priority level information of the ARP is used for this decision to ensure that the request of the bearer with the higher priority level is preferred. In addition, the ARP can be used (e.g. by the eNodeB) to decide which bearer(s) to drop during exceptional resource limitations (e.g. at handover). The pre-emption capability information of the ARP defines whether a bearer with a lower ARP priority level should be dropped to free up the required resources. The pre-emption vulnerability information of the ARP defines whether a bearer is applicable for such dropping by a pre-emption capable bearer with a higher ARP priority value. Once successfully established, a bearer's ARP shall not have any impact on the bearer level packet forwarding treatment (e.g. scheduling and rate control). Such packet forwarding treatment should be solely determined by the other EPS bearer QoS parameters: QCI, GBR and MBR, and by the AMBR parameters. The ARP is not included within the EPS QoS Profile sent to the UE.
for e.g. Video telephony is one use case where it may be beneficial to use EPS bearers with different ARP values for the same UE. In this use case an operator could map voice to one bearer with a higher ARP, and video to another bearer with a lower ARP. In a congestion situation (e.g. cell edge) the eNB can then drop the "video bearer" without affecting the "voice bearer". This would improve service continuity.
Each APN access, by aUE, is associated with APN Aggregate Maximum Bit Rate (APN-AMBR).
The ARP shall contain information about the priority level (scalar), the pre-emption capability (flag) and the pre-emption vulnerability (flag). The primary purpose of ARP is to decide whether a bearer establishment / modification request can be accepted or needs to be rejected due to resource limitations (typically available radio capacity for GBR bearers). The priority level information of the ARP is used for this decision to ensure that the request of the bearer with the higher priority level is preferred. In addition, the ARP can be used (e.g. by the eNodeB) to decide which bearer(s) to drop during exceptional resource limitations (e.g. at handover). The pre-emption capability information of the ARP defines whether a bearer with a lower ARP priority level should be dropped to free up the required resources. The pre-emption vulnerability information of the ARP defines whether a bearer is applicable for such dropping by a pre-emption capable bearer with a higher ARP priority value. Once successfully established, a bearer's ARP shall not have any impact on the bearer level packet forwarding treatment (e.g. scheduling and rate control). Such packet forwarding treatment should be solely determined by the other EPS bearer QoS parameters: QCI, GBR and MBR, and by the AMBR parameters. The ARP is not included within the EPS QoS Profile sent to the UE.
for e.g. Video telephony is one use case where it may be beneficial to use EPS bearers with different ARP values for the same UE. In this use case an operator could map voice to one bearer with a higher ARP, and video to another bearer with a lower ARP. In a congestion situation (e.g. cell edge) the eNB can then drop the "video bearer" without affecting the "voice bearer". This would improve service continuity.
Each APN access, by aUE, is associated with APN Aggregate Maximum Bit Rate (APN-AMBR).
The APN‑AMBR is a subscription parameter stored per APN in the HSS. It limits the aggregate bit rate that can be expected to be provided across all Non‑GBR bearers and across all PDN connections of the same APN (e.g. excess traffic may get discarded by a rate shaping function). Each of those Non‑GBR bearers could potentially utilize the entire APN‑AMBR, e.g. when the other Non‑GBR bearers do not carry any traffic. GBR bearers are outside the scope of APN‑AMBR. The P‑GW enforces the APN‑AMBR in downlink. Enforcement of APN‑AMBR in uplink is done in the UE and additionally in the P‑GW.
Each UE in state EMM-REGISTERED is associated with UE Aggregate Maximum Bit Rate (UE-AMBR).The UE‑AMBR is limited by a subscription parameter stored in the HSS. The MME shall set the UE‑AMBR to the sum of the APN‑AMBR of all active APNs up to the value of the subscribed UE‑AMBR. The UE‑AMBR limits the aggregate bit rate that can be expected to be provided across all Non‑GBR bearers of a UE (e.g. excess traffic may get discarded by a rate shaping function). Each of those Non‑GBR bearers could potentially utilize the entire UE‑AMBR, e.g. when the other Non‑GBR bearers do not carry any traffic. GBR bearers are outside the scope of UE AMBR. The E‑UTRAN enforces the UE‑AMBR in uplink and downlink.
The GBR and MBR denote bit rates of traffic per bearer while UE-AMBR/APN-AMBR denote bit rates of traffic group of bearers.
The ARP parameter of the EPS bearer can be modified by the P‑GW (e.g. based on interaction with the PCRF) to assign the appropriate pre-emption capability and the pre-emption vulnerability setting.The ARP pre-emption vulnerability of the default bearer should be set appropriately to minimize the risk of unnecessary release of the default bearer.
The HSS defines, for each PDN subscription context, the 'EPS subscribed QoS profile' which contains the bearer level QoS parameter values for the default bearer (QCI and ARP) and the subscribed APN-AMBR value. The subscribed ARP shall be used to set the priority level of the EPS bearer parameter ARP for the default bearer while the pre-emption capability and the pre-emption vulnerability information for the default bearer are set based on MME operator policy. In addition, the subscribed ARP shall be applied by the P-GW for setting the ARP priority level of all dedicated EPS bearers of the same PDN connection unless a specific ARP priority level setting is required (due to P-GW configuration or interaction with the PCRF).
This is all about EPS Bearer and its QoS.
EPS Bearer - PART2
In this article we will discuss about Bearer Level QoS Parameters:
The EPS bearer QoS profile includes the parameters QCI, ARP, GBR and non-GBR. The QoS parameters which are applied to aggregated set of EPS bearers are APN-AMBR and UE-AMBR.
The QCI is scalar that is used as a reference to node specific parameters that control packet forwarding treatment ( e.g. scheduling weights, admission thresholds, queue management thresholds, link layer protocol configurations etc) and that have been pre-configured by the operator owning the node (e.g. eNodeB). The characterstics describe the packet forwarding treatment that an SDF aggregate receives edge-to-edge between UE and PCEF in terms of the following characteristics:
1. Resource Type (GBR and non-GBR)
2. Priority
3. Packet Delay Budget (PDB)
4. Packet Error Loss Rate (PELR)
The one-to-one mapping of standardized QCI values to a standardized characterstics is as below:
The Resource Type determines if dedicated network resources related to a service or bearer level Guaranteed Bit Rate (GBR) value are permanently allocated (e.g. by an admission control function in a radio base station). GBR SDF aggregates are therefore typically authorized "on demand" which requires dynamic policy and charging control. A Non GBR SDF aggregate may be pre-authorized through static policy and charging control.
The Packet Delay Budget (PDB) defines an upper bound for the time that a packet may be delayed between the UE and the PCEF. For a certain QCI the value of the PDB is the same in uplink and downlink. The purpose of the PDB is to support the configuration of scheduling and link layer functions (e.g. the setting of scheduling priority weights and HARQ target operating points).
Every QCI (GBR and Non-GBR) is associated with a Priority level. Priority level 1 is the highest Priority level. The Priority levels shall be used to differentiate between SDF aggregates of the same UE, and it shall also be used to differentiate between SDF aggregates from different UEs. Via its QCI an SDF aggregate is associated with a Priority level and a PDB. Scheduling between different SDF aggregates shall primarily be based on the PDB. If the target set by the PDB can no longer be met for one or more SDF aggregate(s) across all UEs that have sufficient radio channel quality then Priority shall be used as follows: in this case a scheduler shall meet the PDB of an SDF aggregate on Priority level N in preference to meeting the PDB of SDF aggregates on Priority level N+1 until the priority N SDF aggregate's GBR (in case of a GBR SDF aggregate) has been satisfied.
The Packet Error Loss Rate (PELR) defines an upper bound for the rate of SDUs (e.g. IP packets) that have been processed by the sender of a link layer protocol (e.g. RLC in E‑UTRAN) but that are not successfully delivered by the corresponding receiver to the upper layer (e.g. PDCP in E‑UTRAN). Thus, the PELR defines an upper bound for a rate of non congestion related packet losses. The purpose of the PELR is to allow for appropriate link layer protocol configurations (e.g. RLC and HARQ in E‑UTRAN). For a certain QCI the value of the PELR is the same in uplink and downlink.
continues..
The EPS bearer QoS profile includes the parameters QCI, ARP, GBR and non-GBR. The QoS parameters which are applied to aggregated set of EPS bearers are APN-AMBR and UE-AMBR.
The QCI is scalar that is used as a reference to node specific parameters that control packet forwarding treatment ( e.g. scheduling weights, admission thresholds, queue management thresholds, link layer protocol configurations etc) and that have been pre-configured by the operator owning the node (e.g. eNodeB). The characterstics describe the packet forwarding treatment that an SDF aggregate receives edge-to-edge between UE and PCEF in terms of the following characteristics:
1. Resource Type (GBR and non-GBR)
2. Priority
3. Packet Delay Budget (PDB)
4. Packet Error Loss Rate (PELR)
The one-to-one mapping of standardized QCI values to a standardized characterstics is as below:
The Resource Type determines if dedicated network resources related to a service or bearer level Guaranteed Bit Rate (GBR) value are permanently allocated (e.g. by an admission control function in a radio base station). GBR SDF aggregates are therefore typically authorized "on demand" which requires dynamic policy and charging control. A Non GBR SDF aggregate may be pre-authorized through static policy and charging control.
The Packet Delay Budget (PDB) defines an upper bound for the time that a packet may be delayed between the UE and the PCEF. For a certain QCI the value of the PDB is the same in uplink and downlink. The purpose of the PDB is to support the configuration of scheduling and link layer functions (e.g. the setting of scheduling priority weights and HARQ target operating points).
Every QCI (GBR and Non-GBR) is associated with a Priority level. Priority level 1 is the highest Priority level. The Priority levels shall be used to differentiate between SDF aggregates of the same UE, and it shall also be used to differentiate between SDF aggregates from different UEs. Via its QCI an SDF aggregate is associated with a Priority level and a PDB. Scheduling between different SDF aggregates shall primarily be based on the PDB. If the target set by the PDB can no longer be met for one or more SDF aggregate(s) across all UEs that have sufficient radio channel quality then Priority shall be used as follows: in this case a scheduler shall meet the PDB of an SDF aggregate on Priority level N in preference to meeting the PDB of SDF aggregates on Priority level N+1 until the priority N SDF aggregate's GBR (in case of a GBR SDF aggregate) has been satisfied.
The Packet Error Loss Rate (PELR) defines an upper bound for the rate of SDUs (e.g. IP packets) that have been processed by the sender of a link layer protocol (e.g. RLC in E‑UTRAN) but that are not successfully delivered by the corresponding receiver to the upper layer (e.g. PDCP in E‑UTRAN). Thus, the PELR defines an upper bound for a rate of non congestion related packet losses. The purpose of the PELR is to allow for appropriate link layer protocol configurations (e.g. RLC and HARQ in E‑UTRAN). For a certain QCI the value of the PELR is the same in uplink and downlink.
continues..
Thursday, February 17, 2011
EPS Bearer - PART1
Before knowing EPS Bearer we need to know about the PDN connectivity service. The PDN connectivity service is nothing but the Evolved Packet System provides IP conectivity between a UE and PLMN external packet data network. The PDN Connectivity Service supports the traffic flow aggregate(s), consisting of one ore more Service Dara Flows (SDFs).
Now coming to EPS Bearer,
An EPS bearer is the level of granularity for bearer level QoS control in the EPC/E-UTRAN. That is, all traffic mapped to the same EPS bearer receive the same bearer level packet forwarding treatment (e.g. Scheduling Policy, Queue Management Policy, Rate Shaping Policy, RLC Configuration etc). Providing different bearer level packet forwarding treatment requires seperate EPS bearers.
One EPS bearer is established when the UE connects to a PDN, and that remains established throughout the lifetime of the PDN connection to provide the UE with always-on IP connectivity to that PDN. That bearer is referred to as the default bearer. Any additional EPS bearer that is established for the same PDN connection is referred to as a dedicated bearer.
Every dedicated bearer is associated with a TFT. A unidirectional EPS bearer is either associated with an UL TFT or a DL TFT that matches the unidirectional traffic flows and a DL TFT or an UL TFT in the other direction that blocks all traffic flows.
Now coming to EPS Bearer,
An EPS bearer is the level of granularity for bearer level QoS control in the EPC/E-UTRAN. That is, all traffic mapped to the same EPS bearer receive the same bearer level packet forwarding treatment (e.g. Scheduling Policy, Queue Management Policy, Rate Shaping Policy, RLC Configuration etc). Providing different bearer level packet forwarding treatment requires seperate EPS bearers.
One EPS bearer is established when the UE connects to a PDN, and that remains established throughout the lifetime of the PDN connection to provide the UE with always-on IP connectivity to that PDN. That bearer is referred to as the default bearer. Any additional EPS bearer that is established for the same PDN connection is referred to as a dedicated bearer.
Every dedicated bearer is associated with a TFT. A unidirectional EPS bearer is either associated with an UL TFT or a DL TFT that matches the unidirectional traffic flows and a DL TFT or an UL TFT in the other direction that blocks all traffic flows.
For of E-UTRAN, the decision to establish or modify a dedicated bearer can only be taken by the EPC, and the bearer level QoS parameter values are always assigned by the EPC. Therefore, the MME shall not modify the bearer level QoS parameter values received on the S11 reference point during establishment or modification of a dedicated bearer. Instead, the MME shall only transparently forwards those values to the E-UTRAN. Consequently, "QoS negotiation" between the E-UTRAN and the EPC during dedicated bearer establishment / modification is not supported. The MME may, however, reject the establishment or modification of a dedicated bearer (e.g. if the bearer level QoS parameter values sent by the PCEF over a GTP based S8 roaming interface do not comply with a roaming agreement).
The distinction between default and dedicated bearers should be transparent to the access network (e.g. E-UTRAN). An EPS bearer is referred to as a GBR bearer if dedicated network resources related to a Guaranteed Bit Rate (GBR) value that is associated with the EPS bearer are permanently allocated (e.g. by an admission control function in the eNodeB) at bearer establishment/modification. Otherwise, an EPS bearer is referred to as a Non-GBR bearer.
A dedicated bearer can either be a GBR or a Non-GBR bearer. A default bearer shall be a Non-GBR bearer.
Wednesday, February 16, 2011
Definition of EPS Connection Management states
ECM-IDLE
A UE is in ECM-IDLE state when no NAS signalling connection between UE and network exists. In ECM-IDLE state, a UE performs cell selection/reselection and PLMN selection.
There exists no UE context in E-UTRAN for the UE in the ECM-IDLE state. There is no S1_MME and no S1_U connection for the UE in the ECM-IDLE state.
In the EMM-REGISTERED and ECM-IDLE state, the UE shall:
- perform a tracking area update if the current TA is not in the list of TAs that the UE has received from the network in order to maintain the registration and enable the MME to page the UE;
- perform the periodic tracking area updating procedure to notify the EPC that the UE is available;
- perform a tracking area update if the RRC connection was released with release cause "load balancing TAU required";
- perform a tracking area update when the UE reselects an E-UTRAN cell and the UE's TIN indicates "P-TMSI";
- perform a tracking area update for a change of the UE's Core Network Capability information or the UE specific DRX parameter;
- perform a tracking area update when the UE manually selects a CSG cell, and the CSG ID of that cell is absent from both the UE's Allowed CSG list and the UE's Operator CSG list;
- answer to paging from the MME by performing a service request procedure;
- perform the service request procedure in order to establish the radio bearers when uplink user data is to be sent.
The UE and the MME shall enter the ECM-CONNECTED state when the signalling connection is established between the UE and the MME. Initial NAS messages that initiate a transition from ECM-IDLE to ECM-CONNECTED state are Attach Request, Tracking Area Update Request, Service Request or Detach Request.
When the UE is in ECM IDLE state, the UE and the network may be unsynchronized, i.e. the UE and the network may have different sets of established EPS bearers. When the UE and the MME enter the ECM CONNECTED state, the set of EPS Bearers is synchronized between the UE and network
ECM-CONNECTED
The UE location is known in the MME with an accuracy of a serving eNodeB ID. The mobility of UE is handled by the handover procedure.
The UE performs the tracking area update procedure when the TAI in the EMM system information is not in the list of TA's that the UE registered with the network, or when the UE handovers to an E UTRAN cell and the UE's TIN indicates "P-TMSI".
For a UE in the ECM-CONNECTED state, there exists a signalling connection between the UE and the MME. The signalling connection is made up of two parts: an RRC connection and an S1_MME connection.
The UE shall enter the ECM-IDLE state when its signalling connection to the MME has been released or broken. This release or failure is explicitly indicated by the eNodeB to the UE or detected by the UE.
The S1 release procedure changes the state at both UE and MME from ECM-CONNECTED to ECM-IDLE.
NOTE 1: The UE may not receive the indication for the S1 release, e.g. due to radio link error or out of coverage. In this case, there can be temporal mismatch between the ECM-state in the UE and the ECM-state in the MME.
After a signalling procedure, the MME may decide to release the signalling connection to the UE, after which the state at both the UE and the MME is changed to ECM-IDLE.
NOTE 2: There are some abnormal cases where the UE transitions to ECM-IDLE.
When a UE changes to ECM CONNECTED state and if a radio bearer cannot be established, or the UE cannot maintain a bearer in the ECM-CONNECTED state during handovers, the corresponding EPS bearer is deactivated
A UE is in ECM-IDLE state when no NAS signalling connection between UE and network exists. In ECM-IDLE state, a UE performs cell selection/reselection and PLMN selection.
There exists no UE context in E-UTRAN for the UE in the ECM-IDLE state. There is no S1_MME and no S1_U connection for the UE in the ECM-IDLE state.
In the EMM-REGISTERED and ECM-IDLE state, the UE shall:
- perform a tracking area update if the current TA is not in the list of TAs that the UE has received from the network in order to maintain the registration and enable the MME to page the UE;
- perform the periodic tracking area updating procedure to notify the EPC that the UE is available;
- perform a tracking area update if the RRC connection was released with release cause "load balancing TAU required";
- perform a tracking area update when the UE reselects an E-UTRAN cell and the UE's TIN indicates "P-TMSI";
- perform a tracking area update for a change of the UE's Core Network Capability information or the UE specific DRX parameter;
- perform a tracking area update when the UE manually selects a CSG cell, and the CSG ID of that cell is absent from both the UE's Allowed CSG list and the UE's Operator CSG list;
- answer to paging from the MME by performing a service request procedure;
- perform the service request procedure in order to establish the radio bearers when uplink user data is to be sent.
The UE and the MME shall enter the ECM-CONNECTED state when the signalling connection is established between the UE and the MME. Initial NAS messages that initiate a transition from ECM-IDLE to ECM-CONNECTED state are Attach Request, Tracking Area Update Request, Service Request or Detach Request.
When the UE is in ECM IDLE state, the UE and the network may be unsynchronized, i.e. the UE and the network may have different sets of established EPS bearers. When the UE and the MME enter the ECM CONNECTED state, the set of EPS Bearers is synchronized between the UE and network
ECM-CONNECTED
The UE location is known in the MME with an accuracy of a serving eNodeB ID. The mobility of UE is handled by the handover procedure.
The UE performs the tracking area update procedure when the TAI in the EMM system information is not in the list of TA's that the UE registered with the network, or when the UE handovers to an E UTRAN cell and the UE's TIN indicates "P-TMSI".
For a UE in the ECM-CONNECTED state, there exists a signalling connection between the UE and the MME. The signalling connection is made up of two parts: an RRC connection and an S1_MME connection.
The UE shall enter the ECM-IDLE state when its signalling connection to the MME has been released or broken. This release or failure is explicitly indicated by the eNodeB to the UE or detected by the UE.
The S1 release procedure changes the state at both UE and MME from ECM-CONNECTED to ECM-IDLE.
NOTE 1: The UE may not receive the indication for the S1 release, e.g. due to radio link error or out of coverage. In this case, there can be temporal mismatch between the ECM-state in the UE and the ECM-state in the MME.
After a signalling procedure, the MME may decide to release the signalling connection to the UE, after which the state at both the UE and the MME is changed to ECM-IDLE.
NOTE 2: There are some abnormal cases where the UE transitions to ECM-IDLE.
When a UE changes to ECM CONNECTED state and if a radio bearer cannot be established, or the UE cannot maintain a bearer in the ECM-CONNECTED state during handovers, the corresponding EPS bearer is deactivated
Definition of main EPS Mobility Management states
EMM-DEREGISTERED
In the EMM DEREGISTERED state, the EMM context in MME holds no valid location or routing information for the UE. The UE is not reachable by a MME, as the UE location is not known.
In the EMM-DEREGISTERED state, some UE context can still be stored in the UE and MME, e.g. to avoid running an AKA procedure during every Attach procedure.
During the successful Inter-RAT TAU/RAU/handover procedure and ISR activated is not indicated to the UE, the old S4 SGSN/old MME changes the EMM state of the UE to GPRS-IDLE/PMM-DETACHED/EMM-DEREGISTERED
EMM-REGISTERED
The UE enters the EMM-REGISTERED state by a successful registration with an Attach procedure to either E-UTRAN or GERAN/UTRAN. The MME enters the EMM-REGISTERED state by a successful Tracking Area Update procedure for a UE selecting an E-UTRAN cell from GERAN/UTRAN or by an Attach procedure via E-UTRAN. In the EMM-REGISTERED state, the UE can receive services that require registration in the EPS.
NOTE: The UE employs a single combined state machine for EMM and GMM states.
The UE location is known in the MME to at least an accuracy of the tracking area list allocated to that UE (excluding some abnormal cases).
In the EMM-REGISTERED state, the UE shall:
- always have at least one active PDN connection;
- setup the EPS security context.
After performing the Detach procedure, the state is changed to EMM-DEREGISTERED in the UE and in the MME. Upon receiving the TAU Reject and Attach Reject messages the actions of the UE and MME depend upon the 'cause value' in the reject message, but, in many cases the state is changed to EMM-DEREGISTERED in the UE and in the MME.
If all the bearers belonging to a UE are released (e.g., after handover from E UTRAN to non-3GPP access), the MME shall change the MM state of the UE to EMM-DEREGISTERED. If the UE camps on E-UTRAN and the UE detects that all of its bearers are released, the UE shall change the MM state to EMM-DEREGISTERED. If all the bearers (PDP contexts) belonging to a UE are released, while the UE camps on GERAN/UTRAN, the UE shall deactivate ISR by setting its TIN to "P-TMSI". This ensures that the UE performs Tracking Area Update when it re-selects E-UTRAN. If the UE switches off its E UTRAN interface when performing handover to non-3GPP access, the UE shall automatically change its MM state to EMM-DEREGISTERED.
The MME may perform an implicit detach any time after the Implicit Detach timer expires. The state is changed to EMM-DEREGISTERED in the MME after performing the implicit detach
In the EMM DEREGISTERED state, the EMM context in MME holds no valid location or routing information for the UE. The UE is not reachable by a MME, as the UE location is not known.
In the EMM-DEREGISTERED state, some UE context can still be stored in the UE and MME, e.g. to avoid running an AKA procedure during every Attach procedure.
During the successful Inter-RAT TAU/RAU/handover procedure and ISR activated is not indicated to the UE, the old S4 SGSN/old MME changes the EMM state of the UE to GPRS-IDLE/PMM-DETACHED/EMM-DEREGISTERED
EMM-REGISTERED
The UE enters the EMM-REGISTERED state by a successful registration with an Attach procedure to either E-UTRAN or GERAN/UTRAN. The MME enters the EMM-REGISTERED state by a successful Tracking Area Update procedure for a UE selecting an E-UTRAN cell from GERAN/UTRAN or by an Attach procedure via E-UTRAN. In the EMM-REGISTERED state, the UE can receive services that require registration in the EPS.
NOTE: The UE employs a single combined state machine for EMM and GMM states.
The UE location is known in the MME to at least an accuracy of the tracking area list allocated to that UE (excluding some abnormal cases).
In the EMM-REGISTERED state, the UE shall:
- always have at least one active PDN connection;
- setup the EPS security context.
After performing the Detach procedure, the state is changed to EMM-DEREGISTERED in the UE and in the MME. Upon receiving the TAU Reject and Attach Reject messages the actions of the UE and MME depend upon the 'cause value' in the reject message, but, in many cases the state is changed to EMM-DEREGISTERED in the UE and in the MME.
If all the bearers belonging to a UE are released (e.g., after handover from E UTRAN to non-3GPP access), the MME shall change the MM state of the UE to EMM-DEREGISTERED. If the UE camps on E-UTRAN and the UE detects that all of its bearers are released, the UE shall change the MM state to EMM-DEREGISTERED. If all the bearers (PDP contexts) belonging to a UE are released, while the UE camps on GERAN/UTRAN, the UE shall deactivate ISR by setting its TIN to "P-TMSI". This ensures that the UE performs Tracking Area Update when it re-selects E-UTRAN. If the UE switches off its E UTRAN interface when performing handover to non-3GPP access, the UE shall automatically change its MM state to EMM-DEREGISTERED.
The MME may perform an implicit detach any time after the Implicit Detach timer expires. The state is changed to EMM-DEREGISTERED in the MME after performing the implicit detach
Monday, February 14, 2011
Common requirements for Home NodeB/eNodeB - PART2
Closed Subscriber Group
- The CSG manager shall be able, under the operator supervision, to add, remove and view CSG membership
NOTE: the interaction of the user with the application that manages the Allowed CSG Lists is out of scope of 3GPP (e.g. Web interface).
- The UE shall contain a list of allowed CSG identities (Allowed CSG List). It shall be possible to store the Allowed CSG List in the USIM. When available, the list on the USIM shall be used. It shall be possible for both, the operator and the UE, to modify the Allowed CSG List.
- The UE shall allow the user to introduce new CSGs to the Allowed CSG List by means of manual CSG selection only.
- The UE shall maintain an operator controlled list of allowed CSG identities (Operator CSG list). It shall be possible to store the Operator CSG list in the USIM. When available, the list on the USIM shall be used. It shall be possible for the operator to modify the Operator CSG List.
- The two lists are maintained independently from each other. A change in the Operator CSG list shall not trigger the UE to modify the Allowed CSG list to reflect such change automatically.
- All CSG cells belonging to a CSG identity not included in the Allowed CSG List or Operator CSG list shall be considered not suitable by the UE.
- Each CSG identity shall be associated to a subscriber group which identifies the subscribers allowed to access the CSG.
- When the subscriber group is updated, the affected UE shall be informed accordingly.
- For temporary members, it shall be possible to limit the period of time during which the subscriber is considered a member of a CSG (granted access rights). It shall be possible to configure a time period for each temporary member.
- The time period shall be configurable by the CSG manager and/or the operator operating the CSG and shall span from 1 decihour to several days. Unlimited membership to the CSG is allowed.
- When a CSG is no longer considered available to provide services, except for emergency calls (i.e. due to time period expiry or removal of the CSG membership), it shall be possible to continue the established communication in another cell not belonging to this CSG.
- In hybrid access mode when services cannot be provided to a CSG member due to a shortage of H(e)NB resources it shall be possible to continue the established communication of non-CSG members in another cell.
- In hybrid access mode, to minimise the impact on CSG members from established communication of non-CSG members, it shall be possible for the network to allow the data rate of established PS communication of non-CSG members to be reduced.
- The CSG manager shall be able, under the operator supervision, to add, remove and view CSG membership
NOTE: the interaction of the user with the application that manages the Allowed CSG Lists is out of scope of 3GPP (e.g. Web interface).
- The UE shall contain a list of allowed CSG identities (Allowed CSG List). It shall be possible to store the Allowed CSG List in the USIM. When available, the list on the USIM shall be used. It shall be possible for both, the operator and the UE, to modify the Allowed CSG List.
- The UE shall allow the user to introduce new CSGs to the Allowed CSG List by means of manual CSG selection only.
- The UE shall maintain an operator controlled list of allowed CSG identities (Operator CSG list). It shall be possible to store the Operator CSG list in the USIM. When available, the list on the USIM shall be used. It shall be possible for the operator to modify the Operator CSG List.
- The two lists are maintained independently from each other. A change in the Operator CSG list shall not trigger the UE to modify the Allowed CSG list to reflect such change automatically.
- All CSG cells belonging to a CSG identity not included in the Allowed CSG List or Operator CSG list shall be considered not suitable by the UE.
- Each CSG identity shall be associated to a subscriber group which identifies the subscribers allowed to access the CSG.
- When the subscriber group is updated, the affected UE shall be informed accordingly.
- For temporary members, it shall be possible to limit the period of time during which the subscriber is considered a member of a CSG (granted access rights). It shall be possible to configure a time period for each temporary member.
- The time period shall be configurable by the CSG manager and/or the operator operating the CSG and shall span from 1 decihour to several days. Unlimited membership to the CSG is allowed.
- When a CSG is no longer considered available to provide services, except for emergency calls (i.e. due to time period expiry or removal of the CSG membership), it shall be possible to continue the established communication in another cell not belonging to this CSG.
- In hybrid access mode when services cannot be provided to a CSG member due to a shortage of H(e)NB resources it shall be possible to continue the established communication of non-CSG members in another cell.
- In hybrid access mode, to minimise the impact on CSG members from established communication of non-CSG members, it shall be possible for the network to allow the data rate of established PS communication of non-CSG members to be reduced.
Common requirements for Home NodeB /eNodeB - PART1
HNB and HeNB Installation, identification and location requirements
H(e)NB shall have a unique equipment identity.
- All the H(e)NBs serving the same CSG share the same unique (within the PLMN) identity called CSG Identity.
- It shall be possible to support at least 125 million CSG Identities within a PLMN of an operator.
- The radio transmitter of a H(e)NB shall not be activated until configured and authorised by the operator.
- When installing, provisioning, configuring or re-configuring an H(e)NB the operator shall be able to:
- verify the H(e)NB's identity.
- obtain the geographical location of the H(e)NB.
- The operator shall be able to determine that the H(e)NB is installed and operated in accordance with all relevant regulatory requirements.
- The operator shall be able to configure the settings of the H(e)NB. In the case where the H(e)NB has detrimental impact on the spectrum usage, the H(e)NB can be set to out-of-service by the operator.
- Installation and activation of a new H(e)NB shall require no reconfiguration of the operators network.
- The impact of H(e)NB on the core network should be minimised.
OA&M Requirements
- H(e)NB shall support the automatic discovery of an operator’s management platform.
- It shall be possible to make use of the operator’s management platform to carry out OA&M functions for H(e)NB. The management connection between H(e)NB and the operator's management platform shall be end-to-end secure.
- H(e)NB shall support OA&M procedures which allow the operator to remotely configure the H(e)NB, deploy software upgrades, detect and report changes in RF conditions and perform general OA&M tasks. The OA&M procedures shall be as closely aligned as possible with those that are commonly used in broadband access networks such as defined in TR-069 Amendment 2.
- If the connection between H(e)NB and the rest of the operator network is out of service, then it shall be possible within an operator’s defined time period for the H(e)NB to deactivate the air-interface
Access Control Requirements
Subject to operator and H(e)NB Hosting Party agreement, the operator shall be able to configure the H(e)NB with open, hybrid or closed access mode.
- When the H(e)NB is configured for open access mode, it shall be possible for the H(e)NB to provide services to subscribers of any PLMN, subject to roaming agreement.
- When the H(e)NB is configured for hybrid access mode, it shall be possible for the H(e)NB to provide services to:
- its associated CSG members, and
- subscribers of any PLMN not belonging to its associated CSG, subject to roaming agreement.
- When the H(e)NB is configured for closed access mode, only users that belong to its associated CSG shall be able to obtain services.
- CSG members may include subscriber of any PLMN subject to roaming agreement
Continues in PART2...
H(e)NB shall have a unique equipment identity.
- All the H(e)NBs serving the same CSG share the same unique (within the PLMN) identity called CSG Identity.
- It shall be possible to support at least 125 million CSG Identities within a PLMN of an operator.
- The radio transmitter of a H(e)NB shall not be activated until configured and authorised by the operator.
- When installing, provisioning, configuring or re-configuring an H(e)NB the operator shall be able to:
- verify the H(e)NB's identity.
- obtain the geographical location of the H(e)NB.
- The operator shall be able to determine that the H(e)NB is installed and operated in accordance with all relevant regulatory requirements.
- The operator shall be able to configure the settings of the H(e)NB. In the case where the H(e)NB has detrimental impact on the spectrum usage, the H(e)NB can be set to out-of-service by the operator.
- Installation and activation of a new H(e)NB shall require no reconfiguration of the operators network.
- The impact of H(e)NB on the core network should be minimised.
OA&M Requirements
- H(e)NB shall support the automatic discovery of an operator’s management platform.
- It shall be possible to make use of the operator’s management platform to carry out OA&M functions for H(e)NB. The management connection between H(e)NB and the operator's management platform shall be end-to-end secure.
- H(e)NB shall support OA&M procedures which allow the operator to remotely configure the H(e)NB, deploy software upgrades, detect and report changes in RF conditions and perform general OA&M tasks. The OA&M procedures shall be as closely aligned as possible with those that are commonly used in broadband access networks such as defined in TR-069 Amendment 2.
- If the connection between H(e)NB and the rest of the operator network is out of service, then it shall be possible within an operator’s defined time period for the H(e)NB to deactivate the air-interface
Access Control Requirements
Subject to operator and H(e)NB Hosting Party agreement, the operator shall be able to configure the H(e)NB with open, hybrid or closed access mode.
- When the H(e)NB is configured for open access mode, it shall be possible for the H(e)NB to provide services to subscribers of any PLMN, subject to roaming agreement.
- When the H(e)NB is configured for hybrid access mode, it shall be possible for the H(e)NB to provide services to:
- its associated CSG members, and
- subscribers of any PLMN not belonging to its associated CSG, subject to roaming agreement.
- When the H(e)NB is configured for closed access mode, only users that belong to its associated CSG shall be able to obtain services.
- CSG members may include subscriber of any PLMN subject to roaming agreement
Continues in PART2...
RACH Procedure in LTE - PART1
The random access procedure is characterized by:
- Common procedure for FDD and TDD;
- One procedure irrespective of cell size and number serving cells when CA is configured;
The random access procedure is performed for the following six events:
- Initial access from RRC_IDLE;
- RRC Connection Re-establishment procedure;
- Handover;
- DL data arrival during RRC_CONNECTED requiring random access procedure;
- E.g. when UL synchronisation status is “non-synchronised”;
- UL data arrival during RRC_CONNECTED requiring random access procedure;
- E.g. when UL synchronisation status is "non-synchronised" or there are no PUCCH resources for SR available.
- For positioning purpose during RRC_CONNECTED requiring random access procedure;
- E.g. when timing advance is needed for UE positioning;
Furthermore, the random access procedure takes two distinct forms:
- Contention based (applicable to first five events);
- Non-contention based (applicable to only handover, DL data arrival and positioning).
Normal DL/UL transmission can take place after the random access procedure
- Common procedure for FDD and TDD;
- One procedure irrespective of cell size and number serving cells when CA is configured;
The random access procedure is performed for the following six events:
- Initial access from RRC_IDLE;
- RRC Connection Re-establishment procedure;
- Handover;
- DL data arrival during RRC_CONNECTED requiring random access procedure;
- E.g. when UL synchronisation status is “non-synchronised”;
- UL data arrival during RRC_CONNECTED requiring random access procedure;
- E.g. when UL synchronisation status is "non-synchronised" or there are no PUCCH resources for SR available.
- For positioning purpose during RRC_CONNECTED requiring random access procedure;
- E.g. when timing advance is needed for UE positioning;
Furthermore, the random access procedure takes two distinct forms:
- Contention based (applicable to first five events);
- Non-contention based (applicable to only handover, DL data arrival and positioning).
Normal DL/UL transmission can take place after the random access procedure
HeNB Support
This version of the specification does not support X2 connectivity of HeNBs.
The S1 interface is defined as the interface:
- Between the HeNB GW and the Core Network.
- Between the HeNB and the HeNB GW.
- Between the HeNB and the Core Network.
- Between the eNB and the Core Network.
The HeNB GW appears to the MME as an eNB. The HeNB GW appears to the HeNB as an MME. The S1 interface between the HeNB and the EPC is the same whether the HeNB is connected to the EPC via a HeNB GW or not.
The HeNB GW shall connect to the EPC in a way that inbound and outbound mobility to cells served by the HeNB GW shall not necessarily require inter MME handovers. One HeNB serves only one cell.
The functions supported by the HeNB shall be the same as those supported by an eNB (with the possible exception of NNSF) and the procedures run between a HeNB and the EPC shall be the same as those between an eNB and the EPC
Functional Split
- Discovery of a suitable Serving HeNB GW.
- A HeNB shall only connect to a single HeNB GW at one time, namely no S1 Flex function shall be used at the HeNB.
- The HeNB will not simultaneously connect to another HeNB GW, or another MME.
- The TAC and PLMN ID used by the HeNB shall also be supported by the HeNB GW.
- Selection of an MME at UE attachment is hosted by the HeNB GW instead of the HeNB;
- HeNBs may be deployed without network planning. A HeNB may be moved from one geographical area to another and therefore it may need to connect to different HeNB GWs depending on its location.
The HeNB GW hosts the following functions
- Relaying UE-associated S1 application part messages between the MME serving the UE and the HeNB serving the UE.
- Terminating non-UE associated S1 application part procedures towards the HeNB and towards the MME. Note that when a HeNB GW is deployed, non-UE associated procedures shall be run between HeNBs and the HeNB GW and between the HeNB GW and the MME.
- Optionally terminating S1-U interface with the HeNB and with the S-GW.
- Supporting TAC and PLMN ID used by the HeNB.
- X2 interfaces shall not be established between the HeNB GW and other nodes.
A list of CSG IDs may be included in the PAGING message. If included, the HeNB GW may use the list of CSG IDs for paging optimization.
MME hosts the following functions
- Access control for UEs that are members of Closed Subscriber Groups (CSG):
- In case of handovers to CSG cells, access control is based on the target CSG ID provided to the MME by the serving E-UTRAN.
- Membership Verification for UEs handing over to hybrid cells
- In case of handovers to hybrid cells Membership Verification is triggered by the presence of the Cell Access Mode and it is based on the target CSG ID provided to the MME by the serving E-UTRAN.
- CSG membership status signalling to the target E-UTRAN in case of attachment/handover to hybrid cells and in case of the change of membership status when a UE is served by a CSG cell or a hybrid cell.
- Supervising the eNB action after the change in the membership status of a UE.
- Routing of handover messages towards HeNB GWs based on the TAI contained in the handover message.
Reference : 3GPP TS 36.300
Subscribe to:
Posts (Atom)