Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 23.682  Word version:  17.0.0

Top   Top   Up   Prev   Next
1…   4.2   4.3…   4.4…   4.5…   4.5.7…   4.5.14…   4.6…   5…   5.3…   5.5…   5.6…   5.6.2…   5.6.6…   5.7…   5.8…   5.9…   5.13…   5.14…   5.15   5.16   5.17…   5.18   5.19…   A…   C…

 

4.5  High Level FunctionWord‑p. 26

4.5.1  Device Triggering Function

Device Triggering is the means by which a SCS sends information to the UE via the 3GPP network to trigger the UE to perform application specific actions that include initiating communication with the SCS for the indirect model or an AS in the network for the hybrid model. Device Triggering is required when an IP address for the UE is not available or reachable by the SCS/AS.
Device trigger message contains information that allows the network to route the message to the appropriate UE and the UE to route the message to the appropriate application. The information destined to the application, along with the information to route it, is referred to as the Trigger payload. The UE needs to be able to distinguish an MT message carrying device triggering information from any other type of messages.
Device Triggering is subscription based. The subscription provides the information whether a UE is allowed to be triggered by a specific SCS. When device triggers are delivered via MT-SMS the serving nodes MME, SGSN and MSC provide the service towards a specific UE based on the UE's subscription for MT-SMS and other subscription parameters affecting MT-SMS service provision.
Device triggering recall/replace functionality allows a SCS to recall or replace previously submitted trigger messages which are not yet delivered to the UE.
Charging data are collected for the device triggering. The MTC-IWF generates CDRs for the service requester. When device triggers are delivered via MT-SMS then network entities, like MME, SGSN, MSC or SMS-SC generate CDRs for SMS services provided for the mobile subscriber.
Up

4.5.2  PS-only Service Provision

PS-only service provision is providing a UE with all subscribed services via PS domain. PS-only service provision implies a subscription that allows only for services exclusively provided by the PS domain, i.e. packet bearer services and SMS services. The support of SMS services via PS domain NAS is a network deployment option and may depend also on roaming agreements. Therefore, a subscription intended for PS-only service provision may allow also for SMS services via CS domain to provide a UE with SMS services in situations when serving node or network don't support SMS via PS domain NAS. The functionality that enables PS-only service provision is described in TS 23.060 and TS 23.272.
The functionality that enables PS-only service provision for SMS delivery in IMS is described in TS 23.204.
Up

4.5.3  Core Network assisted RAN parameters tuning |R12|

Core Network assisted RAN parameters tuning aids the RAN in optimizing the setting of RAN parameters. See TS 23.401 for details.

4.5.4  UE Power Saving Mode |R12|

