Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 24.229  Word version:  19.0.0

Top   Top   Up   Prev   Next
1…   3…   4…   4.5…   5…   5.1.1.4…   5.1.2…   5.1.4…   5.2…   5.2.3…   5.2.6…   5.2.7…   5.3…   5.4…   5.4.1.2.2…   5.4.1.3…   5.4.2   5.4.3…   5.4.3.3…   5.4.4…   5.5…   5.7…   5.7.2…   5.8…   5.11…   6…   6.6…   7…   7.2A…   7.2A.6…   7.3…   7.9A…   8…   A…   A.2…   A.2.1.4…   A.2.1.4.7…   A.2.1.4.8…   A.2.1.4.10A…   A.2.1.4.12…   A.2.2…   A.2.2.4…   A.2.2.4.7…   A.2.2.4.8…   A.2.2.4.10A…   A.2.2.4.12…   A.3…   A.3.3…   B…   C…   E…   F…   H…   I…   K…   L…   L.2A…   M…   N…   O…   Q…   R…   S…   U…   U.2A…   V…   W… 
E IP-Connectivity Access Network specific concepts when using xDSL, Fiber or Ethernet to access IM CN subsystem  E.1 Scope  E.2 Fixed broadband aspects when connected to the IM CN subsystem  E.2A Usage of SDP  E.3 Application usage of SIP  E.4 3GPP specific encoding for SIP header field extensions  E.5 Use of circuit-switched domain 
...

 

E (Normative)  IP-Connectivity Access Network specific concepts when using xDSL, Fiber or Ethernet to access IM CN subsystem |R7|  p. 831

E.1  Scope  p. 831

The present annex defines IP-CAN specific requirements for a call control protocol for use in the IP Multimedia (IM) Core Network (CN) subsystem based on the Session Initiation Protocol (SIP), and the associated Session Description Protocol (SDP), where the IP-CAN is xDSL, Fiber or Ethernet.

E.2  Fixed broadband aspects when connected to the IM CN subsystem  p. 831

E.2.1  Introduction  p. 831

A UE accessing the IM CN subsystem, and the IM CN subsystem itself, utilise the services provided by the fixed-broadband access network to provide packet-mode communication between the UE and the IM CN subsystem.
Requirements for the IP Edge node, defined in ETSI ES 282 001 [138] in support of this communication are outside the scope of this document and specified elsewhere.
From the UEs perspective, it is assumed that one or more IP-CAN bearer(s) are provided, in the form of connection(s) managed by the layer 2 (e.g. DSL modem supporting the UE).
In the first instance, it is assumed that the IP-CAN bearer(s) is (are) statically provisioned between the UE and the IP Edge node, defined in ETSI ES 282 001 [138], according to the user's subscription.
It is out of the scope of the current Release to specify whether a single IP-CAN bearer is used to convey both signalling and media flows, or whether several PVC connections are used to isolate various types of IP flows (signalling flows, conversational media, non conversational media…).
The end-to-end characteristics of the fixed-broadband IP-CAN bearer depend on the type of access network, and on network configuration. The description of the network PVC termination (e.g., located in the DSLAM, in the BRAS…) is out of the scope of this annex.
Up

E.2.2  Procedures at the UE  p. 831

E.2.2.1  Activation and P-CSCF discovery  p. 831

Fixed-broadband bearer(s) is (are) statically provisioned in the current Release.
Unless a static IP address is allocated to the UE, prior to communication with the IM CN subsystem, the UE shall perform a Network Attachment procedure depending on the used fixed-broadband access type. When using a fixed-broadband access, both IPv4 and IPv6 UEs may access the IM CN subsystem. The UE may request a DNS Server IPv4 address(es) via RFC 2132 or a DNS Server IPv6 address(es) via RFC 3315.
The methods for P-CSCF discovery are:
  1. When using IPv4, employ the Dynamic Host Configuration Protocol (DHCP) RFC 2132, the DHCPv4 options for SIP servers RFC 3361, and RFC 3263 as described in subclause 9.2.1. When using IPv6, employ Dynamic Host Configuration Protocol for IPv6 (DHCPv6) RFC 3315, the DHCPv6 options for SIP servers RFC 3319 and DHCPv6 options for Domain Name Servers (DNS) RFC 3646 as described in subclause 9.2.1. In case the DHCP server provides several P-CSCF addresses or FQDNs to the UE, the UE shall select the P-CSCF address or FQDN as indicated in RFC 3319. If sufficient information for P-CSCF address selection is not available, selection of the P-CSCF address by the UE is implementation specific.
  2. The UE selects a P-CSCF from the list in the IMS management object as specified in TS 24.167.
The UE shall use method II to select a P-CSCF if the IMS management object contains the P-CSCF list. Otherwise, the UE shall use method I to select a P-CSCF.
Up

E.2.2.1A  Modification of a fixed-broadband connection used for SIP signalling  p. 832

Not applicable.

E.2.2.1B  Re-establishment of a fixed-broadband connection used for SIP signalling  p. 832

Not applicable.

