J  Dynamic User Allocation to the Application Servers |R7|  Word‑p. 254

J.1  General

The complexity of operating a network increases with the number of supported subscribers, and one contributor will be the management of allocating subscribers to the application servers for the same set of services, where there is a requirement for a user to be assigned to an application servers longer than the duration of one session. This would occur when there is data which is to be retained together with the processing resources longer than a single session.

Possible solutions described below do not require impacts on the stage 3 specifications.

J.2  Representative AS

J.2.1  Concept of Representative AS

The Representative AS is the application server which allocates the user to the application servers and keeps the user allocation information and relevant data for the service during the duration of a session or longer than that. The incoming call for the service is received and forwarded to the allocated application server by the Representative AS.

The following points are considered as requirements for the dynamic user allocation procedures using the representative AS.

• The representative AS for each service is the initial contact point for all signalling. This can include ISC; and for example, Ut; and others signalling that may or may not be defined in 3GPP.
• For the ISC, the representative AS is included in every message which opens a new dialogue. It is not included after the initial transaction.
• For example, when the AS is to be invoked by evaluating the iFC at the S-CSCF, the address in the iFC is the address of the Representative AS.

The following figure shows an example service deployment for three different services using the representative AS.

(not reproduced yet)

Figure J.2.1: Dynamic User Allocation using Representative AS

J.2.2  Procedures related to Representative AS  Word‑p. 255

(not reproduced yet)

Figure J.2.2: Bypassing Representative AS procedure

Procedure is as follows:

Step 1.

The initial SIP INVITE request is sent to S-CSCF to create a new dialogue.

Step 2.

The SIP INVITE request is forwarded to the Representative AS according to the service logic, e.g., iFC evaluation at the S-CSCF.

Step 3.

The Representative AS retrieves the user allocation information and forwards the SIP INVITE request to the AS#1 according to the allocation information. If there is no allocated AS for the user, the Representative AS allocates one.

Step 4.

The SIP INVITE request is forwarded to the AS#1. Note that the Representative AS does not record-route itself.

Step 5-7.

The SIP INVITE request is processed and results in the 200 OK response.

Step 8.

The subsequent SIP INVITE request in the same dialog is sent to the S-CSCF.

Step 9.

The SIP INVITE request is forwarded directly to the AS#1 according to the Route information in the request message.

Step 10-11.

The SIP INVITE request is processed and results in the 200 OK response.

J.3  Dynamic assignment of AS by S-CSCF caching

J.3.1  Concept of Dynamic assignment of AS by S-CSCF caching

The proposed solution "Dynamic assignment of AS by S-CSCF caching" is based on standard SIP session control combined with a new S-CSCF caching functionality. This solution is re-using the DNS (RFC 1035) mechanism, and supports only the ISC interface.

J.3.2  Procedures related to Dynamic assignment of AS by S-CSCF caching  Word‑p. 256

Figure J.3.2.1 shows the procedure for allocating an AS by the first request of a service to an IMS registered user:

(not reproduced yet)

Figure J.3.2.1: Assignment of AS via DNS query during first service request

Step 1.

After IMS registration a user sends an initial request to the S-CSCF for requesting a service (served by an AS).

Step 2.

The S-CSCF performs the DNS query on the server name and resolves one (or a prioritised list) of the IP address(es), which represents a physical or logical AS.

Step 3.

The S-CSCF caches the IP address of the assigned AS and stores it during the IMS registration period of the user.

Step 4.

The S-CSCF routes the request to the assigned AS. (Depending on the service the AS could read/write/store user data, e.g., using Sh interface).

Figure J.3.2.2 shows how subsequent service requests are routed directly to the assigned AS during the registration period of the IMS user:

(not reproduced yet)

Figure J.3.2.2: S-CSCF has stored assigned AS for following service requests

Step 5.

The IMS user requests the service again and sends an initial request to the S-CSCF.

Step 6.

The S-CSCF has stored the IP Address (or a prioritised list) of the assigned AS. There is no longer need to perform a DNS query.

Step 7.

The S-CSCF routes the request to the assigned AS. (Depending on the service the AS can reuse prior stored user data).

The AS pre-assignment and storage could be also done after downloading the service profile during the user registration procedure.

K (Normative)  Inter-IMS Network to Network Interface between two IM CN subsystem networks |R8|  Word‑p. 257

K.1  General

This annex describes the Inter-IMS Network to Network Interface which is used to interconnect two IM CN subsystem networks.

K.2  Overall architecture

Figure K.1 illustrates an high-level architecture diagram showing the Inter-IMS Network to Network Interface (II-NNI) between two IM CN subsystem networks.

(not reproduced yet)

Figure K.1: Inter-IMS Network to Network Interface between two IM CN subsystem networks

The protocols over the two reference points Ici and Izi make up the Inter-IMS Network to Network Interface.

The Ici reference point allows IBCFs to communicate with each other in order to provide the communication and forwarding of SIP signalling messaging between IM CN subsystem networks. The Izi reference point allows TrGWs to forward media streams between IM CN subsystem networks.

---