Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.228  Word version:  19.1.0

Top   Top   Up   Prev   Next
1…   3…   4…   4.2.4…   4.3…   4.4…   4.13…   4.16…   5…   5.2…   5.3…   5.4…   5.4.7…   5.4.8…   5.4a…   5.5…   5.5.3…   5.6…   5.6.3…   5.7…   5.7.3…   5.7.5…   5.7.8…   5.8…   5.10…   5.11…   5.11.3…   5.11.3.3   5.11.3.4   5.11.4…   5.11.5…   5.11.5.3…   5.11.6…   5.12…   5.16…   5.16.2…   5.19…   5.20…   A…   E…   E.2.2…   G…   G.5…   H   I…   J…   K…   L…   M…   M.3…   N…   P…   Q…   Q.2.5…   R…   S…   T…   U…   U.2…   V…   W…   X…   Y…   Z…   AA…   AA.3…   AB…   AC…   AC.7…   AC.7.2…   AC.7.2.2   AC.7.2.3…   AC.7.4…   AC.7.9…   AC.7.9.3…   AC.7.10…   AC.7.10.4.2…   AC.9…   AC.10…   AC.11…   AD…   AE…   AF…   AG…

 

AD (Normative)  Subscribe/Notify Framework for Event Monitoring in IMS |R19|p. 426

AD.1  Generalp. 426

This Annex describes the Subscribe/Notify framework to support event monitoring in the IMS architecture. The framework enables third party AF and network functions to subscribe to IMS DC events.
IMS event exposure for event monitoring allows a consumer (e.g. a DC AS) to subscribe to and being notified about subscriber specific and non-subscriber specific IMS events and to invoke IMS services exposed by the IMS network via the NEF.
A subscriber specific event monitoring request includes the targeted subscribers. The targeted subscribers can be either one distinct subscriber or multiple subscribers indicated by their IMS public user identities. The events in the subscriber specific event monitoring request are common to all targeted subscribers. The NEF sends one event subscription request per targeted subscriber to the HSS serving the given subscriber. The NEF may determine the serving HSS based on configuration or based on HSS discovery as depicted in clause AA.3.3.
A non-subscriber specific event monitoring request does not contain any target subscriber. Non-subscriber specific event monitoring requests are sent by the NEF directly to all IMS AS instances which support monitoring of the requested IMS event. The NEF may be configured with available IMS AS instances, or the NEF can discover IMS AS instances via NRF.
Once an IMS subscriber successfully registers in IMS, and one of the IMS AS is assigned to the subscriber, the IMS AS which supports monitoring of IMS events registers its address in the HSS.
For subscriber specific event monitoring requests received from the AF (e.g. DC AS), the NEF uses Nhss_ImsEE service to manage the subscription requests (e.g. subscribe/unsubscribe) via HSS. HSS uses Nimsas_ImsEE service to manage the subscriber specific subscription requests with the IMS AS assigned to the subscriber.
Up

AD.2  Architecture and functionsp. 426

AD.2.1  Architecturep. 426

Figure AD.2.1-1 depicts the Subscribe/Notify framework for event monitoring in IMS. The framework supports trusted and untrusted AFs.
Copy of original 3GPP image for 3GPP TS 23.228, Fig. AD.2.1-1: Subscribe/Notify Framework for event monitoring in IMS
Up

AD.2.2  Reference pointsp. 427

The following service-based reference points support the IMS subscribe/notify framework:
  • N33: Reference point between AF and NEF.
  • N91: Reference point between NEF and HSS.
  • N92: Reference point between IMS AS and NEF.
  • N71/Sh: Reference point between IMS AS and HSS.

AD.2.3  Functional Entitiesp. 427

AD.2.3.1  NEFp. 427