E.2.2.1C  P-CSCF restoration procedure |R9|  p. 832

A UE supporting the P-CSCF restoration procedure uses the keep-alive procedures described in RFC 6223.
If the P-CSCF fails to respond to keep-alive requests the UE shall acquire a different P-CSCF address using any of the methods described in the subclause E.2.2.1 and perform an initial registration as specified in subclause 5.1.
Up

E.2.2.2  Void

E.2.2.3  Void

E.2.2.4  Void

E.2.2.5  Fixed-broadband bearer(s) for media  p. 832

E.2.2.5.1  General requirements  p. 832
The UE can establish media streams that belong to different SIP sessions on the same fixed-broadband bearer.
E.2.2.5.1A  Activation or modification of fixed-broadband bearers for media by the UE  p. 832
If the UE receives indication within the SDP according to RFC 3524 that media stream(s) belong to group(s), and if several fixed-broadband bearers are available to the UE for the session, the media stream(s) may be sent on separate fixed-broadband bearers according to the indication of grouping. The UE may freely group media streams to fixed-broadband bearers in case no indication of grouping is received from the P-CSCF.
If the UE receives media grouping attributes in accordance with RFC 3524 that it cannot provide within the available fixed-broadband bearer(s), then the UE shall handle such SDP offers in accordance with RFC 3388.
The UE can receive a media authorization token in the P-Media-Authorization header field from the P-CSCF according to RFC 3313. If a media authorization token is received in the P-Media-Authorization header field when a SIP session is initiated, the UE shall reuse the existing fixed-broadband bearer(s) and ignore the media authorization token.
Up
E.2.2.5.1B  Activation or modification of fixed-broadband bearers for media by the network  p. 832
Not applicable.
E.2.2.5.1C  Deactivation of fixed-broadband bearers for media |R11|  p. 833
Not applicable.
E.2.2.5.2  Special requirements applying to forked responses  p. 833
Since the UE is unable to perform bearer modification, forked responses place no special requirements on the UE.
E.2.2.5.3  Unsuccessful situations  p. 833
Not applicable.

E.2.2.6  Emergency service  p. 833

E.2.2.6.1  General |R14|  p. 833
If attached to network via fixed-broadband access technology, the UE shall always consider being attached to its home operator's network for the purpose of emergency calls.
Up
E.2.2.6.1A  Type of emergency service derived from emergency service category value |R15|  p. 833
Not applicable.
E.2.2.6.1B  Type of emergency service derived from extended local emergency number list |R15|  p. 833
Not applicable.
E.2.2.6.2  eCall type of emergency service |R14|  p. 833
The UE shall not send an INVITE request with Request-URI set to "urn:service:sos.ecall.manual" or "urn:service:sos.ecall.automatic".
E.2.2.6.3  Current location discovery during an emergency call |R14|  p. 833
Void.

E.2A  Usage of SDP |R8|  p. 833

E.2A.0  General |R9|  p. 833

Not applicable.

E.2A.1  Impact on SDP offer / answer of activation or modification of xDSL bearer for media by the network  p. 833

Not applicable.

E.2A.2  Handling of SDP at the terminating UE when originating UE has resources available and IP-CAN performs network-initiated resource reservation for terminating UE  p. 834

Not applicable.

E.2A.3  Emergency service |R11|  p. 834

No additional procedures defined.

E.3  Application usage of SIP  p. 834

E.3.1  Procedures at the UE  p. 834

E.3.1.0  Registration and authentication |R12|  p. 834

In order to reach IMS in some access networks, the UE may support:
  • address and/or port number conversions provided by a NA(P)T or NA(P)T-PT as described in Annex F and Annex K; and
  • UE requested FTT-IMS establishment procedure specified in TS 24.322.
If a UE supports one or both of these capabilities then a UE may progressively try them to overcome failure to reach the IMS. Use of these capabilities shall have the following priority order:
  1. UE uses neither capability because reaching the IMS without an intervening NA(P)T, NA(P)T-PT, or tunnel is preferred.
  2. UE may use address and/or port number conversions provided by a NA(P)T or NA(P)T-PT as described in either Annex F or Annex K.
  3. UE may use the UE requested FTT-IMS establishment procedure specified in TS 24.322. If the UE uses the UE-requested FTT-IMS establishment procedure specified in TS 24.322, the UE considers itself to:
    • be configured to send keep-alives;
    • be directly connected to an IP-CAN for which usage of NAT is defined; and
    • be behind a NAT.