A UE may adopt the PSM for reducing its power consumption. That mode is similar to power-off, but the UE remains registered with the network and there is no need to re-attach or re-establish PDN connections. A UE in PSM is not immediately reachable for mobile terminating services. A UE using PSM is available for mobile terminating services during the time it is in connected mode and for the period of an Active Time that is after the connected mode. The connected mode is caused by a mobile originated event like data transfer or signalling, e.g. after a periodic TAU/RAU procedure. PSM is therefore intended for UEs that are expecting only infrequent mobile originating and terminating services and that can accept a corresponding latency in the mobile terminating communication.
For mobile terminated data while a UE is in PSM, the functions for High latency communication may be used as described in clause 4.5.7.
PSM has no support in the CS domain on the network side. PSM should only be used by UEs using the PS domain, SMS and mobile originated IMS or CS services. A UE that uses mobile terminated CS services other than SMS should not use PSM as the CS domain does not provide support for mobile terminated CS voice services to UEs that are in PSM. A UE that uses delay tolerant mobile terminated IMS services other than SMS should not request for PSM unless IMS uses the functions for High latency communication as described in clause 4.5.7.
Applications that want to use the PSM need to consider specific handling of mobile terminating services or data transfers. A network side application may send an SMS or a device trigger to trigger an application on UE to initiate communication with the SCS/AS, which is delivered when the UE becomes reachable. Alternatively a network side application may request monitoring of reachability for data to receive a notification when it is possible to send downlink data immediately to the UE, which is when the UE becomes reachable for downlink data transfer. Alternatively, if an SCS/AS has periodic downlink data, it is more efficient when the UE initiates communication with the SCS/AS to poll for downlink data with that period. For either of the options to work, the UE should request an Active Time that is together with the time being in connected mode long enough to allow for potential mobile terminated service or data delivery, e.g. to deliver an SMS.
When the UE wants to use the PSM it shall request an Active Time value during every Attach and TAU/RAU procedures. If the network supports PSM and accepts that the UE uses PSM, the network confirms usage of PSM by allocating an Active Time value to the UE. The network takes the UE requested value, the Maximum Response Time (defined in clause 5.6.1.4), if provided with the Insert Subscriber Data or Update Location Ack message from HSS, and any local MME/SGSN configuration into account for determining the Active Time value that is allocated to the UE. If the UE wants to change the Active Time value, e.g. when the conditions are changed in the UE, the UE consequently requests the value it wants in the TAU/RAU procedure.
An Active Time may be shorter than the time estimated for delivering a waiting SMS to the UE in NOTE 2 above, e.g. 0 seconds. If the MME/SGSN allocates such a shorter Active Time to the UE, the MME/SGSN (for signalling only connections and if the 'msg waiting flag' is set) and the RAN (for connections with RAB(s) set up) should be configured to keep the connection with the UE sufficiently long such that a waiting SMS can be delivered.
If the MME/SGSN is requested to monitor for Reachability for Data, the MME/SGSN (for signalling only connections) and the RAN (for connections with RAB(s) set up) should keep the connection for the Maximum Response Time less the Active Time, if Maximum Response Time is provided with the Insert Subscriber Data message from HSS. Otherwise a configured default Maximum Response Time is assumed by the MME/SGSN.
The UE is in PSM until a mobile originated event (e.g. periodic RAU/TAU, mobile originated data or detach) requires the UE to initiate any procedure towards the network. In Attach and RAU/TAU procedures a PSM capable UE may request a periodic TAU/RAU Timer value suitable for the latency/responsiveness of the mobile terminated services. If the UE wants to change the periodic TAU/RAU Timer value, e.g. when the conditions are changed in the UE, the UE consequently requests the value it wants in the TAU/RAU procedure.
Any timers and conditions that remain valid during power-off, e.g. NAS-level back-off timers, apply in the same way during PSM. The UE may leave the PSM any time, e.g. for mobile originated communications.
If the network confirms the usage of PSM to a UE, the network shall not activate the ISR for such UE.
The specific procedure handling is described in TS 23.060 and TS 23.401.
Up

4.5.5  Group Message Delivery |R13|Word‑p. 28

The Group Message Delivery feature allows an SCS/AS to deliver a payload to a group of UEs. Two methods of Group Message Delivery are specified:
  • Group Message Delivery via MBMS which is intended to efficiently distribute the same content to the members of a group that are located in a particular geographical area when MBMS is used;
  • Group Message Delivery via unicast MT NIDD for UEs which are part of the same External Group Identifier.
The specific procedure handling for group message delivery using MBMS is described in clause 5.5.1. The group message delivery using MBMS has limited applicability and does not support all the scenarios, e.g. UEs not supporting MBMS, UEs located in areas where MBMS is not deployed. The SCS/AS may recall or replace a previously submitted MBMS message; this is described in clause 5.5.2.
The Group MT NIDD procedure for delivering non-IP data to a group via unicast MT NIDD is described in clause 5.5.3. The SCEF uses the SCS/AS Identifier and the External Group Identifier to determine the APN that will be used to send the non-IP data to the group member UEs. This determination is based on local policies. When the SCEF receives a Group MT NIDD request from the SCS/AS, the SCEF queries the HSS to resolve the group members and forks the message by sending it in a unicast manner to all of the individual UEs that are associated with the External Group Identifier.
Up

4.5.6  Monitoring Events |R13|

4.5.6.1  General

The Monitoring Events feature is intended for monitoring of specific events in 3GPP system and making such monitoring events information available via the SCEF. It is comprised of means that allow the identification of the 3GPP network element suitable for configuring the specific events, the event detection, and the event reporting to the authorised users, e.g. for use by applications or logging, etc. If such an event is detected, the network might be configured to perform special actions, e.g. limit the UE access. Configuration and reporting of the following monitoring events may be supported:
  • Monitoring the association of the UE and UICC and/or new IMSI-IMEI-SV association;
  • UE reachability;
  • Location of the UE, and change in location of the UE;
  • Loss of connectivity;
  • Communication failure;
  • Roaming status (i.e. Roaming or No Roaming) of the UE, and change in roaming status of the UE; and
  • Number of UEs present in a geographical area;
  • Availability after DDN failure; and
  • PDN Connectivity Status.
