|
When PCRF
sends a new PRA ID different than the initial call setup.
|
-
P-GW
receives the new PRA ID during the initial call setup and stores the PRA ID
information.
-
In
RAR, the PRA_EVENT_TRIGGER is registered.
-
P-GW
send PRA_ACTION PRA ID="A", ACTION=start.
-
In
CCA-U, a new PRA ID is received.
-
P-GW
stores new PRA ID information
-
P-GW
sends PRA_ACTION PRA ID = "B", Action=start but does not send Action=stop for
the earlier PRA.
|
Important
|
Ideally, in above condition, PCRF disables the event triggers
first and sends a new PRA-ID=B and enables the event trigger in subsequent
message.
|
|
|
When PCRF
sends a new PRA ID which is same as the initial call setup.
|
PRA ID does not send any PRA Action toward S-GW and P-GW
ignores this.
|
|
PRA ID
Decode Behavior
|
If PRA ID
received is "core network pre-configured presence reporting area", then, P-GW
ignores the "Element List" coming from PCRF. Otherwise, if PRA ID is
"UE-dedicated Presence Reporting Area", then, P-GW parses the "Element List"
and forwards it toward the access side.
|
|
If PRA ID
values from PCRF are 1 octet, 2 octets, and 3 octets.
|
MSB of
the value received from the PCRF is evaluated to find the PRA type. While
encoding, GTPC side zeros are prepended to make it 3 octets.
For
example, if PRA ID = FC (1111 1100) is received from PCRF it is considered as
UE-dedicated PRA and while decoding it is decoded as 00 00 FC.
P-GW
forwards PRA information toward the roaming subscriber if it is received from
the PCRF or from UE.
|
Important
|
Change
of UE presence in the Presence Reporting Area reporting does not apply to the
roaming scenario.
|
|
|
Roaming
Scenario
|
Change of
UE presence in the Presence Reporting Area reporting does not apply to the
roaming scenario.
When the
serving EPC node (MME, S4-SGSN) is changed, the Presence Reporting Area
identifier is transferred for all PDN connections as part of the MM Context
information to the target serving node during the mobility procedure. The list
of Presence Reporting Area elements are also transferred if they are provided
by the P-GW.
|
|
Handover
Behavior: How the PRA identifier is communicated from source MME/S4-SGSN to
target MME/S4-SGSN.
|
MME/S4-SGSN gets the PRA Identifier from source MME/S4-SGSN as part of MM
Context information.
When the
serving EPC node (MME, S4-SGSN) is changed, the Presence Reporting Area
identifier is transferred for all PDN connections as part of the MM Context
information to the target serving node during the mobility procedure. The list
of Presence Reporting Area elements are also transferred if they are provided
by the P-GW.
|
|
Handoff
Behavior: How PRA is disabled when the new access type is not supported PRA.
|
Depending
on the access type and internal configuration PCRF deactivates the PRA, if the
new access PRA is not supported.
During an
IP-CAN session, P-GW notifies the PCRF that the UE is located in an access
type, where local PCRF configuration is such that the reporting changes of the
UE presence in the PRA are not supported. The PCRF unsubscribes to the change
of UE presence in the PRA, if previously activated.
|
|
Behavior
if for E-UTRAN some nodes do not support PRA.
|
If PRA is
enabled from PCRF, then EPC nodes supports it. If all nodes are not supported,
then PRA PCRF activates the Location Change Reporting.
|
Important
|
For E-UTRAN access, homogeneous support of reporting changes of
UE presence in a Presence Reporting Area in a network is assumed. When the PCRF
configuration indicates that reporting changes of the UE presence in a PRA is
supported for E-UTRAN, this means all P-GWs, all MME, and all S-GW support it,
including the MME and S-GW working in the network sharing mode. If the change
of UE presence in the PRA reporting is not supported, the PCRF may instead
activate the location change reporting at the cell or serving area level.
|
|
|
When
access side procedure failure or collision occurs (Create or Update Bearer
procedure)
|
In Update
or Create bearer procedure failure where the PRA action was sent in the request
message and if PRA information was not received in response message, P-GW
attempts to send the PRA action in next control procedure toward the remote
peer.
In Update
or Create bearer procedure failure where PRA action was sent in the request
message and if PRA information was not received in the response message, P-GW
assumes it as PRA action was successfully communicated toward the remote peer.
In the
Update or Create bearer collision scenario where PRA action was sent in the
request message and Update or Create procedure got aborted, P-GW attempts to
send the PRA action in next control procedure toward the remote peer.
|
Feedback