8.30 Subscription to the MWI event package / 5GS

34.229-53GPPInternet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)Part 5: Protocol conformance specification using 5G System (5GS)Release 16TSUser Equipment (UE) conformance specification

8.30.1 Test Purpose (TP)

(1)

with { UE being configured to subscribe to MWI }

ensure that {

when { UE registers to IMS }

then { UE subscribes to MWI and to reg event }

}

(2)

with { UE being registered to MWI and reg event }

ensure that {

when { UE receives initial NOTIFY for MWI }

then { UE sends 200 OK }

}

(3)

with { UE being registered to MWI and reg event }

ensure that {

when { UE receives second NOTIFY for MWI indicating one voice message waiting }

then { UE sends 200 OK }

}

(4)

with { UE being registered to MWI and reg event }

ensure that {

when { UE receives NOTIFY for reg event }

then { UE sends 200 OK }

}

8.30.2 Conformance Requirements

The conformance requirements covered in the present test case are, unless otherwise stated, Rel-15 requirements.

[TS 24.606, clause 4.1]:

The Message Waiting Indication (MWI) service enables the network, upon the request of a controlling user to indicate to the receiving user, that there is at least one message waiting.

[TS 24.606, clause 4.6]:

The application/simple-message-summary MIME type used to provide Message Summary and Message Waiting Indication Information is defined in subclause 5 of RFC 3842 [3].

The coding of the message types in the message-context-class values is defined in the specifications listed in the "reference" column of table 1.

Table 1: Coding requirements

Value	Reference
voice-message	RFC 3458 [5]
video-message	RFC 3938 [6]
fax-message	RFC 3458 [5]
pager-message	RFC 3458 [5]
multimedia-message	RFC 3458 [5]
text-message	RFC 3458 [5]
none	RFC 3458 [5]

The coding of the additional information about deposited messages in the application/simple-message-summary MIME body is defined in subclause 25 of RFC 3261 [11] for SIP extension-header (subclause 3.5 of RFC 3842 [3]) and follow the rules defined in the specifications listed in the "reference" column of table 2.

Table 2: Additional information

Header	Description	Reference
To:	Indicates the subscriber’s public user identity used by correspondent to deposit a message.	subclause 3.6.3 of RFC 2822 [7]
From:	Indicates the correspondent’s public user identity, if available.	subclause 3.6.2 of RFC 2822 [7]
Subject:	Indicates the topic of the deposited message as provided by correspondent.	subclause 3.6.5 of RFC 2822 [7]
Date:	Indicates the time and date information about message deposit.	subclause 3.6.1 of RFC 2822 [7]
Priority:	Indicates the message priority as provided by correspondent.	RFC 2156 [8]
Message-ID:	Indicates a single unique message identity.	subclause 3.6.4 of RFC 2822 [7]
Message-Context:	Indicates a type or context of message.	RFC 3458 [5]

[TS 24.606, clause 4.7.1]:

The MWI service is immediately activated after the SUBSCRIBE request from the MSUA is successfully processed, see subclause 4.7.2.

The MWI service is deactivated after subscription expiry or after unsuccessful attempt to deliver a notification about message waiting.

[TS 24.606, clause 4.7.2.1]:

When the MSUA intends to subscribe for status information changes of a message account, the MSUA shall generate a SUBSCRIBE request in accordance with RFC 6665 [4] and RFC 3842 [3] and in alignment with the procedures described in 3GPP TS 24.229 [2]. If the UE receives a 489 (Bad Event) response or a 405 (Method Not Allowed) response to the SUBSCRIBE request, the UE shall not re-try the SUBSCRIBE request until de-registration of the public user identity from IMS.

NOTE: 489 (Bad Event) response or 405 (Method Not Allowed) response to the SUBSCRIBE request indicates that MWI is not supported in the network.

The MSUA will address the SUBSCRIBE request to one of the subscriber’s public user identities (see subclause 4.5.1).

The MSUA shall implement the "application/simple-message-summary" content type as described in RFC 3842 [3].

8.30.3 Test description

8.30.3.1 Pre-test conditions

System Simulator:

– 1 NR Cell connected to 5GC, default parameters.

UE:

– UE contains either ISIM and USIM applications or only USIM application on UICC.

– UE is configured to register for IMS after switch on.

– The UE is pre-configured to autonomously subscribe to the Message Waiting Indication package.

– The UE is configured with the public service identity of the message account. (Otherwise the phone is expected to use the public identity of the user when subscribing to the Message Waiting Indication package.)

Preamble:

– The UE is in test state 1N-A (TS 38.508-1 [21]) and processed IMS registration as described in Annex A.2 up to step 4.

8.30.3.2 Test procedure sequence

Table 8.30.3.2-1: Main Behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	Check: Does the UE subscribe to the Message Waiting Indication event package?	–>	SUBSCRIBE	1	P
2	The SS responds SUBSCRIBE with 200 OK	<–	200 OK	–	–
3	The UE subscribes to the registration event package	–>	SUBSCRIBE	–	–
4	The SS responds with 200 OK	<–	200 OK	–	–
5	The SS sends initial NOTIFY for Message Waiting Indication event package	<–	NOTIFY	–	–
6	Check: Does the UE respond the NOTIFY with 200 OK?	–>	200 OK	2	P
7	The SS sends another NOTIFY for Message Waiting Indication event package, now referring to one voice message waiting	<–	NOTIFY	–	–
8	Check: Does the UE respond the NOTIFY with 200 OK?	–>	200 OK	3	P
9	The SS sends initial NOTIFY for registration event package, containing full registration state information for the registered public user identity in the XML body	<–	NOTIFY	–	–
10	Check: Does the UE respond with 200 OK?	–>	200 OK	4	P

8.30.3.3 Specific message contents

Table 8.30.3.3-1: SUBSCRIBE (step 1, table 8.30.3.2-1)

Derivation Path: TS 34.229-1 [2], Annex A.6.1, Conditions A1, A6

Table 8.30.3.3-2: 200 OK for SUBSCRIBE (step 2/4, table 8.30.3.2-1)

Derivation Path: TS 34.229-1 [2], Annex A.1.5, Condition A1

Table 8.30.3.3-3: SUBSCRIBE (step 3, table 8.30.3.2-1)

Derivation Path: TS 34.229-1 [2], Annex A.1.4, Conditions A1, A7

Table 8.30.3.3-4: NOTIFY for Message Waiting Indication package (step 5, table 8.30.3.2-1)

Derivation Path: TS 34.229-1 [2], Annex A.6.2, Condition A1

Table 8.30.3.3-5: 200 OK (step 6/8/10, table 8.30.3.2-1)

Derivation Path: TS 34.229-1 [2], Annex A.3.1, Conditions A5, A11, A22

Table 8.30.3.3-6: NOTIFY for Message Waiting Indication package (step 7/9, table 8.30.3.2-1)

Derivation Path: TS 34.229-1 [2], Annex A.6.2, Condition A1
Header/param	Cond	Value/remark	Rel	Reference
Message-body		Messages-Waiting: yes Message-Account: same IMPU as in From header Voice-Message: 1/0 (0/0) To: <same IMPU as sent by the UE in the From header of the SUBSCRIBE in step 1> From: <user2_public1@home1.net> Subject: call me back! Date: Fri 05 Feb 2021 14:24 +0100 Priority: urgent Message-ID: 27775334485@home domain name Message-Context: voice-message

Table 8.30.3.3-7: NOTIFY for reg-event package (step 8, table 8.30.3.2-1)

Derivation Path: TS 34.229-1 [2], Annex A.1.6, Condition A1