To support monitoring features in roaming scenarios, a roaming agreement needs to be made between the HPLMN and the VPLMN. The set of capabilities required for monitoring may be accessible via different 3GPP interfaces/nodes. Selection of 3GPP interface(s) to configure/report the event is dependent on the type of the event, operator configuration, required frequency of event reporting, application provided parameters in monitoring event request, etc.
Support for Monitoring Events can be offered either via HSS, MME/SGSN (as described in clause 4.5.6.2) or via PCRF (as described in clause 4.5.6.3). Based on operator policies, it shall be possible to configure Monitoring Events such that some Monitoring Event follows procedures in clause 4.5.6.2 while another Monitoring Event follows procedures in clause 4.5.6.3. SCEF shall not enable a given Monitoring Event for the same UE via both HSS/MME/SGSN, and PCRF. For the case of group based Monitoring Events, the SCS/AS (either the same SCS/AS or different SCSs/ASs) may configure a Monitor Event with different External Group Identifiers. If, in such a case, more than one External Group Identifier point to the same UE and no Group Reporting Guard Time was provided with any of the monitoring event configurations, the MME, HSS, and SCEF should not send duplicate reports of the same event for the same UE to the same destination.
Up

4.5.6.2  Monitoring Events via HSS and MME/SGSNWord‑p. 29

Monitoring Events via the HSS and the MME/SGSN enables SCEF to configure a given Monitor Event at HSS or MME/SGSN, and reporting of the event via HSS and/or MME/SGSN. Depending on the specific monitoring event or information, it is either the MME/SGSN or the HSS that is aware of the monitoring event or information and makes it available via the SCEF.
The procedures for requesting specific monitoring information or event reports as well as the report procedures are described in clause 5.6.
Some subscription data in HSS for a UE may affect the event monitoring, and such subscription data is set taking the input from the specific parameter(s) of monitoring event(s) as specified in clause 5.6 or from the network parameter configuration(s) as specified in clause 5.18, or from both of them.
If the Enhanced Multiple Event Monitoring feature is supported, the HSS stores the specific parameters per SCEF Reference ID for the same or different event types from multiple SCS/ASs or the specific parameters for the network parameter configurations from multiple SCS/ASs, or from both of them.
Up

4.5.6.3  Monitoring Events via PCRF

Monitoring Events via the PCRF enables the SCEF to retrieve the location information and to report communication failure of a UE. When not performing group monitoring, the SCEF acting as AF shall have an active Rx session to enable the PCRF to report these events. The procedure is defined in in clause 6.2.3 of TS 23.203. The procedure for requesting location information, when not performing group monitoring, is described in clause 5.6.4.1.
The UE location information, provided over Rx, may include a time stamp to indicate when the UE was last-known to be in that location, i.e. if the current location or the last-known location is provided. The UE location information is reported at the time the Rx session is established, modified or terminated. The subscription to UE location information is not persistent across Rx sessions. The UE location information is provided for 3GPP IP-CAN type, for Trusted WLAN access (S2a) or untrusted WLAN (S2b) as defined in in clause 6.2.3 of TS 23.203.
The reporting of communication failure refers to the reporting of RAN/NAS release cause codes according to TS 23.401, TS 23.060, and TWAN/UWAN release causes according to TS 23.402. Once the RAN/NAS or TWAN/UWAN release cause codes are reported to the PCRF, the PCRF reports it to the SCEF according to TS 23.203 for applicable IP-CAN types and RAT types listed in TS 23.203.
Monitoring Events via the PCRF also enable the SCEF to request the location information of a group of UEs via Nt interface.
The procedure for requesting monitoring of a group of UEs via the PCRF is described in clause 5.6.4.1a. Group monitoring requests are sent by the SCEF to each PCRF in the operator's network.
The procedure for reporting the location information for a group of UEs is performed for each UE that has an IP-CAN session established at the time the SCEF requests the UE location for a group of UEs as described in clause 5.6.4.2.
The UE location information, provided over Nt, may include a time stamp to indicate when the UE was last-known to be in that location, i.e. if the current location or the last-known location is provided. The UE location information is provided for 3GPP IP-CAN type, for Trusted WLAN access (S2a) or untrusted WLAN (S2b).
Up

4.5.6.4Void


Up   Top   ToC