C.4 S-NAPTR procedure pseudo-code with topon
29.3033GPPDomain Name System ProceduresRelease 17Stage 3TS
Collocation, when stated as specifically applicable in a procedure, takes precedence over other criteria such as topological ordering or S-NAPTR ordering. Topological ordering, when stated as specifically applicable in a procedure, takes precedence over S-NAPTR ordering. However, S-NAPTR ordering is used for ordering nodes with equivalent topological distances. Pseudo code below is informative and shows how to implement the ordering of record selection. See clause 4.3.2 for normative text.
Assume two distinct types of nodes "A" and "B" are being checked for closeness and the best record pair is needed. First step, which is documented in each case in the main text of this document is to get two candidate lists using a procedure such as that outlined in clause C.3.
candidate_list_A:= get_candidates (targetFQDN_A,desired_service_and_protocol_set_A, "A");
candidate_list_B:= get_candidates (targetFQDN_B,desired_service_and_protocol_set_B, "B");
As an example take the selection of a PGW and SGW by an MME during a UE initial attach procedure. Both a PGW and SGW need to be selected and if "topon" is used in both lists the selected pair is to be as close as possible (collocated being the closest).
Sometimes one list in the procedure is not found by DNS (or was found previously) because the node was already selected. In that case, one of the candidate lists can be just one node.
For example, an UE with an existing PDN connection adds a new PDN connection to a different APN, which may result in a different PGW but needs to continue using the current SGW. Here one of the two candidate lists would just be the data for the current SGW node (i.e., its node name and whether it supports GTPv2 and/or PMIPv6 for S5/S8).
The following pseudo-code illustrates topological matching with full ordering.
procedure topo_matching (candidate_list_A,candidate_list_B, topology_check, colocation_check)// Comment: topology_check and colocation_check are booleans indicating if those checks are done
Begin procedure
paired_sets_list:=empty;
if (colocation_check)
Begin if
total_list:= candidate_list_A appended with candidate_list B;
// Comment: Below canonical_node_name is the hostname with first two labels removed
Foreach unique canonical_node_name from total_list do
Begin foreach
Foreach servce and protocol do
Begin foreach
full_match_list:= get all records from total_list with service and protocol
and canonical_node name
If there is at least one "A" record and one "B" record in full_match_list then
Begin If
degree:=256;
suffix:=canonical_node_name;
create structure with fields
(degree, suffix,service_and_protocol,full_match_list)
add that structure to paired_sets_list
End If
End foreach
End foreach
End if;
if (topology_check) Begin if
max_labels:= (maximum number of DNS labels in total_list)- 2
else
max_labels =0;
End If;
from number_labels_to_match:= max_labels down to 0 do
Begin do
if number_labels_to_match equals 0 then
Begin if
total_list:= candidate_list_A appended with candidate_list B
else
total_list:= get all records from candidate_list_A and candidate_list_B
with "topon" as first label and hostname has at least
(number_labels_to_match+2) labels
// Comment: Add 2 since the first two labels are not part of the node name End If;
// Comment: Below suffix is a hostname chopped off to include only the last number_labels_to_match
Foreach unique suffix from total_list do
Begin foreach
Foreach servce and protocol do
Begin foreach
full_match_list:= get all records from total_list with service and protocol
and suffix contained in end of the hostname
If there is at least one "A" record and one "B" record in full_match_list then
Begin If
degree:=number_labels
create structure with fields
(degree, suffix,service_and_protocol,full_match_list)
add that structure to paired_sets_list
End If
End foreach
End foreach
End do
sort paired_sets by degree
return (paired_sets_list)
End Procedure;
NOTE 1: Matching collocated nodes get a degree of 256, which is above any normal match. Also the above procedure is specific to this document and is not a part of S-NAPTR.
NOTE 2: Order from S-NAPTR is from one S-NAPTR procedure. There is no meaningful order obtained from S-NAPTR between records from two different S-NAPTR procedures. So one node type will be selected "logically first" based on other criteria outside S-NAPTR information.
The above procedure simply creates a list of records which are sorted by decreasing degree of matching in DNS labels. It also gives the list of paired nodes with the same suffix and compatible service which is needed by the 3GPP application.
Since highest degree is preferred over S-NAPTR ordering with "topon" labels the selection is done by degree starting with the highest degree obtaining only the possible "A" and "B" nodes at that degree. A sublist of the paired_sets_list containing the highest degree is taken from paired_sets_list denoted as degree_sublist. Assume the "A" node is to be selected "logically first". Sort the "A" parts of degree_sublist in increasing "snaptr_output_order". For the records in that order try to connect to the node with the service and protocol in the record using 3GPP procedures. On failure proceed with the next record. When that degree_sublist is exhausted then degree-1 is tried and so on until an "A" node is selected. Once an "A" node is chosen, the procedure has also a selected degree, suffix and service.
NOTE 3: The remaining part of this procedure is not needed if the "B" node was already pre-selected outside the present procedure.
Taking the degree_sublist used to select the "A" node create a new sublist from only records with the same service, same protocol and suffix. Remove the "A" node records from that sublist. Sort this new sublist by increasing "snaptr_output_order" (see clause C.3). Using the records in that order try to connect to the "B" nodes with the service and protocol in the record. On a failure proceed with the next record. When that list is exhausted the procedure continues in next paragraph.
NOTE 4: The suffix of the "A" node that was selected influences which "B" nodes are closest to it. We can’t easily and simply reuse the above structure for that reason and it is easier to "reset" the procedure.
A new candidate_list_A is created consisting only of the selected "A" node A and service_and_protocol. The procedure "topo_matching " is run again giving a new paired_sets_list. The "A" node records are removed from the new paired_sets_list leaving only "B" nodes. Sort the records in paired_sets_list in decreasing order of degree and within degree in increasing "snaptr_output_order" (see clause C.3). Using the records in that order try to connect to the "B" nodes with the service in the record. On failure go to next record.
NOTE 5: Failing to actually contact a node should result in the failing node(s) to be removed from consideration for a period of time. Such removal is not detailed above. Also a reasonable implementation would give up after some maximum number of failed attempts.
Annex D (Informative):
SGSN examples
D.1 Introduction
This annex includes examples of the DNS provisioning needed for an SGSN discovery and selection procedures. Examples are not exhaustive either in scope or in content but are intended to be sufficient to illustrate the general techniques and some of the more important use cases.
D.2 Preconditions
Provisions of annex A.2 apply also here.
D.3 SGSN file
A NAPTR record is required to be provisioned under the NRI-RAI FQDN (see clause 4.3.3.5 of this TS). The format of the NRI-RAI FQDN is nri-sgsn<NRI>.rac<RAC>.lac<LAC>.rac as defined in clause 19.4.2.6 of 3GPP TS 23.003 [4].
The nri-sgsn<NRI>.rac<RAC>.lac<LAC>.rac is also the natural place for the SGSN canonical node record set. For this example we place the SGSN canonical node records and the required record for the lookup at the same location both for simplicity and better DNS caching.
For this example we have two SGSNs with NRI codes of 1 and 2 respectively and both in the same SGSN pool (LAC = 1000 hexadecimal and RAC = 0003 hexadecimal).
;
; This is the P-TMSI and RAI related record and the SGSN node record
; The operator has decided to use the 3GPP name as the canononical node name of the SGSN
; rather than having two records (the 3GPP one and an operator defined value)
;
nri-sgsn01.rac0003.lac1001.rac
; IN NAPTR order pref. flag service regexp replacement
IN NAPTR 200 999 "a" "x-3gpp-sgsn:x-s4" "" topoff.eth1.nri-sgsn01.rac0003.lac1001.rac
IN NAPTR 200 999 "a" "x-3gpp-sgsn:x-s3" "" topoff.eth2.nri-sgsn01.rac0003.lac1001.rac
IN NAPTR 300 999 "a" "x-3gpp-sgsn:x-gn" "" topoff.eth3.nri-sgsn01.rac0003.lac1001.rac
;
; Reminder: Canonical node name records must be complete.
; In most cases the interface type (S3 etc) is functionally determined so the NAPTR order is rarely
; used in this record set. The S3 is preferred over over Gn.
;
; Of course if the SGSN had multiple S3 interfaces
; the operator could provision more than one S3 record with different orders
; perhaps to select S3 IPv6 over S3 IPv4
; We have the same type of records for the other SGSN (same comments would apply)
;
nri-sgsn02.rac0003.lac1001.rac
; IN NAPTR order pref. flag service regexp replacement
IN NAPTR 200 999 "a" "x-3gpp-sgsn:x-s4" "" topoff.eth1.nri-sgsn02.rac0003.lac1001.rac
IN NAPTR 200 999 "a" "x-3gpp-sgsn:x-s3" "" topoff.eth2.nri-sgsn02.rac0003.lac1001.rac
IN NAPTR 300 999 "a" "x-3gpp-sgsn:x-gn" "" topoff.eth3.nri-sgsn02.rac0003.lac1001.rac
;
; All SGSN IP addresses for both SGSNs
;
topoff.eth1.nri-sgsn01.rac0003.lac1001.rac IN A 192.0.2.11
IN A 192.0.2.12
IN AAAA 2001:db8:0:0:0:0:0:0
IN AAAA 2001:db8:0:1:0:0:0:0
topoff.eth2.nri-sgsn01.rac0003.lac1001.rac IN A 192.0.2.13
IN A 192.0.2.14
IN AAAA 2001:db8:0:2:0:0:0:0
IN AAAA 2001:db8:0:3:0:0:0:0
topoff.eth3.nri-sgsn01.rac0003.lac1001.rac IN A 192.0.2.15
IN A 192.0.2.16
IN AAAA 2001:db8:0:4:0:0:0:0
IN AAAA 2001:db8:0:5:0:0:0:0
topoff.eth1.nri-sgsn02.rac0003.lac1001.rac IN A 192.0.2.17
IN A 192.0.2.18
IN AAAA 2001:db8:0:6:0:0:0:0
IN AAAA 2001:db8:0:7:0:0:0:0
topoff.eth2.nri-sgsn02.rac0003.lac1001.rac IN A 192.0.2.19
IN A 192.0.2.20
IN AAAA 2001:db8:0:8:0:0:0:0
IN AAAA 2001:db8:0:9:0:0:0:0
topoff.eth3.nri-sgsn02.rac0003.lac1001.rac IN A 192.0.2.21
IN A 192.0.2.22
IN AAAA 2001:db8:0:10:0:0:0:0
IN AAAA 2001:db8:0:11:0:0:0:0
; end of file
The partially qualified SGSN host names are topoff.eth1.nri-sgsn01.rac0003.lac1001.rac and topoff.eth1.nri-sgsn02.rac0003.lac1001.rac, and similar.
The fully qualified SGSN node names are the relatively long
nri-sgsn01.rac0003.lac1001.rac.epc.mnc990.mcc311.3gppnetwork.org.
and
nri-sgsn02.rac0003.lac1001.rac.epc.mnc990.mcc311.3gppnetwork.org.
which are obtained by appending the value of $ORIGIN to the partially qualified SGSN node names. As stated before we will use the partially qualified names in this Annex to avoid this visual clutter and for typographical reasons.
D.4 Null-NRI/SGSN Group ID file for DCN
A NAPTR record is required to be provisioned under the RAI FQDN (see clause 5.8.3). The format of the RAI FQDN is rac<RAC>.lac<LAC>.rac as defined in clause 19.4.2.5 of 3GPP TS 23.003 [4].
For this example we have two SGSN pools represented by SGSN Group ID (sgsngi=0001) and Null-NRI (null-nri=0005). Each pool has two SGSNs with NRI code of 1, 2 and 3, 4 respectively.
;
rac0003.lac1001.rac
; IN NAPTR order pref. flag service regexp replacement
IN NAPTR 100 999 "a" "x-3gpp-sgsn:x-gn+ue-1.10.20" "" topoff.eth1.nri-sgsn0001.sgsngi0001.rac0003.lac1001.rac
IN NAPTR 200 999 "a" "x-3gpp-sgsn:x-s16+ue-1.10.20" "" topoff.eth3.nri-sgsn0002.sgsngi0001.rac0003.lac1001.rac
IN NAPTR 100 999 "a" "x-3gpp-sgsn:x-gn+ue-2.5" "" topoff.eth1.nri-sgsn0003.null-nri0005.rac0003.lac1001.rac
IN NAPTR 200 999 "a" "x-3gpp-sgsn:x-s16+ue-2.5" "" topoff.eth3.nri-sgsn0004.null-nri0005.rac0003.lac1001.rac
;
;From above records, Null-NRI and SGSN Group ID information can be retrieved when necessary.
Annex E (Informative):
SGW/PGW selection examples using GTP-C load control
E.1 PGW selection using GTP-C load control at node level
This example illustrates the principles of the SGW or PGW selection specified in clause 4A.2, with GTP-C load control supported and enabled at node level.
The example assumes that the procedures specified in this document have 3 candidate PGWs with the same relative order, (e.g. with the same topological order) and assume that the following weights are received from the DNS and "Load Metric" reported via GTP-C signalling:
PGW1: DNS-weight-factor = 20, Load-metric = 10%
PGW2: DNS-weight-factor = 20, Load-metric = 20%
PGW3: DNS-weight-factor = 60, Load-metric= 30%
Based on the above, the selecting node calculates the effective available load for each candidate PGW:
PGW1-effective-available-load = (100 – 10)% X 20 = 18
PGW2-effective-available-load = (100 – 20)% X 20 = 16
PGW3-effective-available-load = (100 – 30)% X 60 = 42
The selecting node then calculates the relative available load of each candidate PGW (rounding-off to nearest integer value):
PGW1-relative-available-load = 18 / (18 + 16 + 42) =~ 24%
PGW2-relative-available-load = 16 / (18 + 16 + 42) =~ 21%
PGW3-relative-available-load = 42 / (18 + 16 + 42) =~ 55%
Out of the total new session requests, the node selects the PGW1, PGW2 and PGW3 for 24%, 21% and 55% respectively, e.g. per 100 new sessions requests, the PGW1 is selected for 24 sessions, PGW2 for 21 sessions and PGW3 for the remaining 55 new sessions.
E.2 PGW selection using GTP-C load control at APN level
E. 2.1 PGW selection when APN load control information is available for each candidate PGW
This example illustrates the principles of the PGW selection specified in clause 4A.3, with GTP-C load control supported and enabled at node level and APN level.
The example assumes that the procedures specified in this document have 3 candidate PGWs with the same relative order, (e.g. with the same topological order) and assume that the following weights are received from the DNS and APN load control information reported via GTP-C signalling:
PGW1: DNS-weight-factor = 20, APN1-Load-metric = 60%, APN1-relative-capacity = 50%
PGW2: DNS-weight-factor = 20, APN1-Load-metric = 50%, APN1-relative-capacity = 20%
PGW3: DNS-weight-factor = 60, APN1-Load-metric= 50%, APN1-relative-capacity = 10%
Based on the above, the APN1-effective-available-load is calculated as follows:
PGW1-APN1-effective-available-load = (100 – 60)% X 50% X 20 = 4
PGW2-APN1-effective-available-load = (100 – 50)% X 20% X 20 = 2
PGW3-APN1-effective-available-load = (100 – 50)% X 10% X 60 = 3
Then the APN1-relative-available-load is calculated as below (by rounding-off to nearest integer value):
PGW1-APN1-relative-available-load = 4 / (4 + 2 + 3) =~ 45%
PGW2-APN1-relative-available-load = 2 / (4 + 2 + 3) =~ 22%
PGW3-APN1-relative-available-load = 3 / (4 + 2 + 3) =~ 33%
Out of the total new session requests for APN1, the PGW1 is selected for 45%, PGW2 for 22% and PGW3 for 33%, e.g. per 100 new sessions requests for APN1, the PGW1 is selected for 45 sessions, PGW2 for 22 sessions and PGW3 for 33 sessions.
E.2.2 PGW selection when APN load control information is not available for each candidate PGW
This example illustrates the principles of the PGW selection specified in clause 4A.3, with GTP-C load control supported and enabled at node level and APN level.
The example assumes that the procedures specified in this document have 3 candidate PGWs with the same relative order, (e.g. with the same topological order) and assume that the following weights are received from the DNS and APN load control information reported via GTP-C signalling; it is assumed in particular that PGW3 did only report APN load control information for the APN2.
PGW1: DNS-weight-factor = 20, APN1-Load-metric = 60%, APN1-relative-capacity = 50%
PGW2: DNS-weight-factor = 20, APN1-Load-metric = 50%, APN1-relative-capacity = 20%
PGW3: DNS-weight-factor = 60, APN2-Load-metric= 50%, APN2-relative-capacity = 30%, PGW3-Load-Metric 40%
Based on the above, the APN1-effective-available-load for the PGW3 is calculated assuming the following:
PGW3-APN1-relative-capacity = 100% – 30% = 70%
PGW3-APN1-load-metric = {40% – (50% X 30%)} / {(100% – 30%)} = {40% – 15%} / {70%} = ~36%
Annex F (Informative):
Examples for AMF Discovery by 5G AN
F.1 Introduction
This annex provides examples of DNS provisioning for AMF Discovery by 5G AN.
F.2 Preconditions
See annex A.2.
F.3 Example of an AMF Region with 2 AMF Sets
F.3.1 Master file
The master file for this example has following content.
$ORIGIN 5gc.mnc990.mcc311.3gppnetwork.org.
;
$TTL 600 ; 10 minutes – this directive is defined in IETF RFC 2308 not IETF RFC 1035
;
$INCLUDE SOA_DB.txt
;
$INCLUDE AMFSET_DB.txt
;
; End of file
F.3.2 SOA and NS records
See Annex A.3.3.
F.3.3 AMF Set file
The file containing the AMF Set records for this example will be AMFSET_DB.txt and has following NAPTR record content.
In this example, we have two AMF Sets 1 and 2, in AMF Region 48 (hexadecimal), with 2 AMFs available in each AMF Set.
; AMF Set 1 of AMF Region 48
set001.region48.amfset
; IN NAPTR order pref. flag service regexp replacement
IN NAPTR 100 999 "a" "x-3gpp-amf:x-n2" "" topoff.amf11.amf
IN NAPTR 100 999 "a" "x-3gpp-amf:x-n2" "" topoff.amf12.amf
; AMF Set 2 of AMF Region 48
set002.region48.amfset
; IN NAPTR order pref. flag service regexp replacement
IN NAPTR 100 999 "a" "x-3gpp-amf:x-n2" "" topoff.amf21.amf
IN NAPTR 100 999 "a" "x-3gpp-amf:x-n2" "" topoff.amf22.amf
; AMFs IP addresses
;
topoff.amf11.amf IN A 192.0.2.11
IN A 192.0.2.12
IN AAAA 2001:db8:0:0:0:0:0:0
IN AAAA 2001:db8:0:1:0:0:0:0
topoff.amf12.amf IN A 192.0.2.13
IN A 192.0.2.14
IN AAAA 2001:db8:0:2:0:0:0:0
IN AAAA 2001:db8:0:3:0:0:0:0
topoff.amf21.amf IN A 192.0.2.17
IN A 192.0.2.18
IN AAAA 2001:db8:0:6:0:0:0:0
IN AAAA 2001:db8:0:7:0:0:0:0
topoff.amf22.amf IN A 192.0.2.19
IN A 192.0.2.110
IN AAAA 2001:db8:0:8:0:0:0:0
IN AAAA 2001:db8:0:9:0:0:0:0
; end of file
Annex G (Informative):
Examples for selecting an alternative PGW-C/SMF in a PGW-C/SMF Set
G.1 Introduction
This annex provides examples of DNS provisioning for selecting an alternative PGW-C/SMF in a PGW-C/SMF Set by an MME (see clause 5.1.4).
G.2 Preconditions
See annex A.2.
G.3 Example of an PGW-C/SMF Set
G.3.1 Master file
The master file in A.3.2 is appended with the following content.
$ORIGIN epc.mnc990.mcc311.3gppnetwork.org.
;
; $TTL 600 ; 10 minutes – this directive is defined in IETF RFC 2308 not IETF RFC 1035
;
; $INCLUDE SOA_DB.txt
;
$INCLUDE PGWSET_DB.txt
;
; End of file
G.3.2 SOA and NS records
See Annex A.3.3.
G.3.3 PGW-C/SMF Set file
The file containing the PGW-C/SMF Set records for this example will be PGWSET_DB.txt and has following NAPTR record content.
; PGW Set 12
set12.pgwset
; IN NAPTR order pref. flag service regexp replacement
IN NAPTR 100 999 "a" "x-3gpp-pgw:x-s5-gtp:x-s8-gtp" "" topoff.vip1.gw01.nodes
IN NAPTR 200 999 "a" "x-3gpp-pgw:x-s5-gtp:x-s8-gtp" "" topoff.vip1.gw21.nodes
; PGWs IP addresses
;
topoff.vip1.gw01.nodes IN A 192.0.2.11
IN A 192.0.2.12
IN AAAA 2001:db8:0:0:0:0:0:0
IN AAAA 2001:db8:0:1:0:0:0:0
topoff.vip1.gw21.nodes IN A 192.0.2.13
IN A 192.0.2.14
IN AAAA 2001:db8:0:2:0:0:0:0
IN AAAA 2001:db8:0:3:0:0:0:0
; end of file
Annex H (Informative):
Change history
|
Date |
TSG # |
TSG Doc. |
CR |
Rev |
Cat |
Subject/Comment |
New |
|
2008-12 |
CT#42 |
CP-080714 |
V2.0.0 approved in CT#42 |
8.0.0 |
|||
|
2009-03 |
CT#43 |
CP-090054 |
0001 |
1 |
DNS examples |
8.1.0 |
|
|
0002 |
2 |
DNS cleanup regarding topon/topoff |
|||||
|
0003 |
1 |
Missing clause for node name records of SGW |
|||||
|
0004 |
1 |
DNS Editorial cleanup |
|||||
|
0005 |
SGW Selection for TAU and Handover |
||||||
|
0007 |
1 |
Correction to DNS procedures |
|||||
|
0008 |
2 |
Clarifications to NAPTR flag usage |
|||||
|
0009 |
1 |
||||||
|
2009-06 |
CT#44 |
CP-090291 |
0010 |
1 |
Home agent discovery |
8.2.0 |
|
|
0011 |
1 |
Correction for PGW selection for colocated PGW/GGSN |
|||||
|
0012 |
1 |
Handling when hostnames are missing topon/topoff |
|||||
|
0013 |
1 |
Release 8 SGSN clarifications |
|||||
|
2009-06 |
CT#44 |
CP-090542 |
0015 |
Incorrect FQDN nodes.mnc<MNC>.mcc<MCC>.3gppnetwork.org |
8.3.0 |
||
|
0017 |
3 |
Failure of DNS procedures |
|||||
|
0018 |
1 |
Correction about discovering and selecting a PGW and SGW |
|||||
|
2009-12 |
– |
– |
– |
– |
Update to Rel-9 version (MCC) |
9.0.0 |
|
|
2010-03 |
CT#47 |
CP-100019 |
0024 |
2 |
APN-FQDN construction |
9.1.0 |
|
|
2010-09 |
CT#49 |
CP-100457 |
0027 |
1 |
Construction of APN-FQDN |
9.2.0 |
|
|
2010-12 |
CT#50 |
CP-100678 |
0030 |
3 |
Add missing MME/SGSN selection for the RIM procedure |
9.3.0 |
|
|
2010-12 |
CT#50 |
CP-100686 |
0029 |
1 |
PGW selection by ePDG with GTP over S2b |
10.0.0 |
|
|
CP-100684 |
0033 |
3 |
SIPTO support in DNS |
||||
|
CP-100684 |
0036 |
2 |
GW selection for SIPTO based on eNodeB id |
||||
|
CP-100693 |
0034 |
Correcting clause numbers in Annex A.3 |
|||||
|
CP-100693 |
0035 |
1 |
Clarifications to DNS Based GW Selection in Roaming Cases |
||||
|
CP-100693 |
0037 |
1 |
Correction in Annex C |
||||
|
2011-03 |
CT#51 |
CP-110057 |
0038 |
2 |
GGSN selection for SIPTO APN |
10.1.0 |
|
|
CP-110057 |
0045 |
2 |
GW selection based on RAI/RNC-ID/TAI/eNodeb ID |
||||
|
CP-110056 |
0039 |
2 |
PGW selection for LIPA |
||||
|
CP-110076 |
0042 |
1 |
Adding SGSN selection cases |
||||
|
CP-110076 |
0044 |
2 |
DNS Service for Sv |
||||
|
CP-110076 |
0047 |
1 |
MME selection |
||||
|
CP-110088 |
0043 |
3 |
DNS procedure for Relay Node OAM system discovery |
||||
|
CP-110059 |
0046 |
Service parameter for the GTP based S2b |
|||||
|
2011-06 |
CT#52 |
CP-110364 |
0051 |
1 |
Services of a MME from MME node name |
10.2.0 |
|
|
CP-110374 |
0049 |
1 |
SGSN Selection |
||||
|
2011-07 |
Editorial correction to history table. |
10.2.1 |
|||||
|
2011-09 |
CT#53 |
CP-110567 |
0056 |
2 |
SGSN selection |
10.3.0 |
|
|
2012-03 |
CT#55 |
CP-120028 |
0058 |
1 |
SGSN selection |
11.0.0 |
|
|
CP-120045 |
0061 |
1 |
PGW discovery for GTP based S2a |
||||
|
2012-06 |
CT#56 |
CP-120234 |
0062 |
2 |
DNS procedure for CS to PS SRVCC |
11.1.0 |
|
|
2012-09 |
CT#57 |
CP-120447 |
0064 |
1 |
PGW selection in eHRPD for SIPTO |
11.2.0 |
|
|
CP-120457 |
0065 |
1 |
SGW selection based on eNodeB ID |
||||
|
2013-06 |
CT#60 |
CP-130378 |
0067 |
1 |
GWs selection for SIPTO at the local network |
12.0.0 |
|
|
2013-09 |
CT#61 |
CP-130453 |
0069 |
2 |
SGW selection for SIPTO at the Local Network |
12.1.0 |
|
|
CP-130462 |
0070 |
2 |
GERAN Iu Mode |
||||
|
2013-12 |
CT#62 |
CP-130620 |
0071 |
1 |
SGW selection for SIPTO at the Local Home Network |
12.2.0 |
|
|
2014-06 |
CT#64 |
CP-140230 |
0076 |
1 |
Cleanup the pre-Release-8 DNS procedure on Release-8 SGSN |
12.3.0 |
|
|
2014-09 |
CT#65 |
CP-140505 |
0077 |
2 |
SGW/PGW selection with GTP-C node level load control |
12.4.0 |
|
|
CP-140505 |
0078 |
2 |
PGW selection with GTP-C APN level Load Control |
||||
|
2014-12 |
CT#66 |
CP-140797 |
0079 |
3 |
MME and SGSN selection by RCAF |
13.0.0 |
|
|
2015-06 |
CT#68 |
CP-150270 |
0080 |
3 |
Multiple IP addresses in DNS Record |
13.1.0 |
|
|
2015-12 |
CT#70 |
CP-150781 |
0082 |
2 |
DNS procedures for Decor |
13.2.0 |
|
|
CP-150765 |
0083 |
– |
Priority ordering of SRV records |
||||
|
2016-03 |
CT#71 |
CP-160038 |
0084 |
1 |
GTP-C Load Control – Mix of NAPTR records with "s" and "a" flags |
13.3.0 |
|
|
CP-160022 |
0085 |
1 |
Clarification on the use of UE Usage Type |
||||
|
CP-160022 |
0086 |
4 |
DNS procedures for Decor |
||||
|
CP-160033 |
0087 |
3 |
Impacts on the DNS procedures for CIoT with introduction of NB-IoT and Non-IP |
||||
|
2016-06 |
CT#72 |
CP-160224 |
0088 |
1 |
MME and SGSN selection procedures for Dedicated Core Networks |
13.4.0 |
|
|
2016-06 |
CT#72 |
CP-160228 |
0089 |
2 |
Clarification on the DNS impact for CIoT |
13.4.0 |
|
|
2016-09 |
CT#73 |
CP-160435 |
0090 |
1 |
Use of DNS to select a GGSN handling Non-IP data |
14.0.0 |
|
|
2016-12 |
CT#74 |
CP-160680 |
0092 |
1 |
Use of DéCOR for NonIP_GPRS |
14.1.0 |
|
|
2016-12 |
CT#74 |
CP-160680 |
0096 |
– |
GW selection by S4-SGSN for Non-IP PDN type |
14.1.0 |
|
|
2016-12 |
CT#74 |
CP-160665 |
0094 |
1 |
DECOR for GPRS Core |
14.1.0 |
|
|
2017-06 |
CT#76 |
CP-171036 |
0097 |
1 |
UP function selection by DNS |
14.2.0 |
|
|
2017-09 |
CT#77 |
CP-172015 |
0099 |
– |
PGW selection for WLAN with deployed DCNs |
14.3.0 |
|
|
2017-09 |
CT#77 |
CP-172020 |
0100 |
– |
Missing CUPS stage 3 reference |
14.3.0 |
|
|
2017-12 |
CT#78 |
CP-173036 |
0104 |
4 |
SGW/PGW selection for NR |
15.0.0 |
|
|
2018-03 |
CT#79 |
CP-180020 |
0107 |
1 |
Correction for indicating DCNR to Combined SGW/PGW |
15.1.0 |
|
|
2018-06 |
CT#80 |
CP-181132 |
0108 |
1 |
Selection of a combined PGW/SMF for interworking with 5GS |
15.2.0 |
|
|
2018-09 |
CT#81 |
CP-182067 |
0109 |
– |
DNS records for selecting a node with a network capability in a Dedidated Core Network |
15.3.0 |
|
|
2018-09 |
CT#81 |
CP-182084 |
0110 |
1 |
EPS interworking with 5GS |
15.3.0 |
|
|
2018-09 |
CT#81 |
CP-182084 |
0111 |
1 |
AMF Discovery by 5G AN |
15.3.0 |
|
|
2018-12 |
CT#82 |
CP-183092 |
0115 |
3 |
Procedures to support interworking with 5GC |
15.4.0 |
|
|
2018-12 |
CT#82 |
CP-183092 |
0116 |
– |
Corrections to references in clause 7.2 |
15.4.0 |
|
|
2018-12 |
CT#82 |
CP-183092 |
0117 |
1 |
EPS interworking with 5GS |
15.4.0 |
|
|
2019-03 |
CT#83 |
CP-190032 |
0118 |
– |
PGW/SMF selection by ePDG |
15.5.0 |
|
|
2019-03 |
CT#83 |
CP-190032 |
0119 |
– |
Incomplete references for AMF discovery and selection by MME |
15.5.0 |
|
|
2019-09 |
CT#85 |
CP-192188 |
0120 |
1 |
Selection of MME_SRVCC |
16.0.0 |
|
|
2019-09 |
CT#85 |
CP-192126 |
0121 |
1 |
DNS procedures to support Ethernet PDN |
16.0.0 |
|
|
2019-12 |
CT#86 |
CP-193041 |
0122 |
1 |
UEs not supporting 5GC NAS with a 5GS subscription |
16.1.0 |
|
|
2020-03 |
CT87e |
CP-200021 |
0126 |
– |
UCMF Selection by MMEs |
16.2.0 |
|
|
2020-06 |
CT#88e |
CP-201062 |
0127 |
– |
Service parameter for SGW |
16.3.0 |
|
|
2020-12 |
CT#90e |
CP-203058 |
0129 |
1 |
Support of PGW-C/SMF change |
17.0.0 |
|
|
2021-03 |
CT#91e |
CP-210049 |
0131 |
– |
DCN support for AMF discovery |
17.1.0 |
|
|
2021-12 |
CT#94e |
CP-213097 |
0132 |
– |
B |
Procedure to select a combined UPF/MB-UPF |
17.2.0 |
|
2022-03 |
CT#95e |
CP-220092 |
0133 |
1 |
F |
Incorrect reference in clause 7.2 |
17.3.0 |