Optional procedures apply when the UE is supporting traversal of restrictive non-3GPP access network using STUN/TURN/ICE, as follows:
  1. the protection of SIP messages is provided by utilizing TLS as defined in TS 33.203;
  2. the mechanisms specified in this Annex shall only be applicable when the IP traffic to the IMS core does not traverse through the Evolved Packet Core (EPC);
  3. the UE shall establish the TLS connection to the P-CSCF on port 443 as defined in TS 33.203. The UE shall use SIP digest with TLS for registration as specified in subclause 5.1. If the TLS connection is established successfully, the UE sends SIP signalling over the TLS connection to the P-CSCF;
  4. the UE shall support the keep-alive procedures described in RFC 6223;
  5. the procedures described in subclause K.5.2 apply with the additional procedures described in the present subclause;
  6. when using the ICE procedures for traversal of restrictive non-3GPP access network, the UE shall support the ICE TCP as specified in RFC 6544 and TURN TCP as specified in RFC 6062.
  7. if the UE is configured to use TURN over TCP on port 80, the UE shall establish the TCP connection to TURN server on port 80. If the UE is configured to use TURN over TLS on port 443, the UE shall establish the TLS connection to the TURN server on port 443 as defined in TS 33.203. If the UE is configured to use both, the UE should prefer to use TURN over TCP on port 80 to avoid TLS overhead;
  8. if the connection is established successfully, the UE sends TURN control messages and media packets over the connection as defined in RFC 5766.
Up

E.3.1.0a  IMS_Registration_handling policy |R15|  p. 835

Not applicable.

E.3.1.1  P-Access-Network-Info header field  p. 835

The UE may, but need not, include the P-Access-Network-Info header field where indicated in subclause 5.1.

E.3.1.1A  Cellular-Network-Info header field |R13|  p. 835

Not applicable.

E.3.1.2  Availability for calls |R8|  p. 835

Not applicable.

E.3.1.2A  Availability for SMS |R11|  p. 835

Void.

E.3.1.3  Authorization header field |R10|  p. 835

When using SIP digest or SIP digest without TLS, the UE need not include an Authorization header field on sending a REGISTER request, as defined in subclause 5.1.1.2.1.
Up

E.3.1.4  SIP handling at the terminating UE when precondition is not supported in the received INVITE request, the terminating UE does not have resources available and IP-CAN performs network-initiated resource reservation for the terminating UE |R10|  p. 836

Not applicable.

E.3.1.5  3GPP PS data off |R14|  p. 836

Not applicable.

E.3.1.6  Transport mechanisms |R15|  p. 836

No additional requirements are defined.

E.3.1.7  RLOS |R16|  p. 836

Not applicable.

E.3.2  Procedures at the P-CSCF  p. 836

E.3.2.0  Registration and authentication |R12|  p. 836

The P-CSCF may support UEs connected via restrictive non-3GPP access network.
If the P-CSCF supports UEs connected via restrictive non-3GPP access network, when the P-CSCF receives a 200 (OK) response to a REGISTER request, if the contact address of REGISTER request contains an IP address assigned by the EFTF, and the UE's Via header field contains a "keep" header field parameter, then the P-CSCF shall add a value to the "keep" header field parameter of the UE's Via header field of the 200 (OK) response as defined in RFC 6223.
Optional procedures apply when the P-CSCF is supporting traversal of restrictive non-3GPP access network using STUN/TURN/ICE, as follows:
  1. the protection of SIP messages is provided by utilizing TLS as defined in TS 33.203;
  2. the P-CSCF supporting these additional procedures should use SIP digest with TLS as defined in subclause 5 and the P-CSCF should inserts an IMS-ALG on the media plane;
  3. the mechanisms specified in this annex shall only be applicable when the IP traffic to the IMS core does not traverse through the Evolved Packet Core (EPC);
  4. the P-CSCF shall support the procedures defined in subclause 5.2, with the exception that the P-CSCF shall use SIP over TLS on port 443 as defined in TS 33.203;
  5. when the UE has indicated support of the keep-alive mechanism defined in RFC 6223, the P-CSCF shall indicate to the UE that it supports the keep-alive mechanism; and
  6. the IMS-ALG in the P-CSCF shall support ICE procedures, as defined in subclause 6.7.2.7.
Up

E.3.2.1  Determining network to which the originating user is attached  p. 837

In order to determine from which network the request was originated the P-CSCF shall check if the location information received in the network provided and/or UE provided "dsl-location", "eth-location" or "fiber-location" parameter in the P-Access-Network-Info header field(s) belongs to a location in the same country.
Up

E.3.2.2  Location information handling  p. 837

Upon receipt of an initial request for a dialog or standalone transaction or an unknown method, the P-CSCF based on local policy may include a P-Access-Network-Info header field.The value of the "dsl-location", "eth-location" or "fiber-location" parameter shall be the value as received in the Location-Information header in the User-Data Answer command as specified in ETSI ES 283 035 [98].
Up

E.3.2.3  Void

E.3.2.4  Void

E.3.2.5  Void

E.3.2.6  Resource sharing |R13|  p. 837

Not applicable.

E.3.2.7  Priority sharing |R13|  p. 837

Not applicable.

E.3.2.8  RLOS |R16|  p. 837

Not applicable.

E.3.3  Procedures at the S-CSCF |R8|  p. 837

E.3.3.1  Notification of AS about registration status  p. 837

Not applicable

E.3.3.2  RLOS |R16|  p. 837

Not applicable.

E.4  3GPP specific encoding for SIP header field extensions  p. 838

E.4.1  Void

E.5  Use of circuit-switched domain |R8|  p. 838

There is no CS domain in this access technology.

Up   Top   ToC