The NEF, in addition to its role as defined TS 23.502, is the entry point for subscriptions to notifications for monitoring of IMS related events, via N33 reference point using the Nnef_ImsEE_Subscribe service operation.
An incoming subscription request to the NEF for a subscriber specific event may include a single IMS subscriber or a list of IMS subscribers. The NEF initiates an individual subscription request to the HSS instance corresponding to each IMS subscriber included in the incoming subscribe request from the AF.
NEF initiates a subscription request for subscriber specific events towards HSS via N91 reference point using the Nhss_ImsEE_Subscribe service operation.
NEF initiates a subscription request for non-subscriber specific events towards applicable IMS AS instances via N92 reference point using the Nimsas_ImsEE service.
NEF receives notifications corresponding to subscribed IMS events from the applicable IMS AS instances via N92 reference point using the Nimsas_ImsEE_Notify service operation. NEF sends the received notifications to the requesting AFs via N33 reference point using the Nnef_ImsEE_Notify service operation.
Up

AD.2.3.2  HSSp. 428

HSS handles subscriptions to IMS DC events related to registered and unregistered IMS subscribers and ensures that a subscription is persistent when UE registers, deregisters and re-registers in IMS.
HSS receives subscription requests for subscriber specific events from NEF via N91 reference point using the Nhss_ImsEE_Subscribe service operation.
HSS stores the incoming subscription request and sends the subscription request to the IMS AS instance supporting the requested event and assigned to the IMS subscriber via N71 reference point, using the Nimsas_ImsEE_Subscribe service operation, or via Sh reference point.
The IMS AS assigned to an IMS subscriber is registered in HSS via N71 reference point using the Nhss_ImsUECM_Registration service operation, or via Sh reference point. If the IMS subscriber in the incoming subscription request is not registered, HSS ensures that when the IMS subscriber registers, any pending subscription request is sent to the applicable IMS AS instance assigned to the IMS subscriber. IMS AS rejects subscriptions to IMS DC events for a subscriber that is not subscribed to IMS DC service.
HSS ensures that corresponding notifications are directly sent to the NEF as subscribing entity, and not via HSS.
Up

AD.2.3.3  IMS ASp. 428

Once an IMS subscriber successfully registers in IMS, any DC supporting IMS AS allocated to the subscriber that supports monitoring of IMS events shall register in HSS its IMS AS instance via N71 reference point using the Nhss_ImsUECM_Registration service operation, or via Sh reference point.
The IMS AS receives subscription requests from HSS related to supported subscriber specific IMS DC events via the N71 reference point using the Nimsas_ImsEE_Subscribe service operation, or via the Sh reference point. IMS AS also receives subscription requests from NEF related to non-subscriber specific events via the N92 reference point using the Nimsas_ImsEE service operation.
IMS AS sends notification events directly to the NEF as subscribing entity included in the subscription request via N92 reference point using the Nimsas_ImsEE_Notify service operation.
Up

AD.2.4  Determination of IMS Events supported by an IMS ASp. 428

The NF profile registered in NRF of an IMS AS that supports monitoring of IMS events may include support for the Nimsas_ImsEE service and related service operations. Additionally, the NF profile of the IMS AS may include the list of IMS events the IMS AS instance supports. NF consumers of the Nimsas_ImsEE service (i.e., HSS and NEF) can make use of this information in the NF profile of the IMS AS to determine the IMS AS instances that support monitoring of a given IMS event.
As an optimization option, a subscriber can subscribe to a number of events in a single subscription. In this case, event filters are applied to each event independently for event detection. Additionally, notification to detected events are handled individually.
Up

AD.2.5  Exposure Eventsp. 428

AD.2.5.1  Generalp. 428

Subscription requests for the notification of an IMS event type may include event filter information, e.g. condition for notifying the event. The event filter depends on the event type. The IMS events and corresponding event filters are only meaningful for the AF and the IMS AS. The involved NF consumer of the IMS AS (e.g. HSS/NEF) determines which IMS AS supports a given IMS event type by matching the IMS event ID requested by the AF with the list of supported IMS event types included in the NF profile of IMS AS registered in the NRF or by implementation means.
Subscription requests for the notification of an IMS event shall include Event Reporting information. The Event Reporting information defines the type of reporting requested (e.g. event reporting mode, number of reports, maximum duration of reporting). The contents of the Event Reporting Information along with the presence requirement of each information element is described in Table 4.15.1-1 of TS 23.502.
Up

