5.4 Policy
24.3123GPPAccess Network Discovery and Selection Function (ANDSF) Management Object (MO)Release 17TS
5.4.1 ANDSF/Policy
The Policy node acts as a placeholder for ISMP information.
– Occurrence: ZeroOrOne
– Format: node
– Access Types: Get, Replace
– Values: N/A
5.4.2 ANDSF/Policy/<X>
This interior node acts as a placeholder for one or more ISMP rules.
– Occurrence: OneOrMore
– Format: node
– Access Types: Get, Replace
– Values: N/A
5.4.3 ANDSF/Policy/<X>/RulePriority
The RulePriority leaf represents the priority given to one particular rule and is represented as a numerical value.
– Occurrence: One
– Format: int
– Access Types: Get, Replace
– Values: <Rule priority>
In case more than one valid ISMP rule exists, the UE shall treat the rule with the lowest RulePriority value as the rule having the highest priority among the valid rules. If the UE finds multiple rules with the same priority, the choice of the rule is UE implementation specific. If there are no matching access networks according to the rule, the UE shall use other rules with the same priority. If there are no matching access networks according to any rule with a certain priority, the UE may use rules with lower priority.
5.4.4 ANDSF/Policy/<X>/PrioritizedAccess
The PrioritizedAccess node indicates the preferred access for one particular rule.
– Occurrence: One
– Format: node
– Access Types: Get, Replace
– Values: N/A
5.4.5 ANDSF/Policy/<X>/PrioritizedAccess/<X>
This interior node acts as a placeholder for one or more prioritized accesses.
– Occurrence: OneOrMore
– Format: node
– Access Types: Get, Replace
– Values: N/A
5.4.6 ANDSF/Policy/<X>/PrioritizedAccess/<X>/
AccessTechnology
The AccessTechnology leaf indicates a prioritized access technology.
– Occurrence: One
– Format: int
– Access Types: Get, Replace
– Values: <Access technology>
Possible values for the Access technology are specified in table 5.4.6.1.
Table 5.4.6.1: Possible values for the AccessTechnology leaf
|
Value |
Description |
|
0 |
Reserved |
|
1 |
3GPP |
|
2 |
Reserved |
|
3 |
WLAN |
|
4 |
WiMAX |
|
5-255 |
Reserved |
5.4.7 ANDSF/Policy/<X>/PrioritizedAccess/<X>/
AccessId
The AccessId leaf represents an access network identifier.
– Occurrence: ZeroOrOne
– Format: chr
– Access Types: Get, Replace
– Values: <Access id>
The AccessId contains an identifier for a specific radio access network. Only SSID for WLAN and NAP-ID for WiMAX radio access network are contained in this leaf. AccessIds in numerical format shall be encoded as character string. The AccessId be represented by Unicode characters encoded as UTF-8 as specified in IETF RFC 3629 [11] and formatted using Normalization Form KC (NFKC) as specified in Unicode Standard Annex #15; Unicode Normalization Forms [12].
The absence of this leaf indicates that the UE can consider any available radio access network of the defined access technology in the corresponding ANDSF/Policy/<X>/PrioritizedAccess/<X>/AccessTechnology leaf for the network selection.
5.4.8 ANDSF/Policy/<X>/PrioritizedAccess/<X>/
SecondaryAccessId
The SecondaryAccessId leaf represents a secondary access network identifier.
– Occurrence: ZeroOrOne
– Format: chr
– Access Types: Get, Replace
– Values: <HESSID>
The SecondaryAccessId contains an identifier for a specific radio access network. Only HESSID for WLAN radio access network is contained in this leaf. The SecondaryAccessId leaf may only be present when the corresponding AccessId leaf for a WLAN radio access network is present. The format of the HESSID is defined by IEEE 802.11™-2012 [26].
5.4.9 ANDSF/Policy/<X>/PrioritizedAccess/<X>/
AccessNetworkPriority
The AccessNetworkPriority leaf represents an access technology priority.
– Occurrence: One
– Format: int
– Access Types: Get, Replace
– Values: <Access network priority>
In case more than one valid PrioritizedAccess are available and if the value of the priority belongs to the range 1-250, the UE shall consider the access network (with the corresponding access identifier if present) with the lowest AccessNetworkPriority value as the access network (with the corresponding access identifier if present) having the highest priority, as defined in table 5.4.9.1. The AccessNetworkPriority value ‘Restricted access’ (254) indicates an access that should not be used by the UE. The AccessNetworkPriority value ‘Forbidden’ (255) indicates an access that shall not be used by the UE. The same AccessNetworkPriority value may be used for more than one AccessId and more than one Access Technology. If more than one AccessId or more than one Access Technology with the same value of the AccessNetworkPriority are avilable, the UE selects one of them in an implementation dependant way. If the UE is not able to find an access network according to ANDSF policies, it is implementation dependent how to proceed with network selection.
Table 5.4.9.1: Values of AccessNetworkPriority leaf
|
Value |
Description |
|
0 |
Reserved |
|
1-250 |
Priority value |
|
251-253 |
Reserved |
|
254 |
Restricted access. This access should be avoided if the current rule is active. |
|
255 |
Forbidden. UE is not allowed to use this access if the current rule is active. |
NOTE: It is implementation dependent if or when a restricted access is selected if there are no other accesses available.
5.4.10 ANDSF/Policy/<X>/ValidityArea
The ValidityArea node acts as a placeholder for location conditions for a particular rule.
– Occurrence: ZeroOrOne
– Format: node
– Access Types: Get, Replace
– Values: N/A
The validity condition of ValidityArea is considered valid when at least one of 3GPP_Location, or 3GPP2_Location or WiMAX_Location, or WLAN_Location, or Geo_Location is a match.
If the ValidityArea node is present and empty (i.e. none of the nodes 3GPP_Location, 3GPP2_Location, WiMAX_Location, WLAN_Location or Geo_Location exist), then the ValidityArea is not considered when evaluating the validity of the corresponding rule.
If the UE cannot deduce its location by any means, only rules without Validity Area node or rules with empty ValidityArea node can be considered for valid rule.
5.4.11 ANDSF/Policy/<X>/ValidityArea/3GPP_Location
The 3GPP_Location node acts as a placeholder for 3GPP location descriptions.
– Occurrence: ZeroOrOne
– Format: node
– Access Types: Get, Replace
– Values: N/A
If the UE is currently aware that it is located in the coverage area described by at least one instance of ANDSF/Policy/<X>/ValidityArea/3GPP_Location/<X> node, the UE shall consider the corresponding rule as valid. In case of overlapping validity domains of multiple policy rules, RulePriority leaf is used as discriminator.
5.4.12 ANDSF/Policy/<X>/ValidityArea/3GPP_Location/<X>
This interior node acts as a placeholder for one or more 3GPP location descriptions.
– Occurrence: OneOrMore
– Format: node
– Access Types: Get, Replace
– Values: N/A
If the location is indicated with more than one leaf (i.e. PLMN and at least one leaf out of TAC, LAC, GERAN_CI, UTRAN_CI or EUTRA_CI) within a single instance of ANDSF/Policy/<X>/ValidityArea/3GPP_Location/<X> node, then the UE shall consider 3GPP location validity condition for the particular rule to be fulfilled only if the present leaf values in the node match with the location of the UE in that radio access technology, and the UE shall ignore other existing values, if any.
5.4.13 ANDSF/Policy/<X>/ValidityArea/3GPP_Location/<X>/PLMN
The PLMN leaf indicates a PLMN code for one particular 3GPP location condition for the ISMP rule.
– Occurrence: One
– Format: chr
– Access Types: Get, Replace
– Values: <PLMN>
The format of the PLMN is defined by 3GPP TS 23.003 [3].
5.4.14 ANDSF/Policy/<X>/ValidityArea/3GPP_Location/<X>/TAC
The TAC leaf indicates a Tracking Area Code for one particular 3GPP location condition for the ISMP rule.
– Occurrence: ZeroOrOne
– Format: chr
– Access Types: Get, Replace
– Values: <Tracking area code>
The format of the TAC is defined by 3GPP TS 23.003 [3].
5.4.15 ANDSF/Policy/<X>/ValidityArea/3GPP_Location/<X>/LAC
The LAC leaf indicates a Location Area Code for one particular 3GPP location condition for the ISMP rule.
– Occurrence: ZeroOrOne
– Format: chr
– Access Types: Get, Replace
– Values: <Location area code>
The format of the LAC is defined by 3GPP TS 23.003 [3].
5.4.16 ANDSF/Policy/<X>/ValidityArea/3GPP_Location/<X>/GERAN_CI
The GERAN_CI leaf indicates a cell identity for one particular GERAN network related location description.
– Occurrence: ZeroOrOne
– Format: bin
– Access Types: Get, Replace
– Values: <GERAN Cell Identity>
The format of the Cell Global Identity, of which the Cell Identity is part, is defined in 3GPP TS 23.003 [3].
The GERAN_CI value is set to the Cell Identity, CI, obtained from lower layers of the UE. The CI is part of the Cell Global Identity as defined in 3GPP TS 23.003 [3]. The value of GERAN_CI is coded as a bit string with fixed length of 16 bits.
5.4.17 ANDSF/Policy/<X>/ValidityArea/3GPP_Location/ <X>/UTRAN_CI
The UTRAN_CI leaf indicates a cell identity for one particular UTRAN network related location description.
– Occurrence: ZeroOrOne
– Format: bin
– Access Types: Get, Replace
– Values: <UTRAN Cell Identity>
The UTRAN_CI value is set to the UTRAN Cell Identity as defined in 3GPP TS 25.331 [3B] and obtained from lower layers of the UE. The value of UTRAN CI is coded as a bit string with fixed length of 28 bits.
5.4.18 ANDSF/Policy/<X>/ValidityArea/3GPP_Location/ <X>/EUTRA_CI
The EUTRA_CI leaf indicates a cell identity for one particular E-UTRA network related location description.
– Occurrence: ZeroOrOne
– Format: bin
– Access Types: Get, Replace
– Values: <E-UTRA Cell Identity>
The EUTRA_CI value is set to the cell identity part of the Evolved Cell Global Identifier, as described in 3GPP TS 36.331 [3C] and obtained from lower layers of the UE. The value of EUTRA_CI is coded as a bit string with fixed length of 28 bits.
5.4.19 ANDSF/Policy/<X>/ValidityArea/3GPP2_Location
This 3GPP2_Location node acts as a placeholder for 3GPP2 location descriptions.
– Occurrence: ZeroOrOne
– Format: node
– Access Types: Get, Replace
– Values: N/A
If the UE is currently aware that it is located in the coverage area described by ANDSF/Policy/<X>/ValidityArea/3GPP2_Location/1x or ANDSF/Policy/<X>/ValidityArea/3GPP2_Location/HRPD or bothnodes, the UE shall consider the corresponding rule as valid. In case of overlapping validity domains of multiple policy rules, RulePriority leaf is used as discriminator.
If ANDSF provides 3GPP2_Location as a validity area, either the 1x or HRPD interior node, or both, shall be provided.
5.4.20 ANDSF/Policy/<X>/ValidityArea/3GPP2_Location/1x
This 1x node acts as a placeholder for 3GPP2 1x RAT location descriptions.
– Occurrence: ZeroOrOne
– Format: node
– Access Types: Get, Replace
– Values: N/A
If the UE is currently aware that it is located in the coverage area described by at least one instance of ANDSF/Policy/<X>/ValidityArea/3GPP2_Location/1x /<X> node, the UE shall consider the corresponding rule as valid.
5.4.21 ANDSF/Policy/<X>/ValidityArea/3GPP2_Location/1x/<X>
This interior node acts as a placeholder for one or more 3GPP2 1x RAT location descriptions.
– Occurrence: OneOrMore
– Format: node
– Access Types: Get, Replace
– Values: N/A
If the location is indicated with more than one leaf (i.e. SID and at least one leaf out of NID or Base_ID are present) within a single instance of ANDSF/Policy/<X>/ValidityArea/3GPP2_Location/1x/<X> node, the UE shall consider 3GPP2 location validity condition for the particular rule to be fulfilled only if all the present leaf values in the node match with the location of the UE.
5.4.22 ANDSF/Policy/<X>/ValidityArea/3GPP2_Location/1x/<X>/
SID
This SID leaf indicates a System Identification code for one particular 3GPP2 1x RAT location condition for the ISMP rule.
– Occurrence: One
– Format: chr
– Access Types: Get, Replace
– Values: <System Identification>
The format of the SID is defined by 3GPP2 C S0016 [14].
5.4.23 ANDSF/Policy/<X>/ValidityArea/3GPP2_Location/1x/<X>/
NID
This NID leaf indicates a Network Identification code for one particular 3GPP2 1x RAT location condition for the ISMP rule.
– Occurrence: ZeroOrOne
– Format: chr
– Access Types: Get
– Values: <Network Identification>
The format of the NID is defined by 3GPP2 C.S0016 [14].
5.4.24 ANDSF/Policy/<X>/ValidityArea/3GPP2_Location/1x/<X>/
Base_ID
This Base_ID leaf indicates a Base Station Identification code for one particular 3GPP2 1x RAT location condition for the ISMP rule.
– Occurrence: ZeroOrOne
– Format: chr
– Access Types: Get, Replace
– Values: <Base Station Identification>
The format of the Base_ID is defined by 3GPP2 C.S0005 [13].
5.4.25 ANDSF/Policy/<X>/ValidityArea/3GPP2_Location/HRPD
This HRPD node acts as a placeholder for 3GPP2 HRPD RAT location descriptions.
– Occurrence: ZeroOrOne
– Format: node
– Access Types: Get, Replace
– Values: N/A
If the UE is currently aware that it is located in the coverage area described by at least one instance of ANDSF/Policy/<X>/ValidityArea/3GPP2_Location/HRPD/<X> node, the UE shall consider the corresponding rule as valid.
5.4.26 ANDSF/Policy/<X>/ValidityArea/3GPP2_Location/HRPD/<X>
This interior node acts as a placeholder for one or more 3GPP2 HRPD RAT location descriptions.
– Occurrence: OneOrMore
– Format: node
– Access Types: Get, Replace
– Values: N/A
The UE shall consider 3GPP2 location validity condition for the particular rule to be fulfilled only if both the leaf values within a single instance of ANDSF/Policy/<X>/ValidityArea/3GPP2_Location/HRPD/<X> node (i.e. Sector_ID and Netmask) match with the location of the UE.
5.4.27 ANDSF/Policy/<X>/ValidityArea/3GPP2_Location/HRPD/<X>/
Sector_ID
This Sector_ID leaf indicates a Sector Identification code for one particular 3GPP2 HRPD RAT location condition for the ISMP rule.
– Occurrence: One
– Format: bin
– Access Types: Get, Replace
– Values: < Sector_ID >
The format of the Sector_ID is defined by 3GPP2 C.S0024-0 [15]. The length of Sector ID contained in this node is 128 bits.
5.4.28 ANDSF/Policy/<X>/ValidityArea/3GPP2_Location/HRPD/<X>/
Netmask
This Netmask leaf indicates a Netmask code for one particular 3GPP2 HRPD RAT location condition for the ISMP rule.
– Occurrence: One
– Format: bin
– Access Types: Get, Replace
– Values: < Netmask>
The format of Netmask is defined by 3GPP2 C.S0024-0 [15]. The length of Netmask contained in this node is 8 bits. The mask contained in this leaf shall be applied to the Sector_ID bit string contained in the correspondent leaf of interior node ANDSF/Policy/<X>/ValidityArea/3GPP2_Location/HRPD/<X>/Sector_ID.
5.4.29 ANDSF/Policy/<X>/ValidityArea/WiMAX_Location
The WiMAX_Location node acts as a placeholder for WiMAX location descriptions.
– Occurrence: ZeroOrOne
– Format: node
– Access Types: Get, Replace
– Values: N/A
If the UE is currently aware that it is located in the coverage area described by at least one instance of ANDSF/Policy/<X>/ValidityArea/WiMAX_Location/<X> node, the UE shall consider the corresponding rule as valid. In case of overlapping validity domains of multiple policy rules, RulePriority leaf is used as discriminator.
5.4.30 ANDSF/Policy/<X>/ValidityArea/WiMAX_Location/<X>
This interior node acts as a placeholder for one or more WiMAX location descriptions.
– Occurrence: OneOrMore
– Format: node
– Access Types: Get, Replace
– Values: N/A
The UE shall consider WiMAX location validity condition for the particular rule to be fulfilled only if both the leaf values within a single instance of ANDSF/Policy/<X>/ValidityArea/WiMAX_Location/<X> node (i.e. NAP-ID and BS-ID) match with the location of the UE.
5.4.31 ANDSF/Policy/<X>/ValidityArea/WiMAX_Location/<X>/NAP-ID
The NAP-ID leaf indicates the Network Access Provider for a particular WiMAX location condition for the ISMP rule.
– Occurrence: One
– Format: chr
– Access Types: Get, Replace
– Values: <NAP-ID>
The format of the NAP-ID is defined by the WiMAX Forum Network Architecture Release 1.0 version 1.2.2 – Stage 2 [6] and WiMAX Forum Network Architecture Release 1.0 version 1.2.2 – Stage 3 [7].
5.4.32 ANDSF/Policy/<X>/ValidityArea/WiMAX_Location/<X>/BS-ID
The BS-ID leaf indicates the BS identifier for a particular WiMAX location condition for the ISMP rule.
– Occurrence: One
– Format: chr
– Access Types: Get, Replace
– Values: <BS-ID>
The format of the BS-ID is defined by the IEEE Std 802.16e-2005 and IEEE Std 802.16-2004/Cor1-2005 [10].
5.4.33 ANDSF/Policy/<X>/ValidityArea/WLAN_Location
The WLAN_Location node acts as a placeholder for WLAN location descriptions.
– Occurrence: ZeroOrOne
– Format: node
– Access Types: Get, Replace
– Values: N/A
If the UE is currently aware that it is located in the coverage area described by at least one instance of ANDSF/Policy/<X>/ValidityArea/WLAN_Location/<X> node, the UE shall consider the corresponding rule as valid. In case of overlapping validity domains of multiple policy rules, RulePriority leaf is used as discriminator.
The UE shall ignore WLAN_Location node that is present and does not contain at least one of the non-empty leaves (i.e. HESSID, SSID or BSSID).
5.4.34 ANDSF/Policy/<X>/ValidityArea/WLAN_Location/<X>
This interior node acts as a placeholder for one or more WLAN location descriptions.
– Occurrence: OneOrMore
– Format: node
– Access Types: Get, Replace
– Values: N/A
If the location is indicated with at least one present leaf out of HESSID, SSID, or BSSID within a single instance of ANDSF/Policy/<X>/ValidityArea/WLAN_Location/<X> node, the UE shall consider WLAN location validity condition for the particular rule to be fulfilled only if all the present leaf values in the node match with the location of the UE.
5.4.35 ANDSF/Policy/<X>/ValidityArea/WLAN_Location/<X>/HESSID
The HESSID leaf indicates the HESSID for a particular WLAN location condition for the ISMP rule.
– Occurrence: ZeroOrOne
– Format: chr
– Access Types: Get, Replace
– Values: <HESSID>
The format of the HESSID is defined by IEEE 802.11™-2012 [26].
5.4.36 ANDSF/Policy/<X>/ValidityArea/WLAN_Location/<X>/SSID
The SSID leaf indicates the SSID for a particular WLAN location condition for the ISMP rule.
– Occurrence: ZeroOrOne
– Format: chr
– Access Types: Get, Replace
– Values: <SSID>
The format of the SSID is defined by IEEE Std 802.11™-2012 [26].
5.4.37 ANDSF/Policy/<X>/ValidityArea/WLAN_Location/<X>/BSSID
The BSSID leaf indicates the AP identifier for one particular WLAN location condition for the ISMP rule.
– Occurrence: ZeroOrOne
– Format: chr
– Access Types: Get, Replace
– Values: <BSSID>
The format of the BSSID is defined by IEEE Std 802.11™-2012 [26].
5.4.38 ANDSF/Policy/<X>/ValidityArea/Geo_Location
The Geo_Location node acts as a placeholder for Geographical location descriptions for one ISMP rule.
– Occurrence: ZeroOrOne
– Format: node
– Access Types: Get, Replace
– Values: N/A
If the UE is currently aware that it is located in the area described by at least one instance of ANDSF/Policy/<X>/ValidityArea/Geo_Location/Circular/<X> node, the UE shall consider the corresponding rule as valid. In case of overlapping validity domains of multiple policy rules, RulePriority leaf is used as discriminator.
If the ANDSF/Policy/<X>/ValidityArea/Geo_Location node is present and empty (i.e. the node Circular does not exist), then the Geo_Location node is not considered when evaluating the validity of the corresponding rule.
5.4.39 ANDSF/Policy/<X>/ValidityArea/Geo_Location/Circular
The Circular node acts as a placeholder for circular areas location descriptions for one ISMP rule.
– Occurrence: ZeroOrOne
– Format: node
– Access Types: Get, Replace
– Values: N/A
5.4.40 ANDSF/Policy/<X>/ValidityArea/Geo_Location/Circular/<X>
The interior node acts as a placeholder for one or more circular area location descriptions for one ISMP rule.
– Occurrence: OneOrMore
– Format: node
– Access Types: Get, Replace
– Values: <N/A >
The UE shall consider Geo location validity condition for the particular rule to be fulfilled only if all the leaf values within a single instance of ANDSF/Policy/<X>/ValidityArea/Geo_Location/Circular/<X> node (i.e. AnchorLatitude, AnchorLongitude and Radius) match with the location of the UE.
5.4.41 ANDSF/Policy/<X>/ValidityArea/Geo_Location/Circular/<X>/ AnchorLatitude
The AnchorLatitude leaf indicates the latitude value of the center of the circular area.
– Occurrence: One
– Format: bin
– Access Types: Get, Replace
– Values: < Latitude>
The Latitude is defined in subclause 6.1 of 3GPP TS 23.032 [3A].
5.4.42 ANDSF/Policy/<X>/ValidityArea/Geo_Location/Circular/<X>/ AnchorLongitude
The AnchorLongitude leaf indicates the longitude value of the centre of the circular area.
– Occurrence: One
– Format: bin
– Access Types: Get, Replace
– Values: < Longitude >
The Longitude is defined in subclause 6.1 of 3GPP TS 23.032 [3A].
5.4.43 ANDSF/Policy/<X>/ValidityArea/Geo_Location/Circular/<X>/ Radius
The Radius leaf indicates the radius value of the circular area.
– Occurrence: One
– Format: int
– Access Types: Get, Replace
– Values: < Radius>
The Radius is given in meters and is defined in subclause 6.6 of 3GPP TS 23.032 [3A].
5.4.43A ANDSF/Policy/<X>/ValidityAreaRef
The ValidityAreaRef leaf contains a reference to a ValidityArea interior node.
– Occurrence: ZeroOrOne
– Format: chr
– Access Types: Get, Replace
– Values: < a reference to a ValidityArea interior node >
The reference to a ValidityArea interior node is a full device URI as specified in OMA-TS-DM_Protocol-V1_2 [5A], identifying the ValidityArea interior node in the UE management tree.
ValidityAreaRef leaf is considered a match when the referenced ValidityArea interior node is considered a match.
5.4.44 ANDSF/Policy/<X>/Roaming
The Roaming leaf indicates the roaming condition for the ISMP rule.
– Occurrence: ZeroOrOne
– Format: bool
– Access Types: Get, Replace
– Values: 0, 1
0 Indicates that the rule is only valid when the UE is not roaming.
1 Indicates that the rule is only valid when the UE is roaming.
The UE shall consider a rule with the Roaming leaf present as valid only if the current roaming state (roaming/not roaming) of the UE matches the one indicated in the Roaming value.
NOTE: When the UE is roaming, how it discovers and interacts with the ANDSF is not specified in the specification of this release.
5.4.45 ANDSF/Policy/<X>/PLMN
The PLMN leaf indicates a PLMN code of the operator, which created this policy.
– Occurrence: One
– Format: chr
– Access Types: Get, Replace
– Values: <PLMN>
The format of the PLMN is defined by 3GPP TS 23.003 [3].
5.4.46 ANDSF/Policy/<X>/TimeOfDay
The TimeOfDay node indicates the time of day condition for the ISMP rule.
– Occurrence: ZeroOrOne
– Format: node
– Access Types: Get, Replace
– Values: N/A
The validity condition of TimeOf Day is considered fulfilled when the time of day in the current time zone, as indicated by the UE, matches at least one time interval indicated in the TimeOfDay node.
If the ANDSF/Policy/<X>/TimeOfDay/<X> node is present and empty (i.e. none of the nodes TimeStart, TimeStop, DateStart, DateStop or DayOfWeek exist), then the TimeOfDay is not considered when evaluating the validity of the corresponding rule.
If the UE does not support calendar or clock application, only rules without TimeOfDay node or rules with empty TimeOfDay node can be considered as valid rules.
5.4.47 ANDSF/Policy/<X>/TimeOfDay/<X>
This interior node acts as a placeholder for one or more time of day condition for the ISMP rule.
– Occurrence: OneOrMore
– Format: node
– Access Types: Get, Replace
– Values: N/A
The UE shall interpret the TimeOfDay leaf values as related to the local time of the UE. The TimeOfDay conditions are evaluated as specified in table 5.4.47.1 and table 5.4.47.2.
Table 5.4.47.1 also specifies TimeOfDay leaf combinations, which are not allowed. ANDSF shall not use such leaf combinations and UE processing of such combinations is UE implementation specific.
NOTE 1: TimeOfDay leaf value combinations, where TimeStart, TimeStop, or both TimeStart and TimeStop are not included, are explained in table 5.4.47.1.
NOTE 2: TimeOfDay leaf value combinations, where both TimeStart and TimeStop are included are explained in table 5.4.47.2. The second half of table 5.4.47.2, where TimeStop is before TimeStart, explains how to configure overnight time periods.
Figure 5.4.47.1 shows an example of overnight TimeOfDay repetitious periods when both DateStart and DateStop leaves are included.
Table 5.4.47.1: Applicable TimeOfDay leaf combinations when TimeStart and TimeStop are not both included
|
TimeStart |
TimeStop |
DateStart |
DateStop |
Date and time ranges when the given condition is applicable |
|
not included |
not included |
not included |
not included |
From current time and current day to infinite: – only during days of the week indicated by DayOfWeek leaf if DayOfWeek leaf is included; or – during all days if DayOfWeek leaf is not included. |
|
not included |
not included |
not included |
included |
From the current time of the current day to 24:00 of the date indicated by DateStop: – only during days of the week indicated by DayOfWeek leaf if DayOfWeek leaf is included; or – during all days if DayOfWeek leaf is not included. |
|
not included |
not included |
included |
not included |
From 00:00 of the date indicated by DateStart to infinite: – only during days of the week indicated by DayOfWeek leaf if DayOfWeek leaf is included; or – during all days if DayOfWeek leaf is not included. |
|
not included |
not included |
included |
included |
From 00:00 of the date indicated by DateStart to 24:00 of the date indicated by DateStop: – only during days of the week indicated by DayOfWeek leaf if DayOfWeek leaf is included; or – during all days if DayOfWeek leaf is not included. |
|
not included |
included |
not included |
not included |
Not allowed |
|
not included |
included |
not included |
included |
From the current time of the current day to the time indicated by TimeStop of the date indicated by DateStop: – only during days of the week indicated by DayOfWeek leaf if DayOfWeek leaf is included; or – during all days if DayOfWeek leaf is not included. |
|
not included |
included |
included |
not included |
Not allowed |
|
not included |
included |
included |
included |
From 00:00 of the date indicated by DateStart to the time indicated by TimeStop of the date indicated by DateStop: – only during days of the week indicated by DayOfWeek leaf if DayOfWeek leaf is included; or – during all days if DayOfWeek leaf is not included. |
|
included |
not included |
not included |
not included |
Not allowed |
|
included |
not included |
not included |
included |
Not allowed |
|
included |
not included |
included |
not included |
From the time indicated by TimeStart of the date indicated by DateStart to infinite: – only during days of the week indicated by DayOfWeek leaf if DayOfWeek leaf is included; or – during all days if DayOfWeek leaf is not included. |
|
included |
not included |
included |
included |
From the time indicated by TimeStart of the date indicated by DateStart to 24:00 of the date indicated by DateStop: – only during days of the week indicated by DayOfWeek leaf if DayOfWeek leaf is included; or – during all days if DayOfWeek leaf is not included. |
Table 5.4.47.2: Applicable TimeOfDay leaf combinations when TimeStart and TimeStop are both included
|
TimeStart |
TimeStop |
DateStart |
DateStop |
Date and time ranges when the given condition is applicable |
|
included |
included and not before TimeStart |
not included |
not included |
From the time indicated by TimeStart to the time indicated by Time-Stop, from current day to infinite: – only during days of the week indicated by DayOfWeek leaf if DayOfWeek leaf is included; or – daily if DayOfWeek leaf is not included. |
|
included |
included and not before TimeStart |
not included |
included |
From the time indicated by TimeStart to the time indicated by TimeStop, from the current day until the date indicated by DateStop: – only during days of the week indicated by DayOfWeek leaf if DayOfWeek leaf is included; or – daily if DayOfWeek leaf is not included. |
|
included |
included and not before TimeStart |
included |
not included |
From the time indicated by TimeStart to the time indicated by TimeStop, from the date indicated by DateStart to infinite: – only during days of the week indicated by DayOfWeek leaf if DayOfWeek leaf is included; or – daily if DayOfWeek leaf is not included. |
|
included |
included and not before TimeStart |
included |
included |
From the time indicated by TimeStart to the time indicated by TimeStop, from the date indicated by DateStart to the date indicated by DateStop: – only during days of the week indicated by DayOfWeek leaf if DayOfWeek leaf is included; or – daily if DayOfWeek leaf is not included. |
|
included |
included and before TimeStart |
not included |
not included |
From the time indicated by TimeStart to 24:00 and from 00:00 to the time indicated by TimeStop, from current day to infinite: – only during days of the week indicated by DayOfWeek leaf if DayOfWeek leaf is included; or – daily if DayOfWeek leaf is not included. |
|
included |
included and before TimeStart |
not included |
included |
From the time indicated by TimeStart to 24:00 and from 00:00 to the time indicated by TimeStop, from the current day to the date indicated by DateStop: – only during days of the week indicated by DayOfWeek leaf if DayOfWeek leaf is included; or – daily if DayOfWeek leaf is not included. |
|
included |
included and before TimeStart |
included |
not included |
From the time indicated by TimeStart to 24:00 and from 00:00 to the time indicated by TimeStop, from the date indicated by DateStart until infinite: – only during days of the week indicated by DayOfWeek leaf if DayOfWeek leaf is included; or – daily if DayOfWeek leaf is not included. |
|
included |
included and before TimeStart |
included |
included |
From the time indicated by TimeStart to 24:00 and from 00:00 to the time indicated by TimeStop, from the date indicated by DateStart to the date indicated by DateStop: – only during days of the week indicated by DayOfWeek leaf if DayOfWeek leaf is included; or – daily if DayOfWeek leaf is not included. |
NOTE: A specific continuous time period, which includes times of day from two different dates, can be expressed using multiple TimeOfDay instances: one instance for the starting date, one instance for the ending date and one instance for all dates between the starting and ending date if any. For example, 2012-10-27, 22:00 – 2012-10-30, 02:00 is defined as:
TimeOfDay/1: 2012-10-27T22:00 – 2012-10-27T24:00,
TimeOfDay/2: 2012-10-28 – 2012-10-29 and
TimeOfDay/3: 2012-10-30T00:00 – 2012-10-30T02:00.
Figure 5.4.47.1: Example of overnight TimeOfDay repetitious periods
5.4.48 ANDSF/Policy/<X>/TimeOfDay/<X>/TimeStart
The TimeStart leaf acts as a place holder containing a time of day.
– Occurrence: ZeroOrOne
– Format: chr
– Access Types: Get, Replace
– Values: <time of day>
The value this leaf can assume is time of the day represented in string format, as defined in ISO 8601:2004 [16].
5.4.49 ANDSF/Policy/<X>/TimeOfDay/<X>/TimeStop
The TimeStop leaf node acts as a place holder containing a time of day.
– Occurrence: ZeroOrOne
– Format: chr
– Access Types: Get, Replace
– Values: <time of day>
The value this leaf can assume is time of the day represented in string format, as defined in ISO 8601:2004 [16].
5.4.50 ANDSF/Policy/<X>/TimeOfDay/<X>/DateStart
The DateStart leaf acts as a place holder containing a date.
– Occurrence: ZeroOrOne
– Format: chr
– Access Types: Get, Replace
– Values: <date>
The value this leaf can assume is a date represented in string format, as defined in ISO 8601:2004 [16]. The UE handling of semantical error where DateStart node indicates a date that does not exist is UE implementation specific.
5.4.51 ANDSF/Policy/<X>/TimeOfDay/<X>/DateStop
The DateStop leaf acts as a place holder containing a date.
– Occurrence: ZeroOrOne
– Format: chr
– Access Types: Get, Replace
– Values: <date>
The value this leaf can assume is a date represented in string format, as defined in ISO 8601:2004 [16].
The UE handling of semantical error where DateStop node indicates a date that does not exist is UE implementation specific.
5.4.51A ANDSF/Policy/<X>/TimeOfDay/<X>/DayOfWeek
The DayOfWeek leaf indicates the day(s) of the week for which the corresponding rule is valid.
– Occurrence: ZeroOrOne
– Format: int
– Access Types: Get, Replace
– Values: <day of week bitmap>
The value of this leaf is an 8-bit integer formated as a bit map representing days of the week. The most significant bit is set to one. The remaining bits represent days of the week, as shown in figure 5.4.51A.1:
Figure 5.4.51A.1: Bitmap format for the value of DayOfWeek leaf
If the bit corresponding to a day of the week is set, the rule is valid on that day. The following values are invalid:
– "null";
– 128; and
– less than 128.
The UE processing of invalid values is implementation dependent.
5.4.51B ANDSF/Policy/<X>/TimeOfDayRef
The TimeOfDayRef leaf contains a reference to a TimeOfDay interior node.
– Occurrence: ZeroOrOne
– Format: chr
– Access Types: Get, Replace
– Values: < a reference to a TimeOfDay interior node >
The reference to a TimeOfDay interior node is a full device URI as specified in OMA-TS-DM_Protocol-V1_2 [5A], identifying the TimeOfDay interior node in the UE management tree.
TimeOfDayRef leaf is considered a match when the referenced TimeOfDay interior node is considered a match.
5.4.52 ANDSF/Policy/<X>/UpdatePolicy
The UpdatePolicy leaf indicates the update policy for the ISMP.
– Occurrence: ZeroOrOne
– Format: bool
– Access Types: Get, Replace
– Values: 0, 1
0 Indicates that the UE is not required to request an update of the ISMP.
1 Indicates that the UE is required to request an update of the ISMP.
The UpdatePolicy value may be used by the UE to determine whether or not to request an update of its ISMP when the rule is no longer considered to be valid by the UE.
The default value 0 applies if this leaf is not provisioned.