AD.2.5.2  Event Monitoringp. 429

Table AD.2.5.3-1 enumerates the IMS DC exposure events and their detection criteria:
Event Description and Detection criteria Which NF detects the event
Bootstrap Data Channel establishedDetected when a Bootstrap data channel is established. Network detects that a Bootstrap data channel is established when the SDP for an established IMS DC includes the media for a Bootstrap data channel with the corresponding Bootstrap DC stream ID according to TS 26.114.IMS AS
Bootstrap Data Channel ReleaseDetected when an established Bootstrap data channel is released. Network detects that a Bootstrap data channel is released when an IMS DC that includes an SDP with the media for a Bootstrap data channel with the corresponding Bootstrap DC stream ID according to TS 26.114 is released, or an IMS DC is updated to remove the media for a Bootstrap data channel with the corresponding Bootstrap DC stream ID according to TS 26.114.IMS AS
Application Data Channel establishedDetected when an Application Data Channel is established.
Network detects that an Application data channel is established when the SDP for an established IMS DC includes the media for an Application data channel with the corresponding Application DC stream ID according to TS 26.114. The Application DC stream ID can be explicit or any stream ID.
IMS AS
Application Data Channel ReleaseDetected when an Application data channel is released.
Network detects that an Application data channel is released when an IMS DC that includes an SDP with the media for an Application data channel with the corresponding Application DC stream ID according to TS 26.114 is released, or an IMS DC is updated to remove the media for an Application data channel with the corresponding Application DC stream ID according to TS 26.114.
IMS AS
Application Data Channel requires interworking is establishedDetected when an Application Data Channel requires interworking is in the process of establishment.
Network detects that an P2A Application data channel is in process of establishment and the MDC2 resources are assigned for the Application data channel.
IMS AS
Event Filters are used to specify the conditions to match for notifying the events (i.e. "List of Parameter values to match"). If there are no conditions to match for a specific Event ID, then the Event Filter is not provided. The following list provides an example how the conditions to match for event reporting can be specified for various Event IDs for IMS DC exposure events:
  • Calling ID: Identifies the public identity of calling subscriber in the targeted IMS session if present.
  • Called ID: Identifies the public identity of called subscriber in the targeted IMS session if present.
  • Media Information Set: If present, includes a set of media information indicating how the media used in the created targeted session for the selected event. Each media information contains:
    • Media Type: It indicates the media type used in the created session, e.g., Data Channel.
    • Media Parameter: It indicates the related media parameters. Different media, includes different parameters.
      • When the Media Type is Data Channel, it indicates the Data Channel Type (ADC or BDC).
      • When the Data Channel Type is BDC, it indicates local or remote, for local UE or for remote UE.
      • When the media type is ADC, Data Channel application binding information is included.
  • Session ID: Indicates the targeted Session ID if present.
Up

AD.3  Subscribe/Notify Procedures for Event Monitoring in IMSp. 430

AD.3.1  IMS AS instance Registration in HSSp. 430

Figure AD.3.1-1 depicts a signalling flow diagram for an IMS AS registering in HSS the IMS AS instance assigned to a registering UE.
Copy of original 3GPP image for 3GPP TS 23.228, Fig. AD.3.1-1: IMS AS Instance Registration in HSS
Figure AD.3.1-1: IMS AS Instance Registration in HSS
(⇒ copy of original 3GPP image)
Up
Step 1.
UE performs initial IMS Registration (see clause 5.2).
Step 2.
S-CSCF performs third party Registration with the IMS AS instance assigned to the registering UE.
Step 3.
IMS AS assigned to the UE/IMPU registers in HSS using Nhss_ImsUECM_Registration service operation or using Sh interface.

AD.3.2  Subscribe/Notify Procedure for subscriber specific IMS eventsp. 430

Figure AD.3.2-1 depicts a signalling flow diagram for establishing a subscription for notification of a subscriber specific IMS event.
Copy of original 3GPP image for 3GPP TS 23.228, Fig. AD.3.2-1: SUBSCRIBE/NOTIFY Procedure for Subscriber specific IMS events
Up
The steps in the call flow are as follows:
Step 1.
UE performs initial IMS Registration as per clause AD.3.1.
Step 2.
AF subscribes to NEF initiating the Nnef_imsEE_Subscribe Request for a subscriber specific IMS event. The AF may include one or more IMS subscriber IDs in the subscription request.
Step 3.
NEF initiates for each IMS subscriber in the incoming subscription request a separate subscription request towards HSS for the requested event via the Nhss_ImsEE_Subscribe Request service operation. The NEF creates a Notification Target address, and Notification Correlation ID and includes it to the Nhss_ImsEE_Subscribe Request.
Step 4.
NEF returns to AF the Nnef_ImsEE_Subscribe Response.
Step 5.
HSS locates the IMS AS instance serving the UE based on the IMS AS registration in HSS executed in step 1. The HSS determines if the IMS AS instance for the IMS subscriber (IMPU) supports the requested IMS event based on the NF profile of the registered IMS AS instances stored in NRF.
If the UE is not IMS registered in HSS, steps 6 and 7 are skipped.
Step 6.
HSS subscribes to the IMS AS instance serving the UE and supporting the requested IMS event, using Nimsas_ImsEE_Subscribe Request for the requested IMS event including the IMPU, and the NEF address as notification endpoint. Alternatively, HSS can use Sh interface to send the requested IMS event to the IMS AS instance assigned to the UE.
Step 7.
IMS AS returns to HSS with the Nimsas_ImsEE_Subscribe Response or returns to HSS via Sh interface.
Step 8.
HSS returns to NEF the Nhss_ImsEE_Subscribe Response.
Step 9.
At some point, the requested event for the UE is detected by the IMS AS.
Step 10.
The IMS AS sends an Nimsas_ImsEE_Notify Request to NEF.
Step 11.
NEF sends to IMS AS Nimsas_ImsEE Notify Response to the IMS AS.
Step 12.
The NEF maps the Notification Correlation ID to the subscription in the NEF. NEF sends Nnef_ImsEE_Notify Request to AF using the Notification Target Address and Notification Correlation ID received in step 2.
Step 13.
The AF sends an Nnef_ImsEE_Notify Response to the NEF.
Up

AD.3.3  Subscribe/Notify Procedure for Non-subscriber specific IMS eventsp. 432

Figure AD.3.3-1 depicts a signalling flow diagram for establishing a subscription for notification of a non-subscriber specific IMS event.
Copy of original 3GPP image for 3GPP TS 23.228, Fig. AD.3.3-1: SUBSCRIBE/NOTIFY Procedure for non-subscriber specific IMS events
Up
The steps in the call flow are as follows:
Step 1.
AF subscribes to NEF initiating the Nnef_imsEE_Subscribe Request for non-subscriber specific IMS event.
Step 2.
NEF returns to AF the Nnef_ImsEE_Subscribe Response.
Step 3.
NEF locates the IMS AS instances that support the requested IMS event via NRF or by local configuration.
Step 4.
For each IMS AS instance that supports the requested IMS event, NEF subscribes to the IMS AS using Nimsas_ImsEE_Subscribe Request for the requested IMS event.
Step 5.
IMS AS returns to NEF the Nnef_ImsEE_Subscribe Response.
Step 6.
At some point, the requested event for the UE is detected by the IMS AS.
Step 7.
The IMS AS sends an Nimsas_ImsEE_Notify Request to NEF.
Step 8.
NEF sends to IMS AS Nimsas_ImsEE Notify Response.
Step 9.
NEF sends Nnef_ImsEE_Notify Request to AF.
Step 10.
The AF sends an Nnef_ImsEE_Notify Response to the NEF.
Up

Up   Top   ToC