Method and Functions for Handling a UE's Access to a DN
20220046484 · 2022-02-10
Inventors
Cpc classification
H04L67/568
ELECTRICITY
H04L67/63
ELECTRICITY
H04L67/147
ELECTRICITY
International classification
Abstract
The embodiments herein relate to a method performed by a SMF (110) for handling a UEs (101) access to a DN (130) in a 5G communications system. The SMF (110) obtains at least one anycast address supported at a DN/I (130/I) which is accessible by the UE (101) from its location. The SMF (110) sends instructions to a UPF/c (105/c) to report usage of the at least one anycast address. The SMF (110) receives, from the UPF/c (105/c), information that usage of the anycast address has been detected. When usage of the anycast address has been detected, the SMF (110) determines that future usage of the anycast address should be routed to the DN/I (130/I) via the UPF/I (105/I).
Claims
1-36. (canceled)
37. A method, performed by a Session Management Function (SMF), for handling a User Equipment's (UE) access to a Data Network (DN) in a Fifth Generation (5G) communications system, the method comprising: obtaining at least one anycast address supported at a local Data Network (DN/l) which is accessible by the UE from its location; sending instructions to a central User Plane Function (UPF/c) to report usage of the at least one anycast address; receiving, from the UPF/c, information that usage of the anycast address has been detected; and determining, in response to usage of the anycast address being detected, that future usage of the anycast address should be routed to the DN/l via a local UPF (UPF/l).
38. The method of claim 37, where the at least one anycast address is obtained by sending a request for the anycast address to a database (DB), and receiving a response with the requested at least one anycast address from the DB.
39. The method of claim 37, wherein the anycast address is obtained internally in the SMF.
40. The method of claim 37, further comprising selecting, when there is a plurality of obtained anycast addresses, at least one anycast address from the plurality which are applicable for the UE's subscription.
41. The method of claim 37, further comprising sending, in response to usage of the anycast address being detected, instructions to the UE to use a second routing indicator instead of a first routing indicator for routing of data packets.
42. The method of claim 37, further comprising sending instructions to the UPF/c to drop data packets with the at least one anycast address.
43. The method of claim 42, further comprising sending instructions to the UPF/c to send an error message to the UE when the data packet has been dropped.
44. A method, performed by a central User Plane Function (UPF/c), for handling a User Equipment's (UE) access to a Data Network (DN) in a Fifth Generation (5G) communications system, the method comprising: receiving instructions from a Session Management Function (SMF) to report usage of at least one anycast address, wherein the at least one anycast address is supported at a local Data Network (DN/l) which is accessible by the UE from its location; detecting usage of the at least one anycast address, wherein the anycast address has been used to access a central Data Network (DN/c) via the UPF/c; and sending, to the SMF, information that usage of the anycast address has been detected.
45. The method of claim 44, further comprising forwarding, in response to the usage of the at least one anycast address being detected, a data packet with the detected used at least one anycast address to the DN/c.
46. The method of claim 44, further comprising dropping a data packet with the detected used at least one anycast address.
47. The method of claim 46, further comprising receiving instructions from the SMF to drop data packets with the least one anycast address.
48. The method of claim 46, further comprising: receiving instructions from the SMF to send an error message to the UE when the data packet has been dropped; and sending the error message to the UE when the data packet has been dropped.
49. A Session Management Function (SMF) in a Fifth Generation (5G) communications system, the SMF comprising: processing circuitry; memory containing instructions executable by the processing circuitry whereby the SMF is operative to: obtain at least one anycast address supported at a local Data Network (DN/l), which is accessible by a User Equipment (UE) from its location; send instructions to a central User Plane Function (UPF/c) to report usage of the at least one anycast address; receive, from the UPF/c, information that usage of the anycast address has been detected; and determine, in response to usage of the anycast address being detected, that future usage of the anycast address should be routed to the DN/l via a local User Plane Function (UPF/l).
50. The SMF of claim 49, wherein the instructions are such that the SMF is operative to obtain the at least one anycast address by sending a request for the anycast address to a database (DB), and receiving a response with the requested at least one anycast address from the DB.
51. The SMF of claim 49, wherein the instructions are such that the SMF is operative to obtain the anycast address internally in the SMF.
52. A central User Plane Function (UPF/c) in a Fifth Generation (5G) communications system, the UPF/c comprising: processing circuitry; memory containing instructions executable by the processing circuitry whereby the UPF/c is operative to: receive instructions from a Session Management Function (SMF) to report usage of at least one anycast address, wherein the at least one anycast address is supported at a local Data Network (DN/l) which is accessible by a User Equipment (UE) from its location; detect usage of the at least one anycast address, wherein the anycast address has been used to access a central Data Network (DN/c) via the UPF/c; and send, to the SMF, information that usage of the anycast address has been detected.
53. The UPF/c of claim 52, wherein the instructions are such that the UPF/c is operative to forward, when the usage of the anycast address has been detected, a data packet with the detected used at least one anycast address to the DN/c.
54. The UPF/c of claim 52, wherein the instructions are such that the UPF/c is operative to drop a data packet with the detected used at least one anycast address.
55. The UPF/c of claim 54, wherein the instructions are such that the UPF/c is operative to receive instructions from the SMF to drop data packets with the least one anycast address.
56. The UPF/c of claim 54, wherein the instructions are such that the UPF/c is operative to: receive instructions from the SMF to send an error message to the UE when the data packet has been dropped; and send the error message to the UE when the data packet has been dropped.
Description
BRIEF DESCRIPTION OF THE DRAWINGS
[0021] The embodiments herein will now be further described in more detail by way of example only in the following detailed description by reference to the appended drawings illustrating the embodiments and in which:
[0022]
[0023]
[0024]
[0025]
[0026]
[0027]
[0028]
[0029]
[0030]
[0031]
[0032]
[0033]
[0034] The drawings are not necessarily to scale and the dimensions of certain features may have been exaggerated for the sake of clarity. Emphasis is instead placed upon illustrating the principle of the embodiments herein.
DETAILED DESCRIPTION
[0035] The embodiments herein relate to automatic detection of using an anycast address at a DN/c which is also available at a DN/l closer to the UE, and redirecting the traffic to the Application Server (AS) with that anycast address at that DN/l. Subsequent interactions use the actual address. It applies to a scenario with IPv6MH breakout of traffic and to ULCL breakout of traffic. Breakout of traffic may also be referred to as offload of traffic. Before continuing to describe this in more detail, an example of a network architecture in which the embodiment herein may be implemented will be described.
[0036] ULCL is a functionality supported by an UPF for diverting traffic to local data networks based on traffic matching filters applied to the UE traffic. Multi-Homing may be described as when there are two or more network connections to the same type of network. A purpose of multi-homing is to increase reliability and/or performance.
[0037]
[0038] The UE 101 may be a device by which a subscriber may access services offered by an operator's network and services outside operator's network to which the operator's radio access network and core network provide access, e.g. access to the Internet. The device may be any device, mobile or stationary, enabled to communicate in the communications network, for instance but not limited to e.g. wireless device, mobile phone, smart phone, sensors, meters, vehicles, household appliances, medical appliances, media players, cameras, Machine to Machine (M2M) device, Device to Device (D2D) device, Internet of Things (IoT) device, terminal device, communication device or any type of consumer electronic, for instance but not limited to television, radio, lighting arrangements, tablet computer, laptop or Personal Computer (PC). The UE 101 may be portable, pocket storable, hand held, computer comprised, or vehicle mounted devices, enabled to communicate voice and/or data, via the radio access network, with another entity, such as another UE or a server.
[0039] The (R)AN 103 may comprise a (R)AN node (not illustrated in
[0040] The (R)AN 103 is adapted to be connected to a UPF 105 via a N3 interface. The UPF 105 is adapted to be connected to another UPF 105 via a N9 interface. The UPF 105 may be a local or a central UPF. In the example shown in
[0054] The UE 101 is adapted to be connected to an Access and Mobility Management Function (AMF) 108 via a N1 interface, and the (R)AN 103 is adapted to be connected to the AMF 108 via a N2 interface. The AMF 108 may comprise at least one of the following functionalities: [0055] Termination of RAN Control Plane (CP) interface N2. [0056] Termination of Non-Access-Stratum (NAS), N1, NAS ciphering and integrity protection. [0057] Registration management. [0058] Connection management. [0059] Reachability management. [0060] Mobility Management. [0061] Lawful intercept. [0062] Provide transport for Session Management (SM) messages between UE 101 and SMF 110. [0063] Transparent proxy for routing SM messages. [0064] Access Authentication. [0065] Access Authorization. [0066] Provide transport for Short Message Service (SMS) messages between UE 101 and SMF 110. [0067] Security Anchor Functionality (SEAF). [0068] Location Services management for regulatory services. [0069] Provide transport for Location Services messages between UE 101 and Location Management Function (LMF) as well as between RAN 103 and LMF. [0070] Evolved Packet System (EPS) Bearer Identity (ID) allocation for interworking with EPS. [0071] UE mobility event notification.
[0072] Each of the UPFs 105 is adapted to be connected to a SMF 110 via a respective N4 interface. The SMF 110 may comprise at least one of the following functionalities: [0073] Session Management e.g. Session Establishment, modify and release, including tunnel maintain between UPF 105 and (R)AN node 103. [0074] UE IP address allocation & management. [0075] Dynamic Host Configuration Protocol version 4 (DHCPv4) and DHCP version 6 (DHCPv6) functions. [0076] ARP proxying. [0077] Selection and control of UP function. [0078] Configures traffic steering at UPF 105 to route traffic to proper destination. [0079] Termination of interfaces towards Policy control functions. [0080] Lawful intercept. [0081] Charging data collection and support of charging interfaces. [0082] Control and coordination of charging data collection at UPF. [0083] Termination of SM parts of NAS messages. [0084] Downlink Data Notification (DDN). [0085] Initiator of Access Network (AN) specific SM information. [0086] Determine Session and Service Continuity (SSC) mode of a session. [0087] Roaming functionality.
[0088] The AMF 108 and the SMF 110 are adapted to be connected to each other via a N11 interface.
[0089] The SMF 110 is adapted to be connected to a Policy Control Function (PCF) 113 via a N7 interface. The PCF 113 is adapted to be connected to the AMF 108 via a N15 interface. The PCF 113 may comprise at least one of the following functionalities: [0090] Supports unified policy framework to govern network behaviour. [0091] Provides policy rules to Control Plane function(s) to enforce them. [0092] Accesses subscription information relevant for policy decisions in a Unified Data Repository (UDR).
[0093] The PCF 113 is adapted to be connected to an Access Function (AF) 115 via a N5 interface. The AF 115 may comprise at least one of the following functionalities: [0094] Application influence on traffic routing. [0095] Accessing Network Exposure Function. [0096] Interacting with the Policy framework for policy control.
[0097] The SMF 110 is adapted to be connected to a Unified Data Management (UDM) 118 via a N10 interface. The UDM 118 may comprise at least one of the following functionalities: [0098] Generation of Third Generation Partnership Project (3GPP) Authentication and Key Agreement (AKA) Authentication Credentials. [0099] User Identification Handling. [0100] Support of de-concealment of privacy-protected subscription identifier (SUCI). [0101] Access authorization based on subscription data. [0102] UE's Serving Network Function (NF) Registration Management. [0103] Support to service/session continuity. [0104] Mobile Terminal (MT)-SMS delivery support. [0105] Lawful Intercept Functionality. [0106] Subscription management. [0107] SMS management.
[0108] The UDM 118 is adapted to be connected to the AMF 108 via a N8 interface.
[0109] The UDM 118 is adapted to be connected to an Authentication Server Function (AUSF) 120 via a N13 interface. The AUSF 120 supports authentication for 3GPP access and untrusted non-3GPP access.
[0110] The AUSF 120 is adapted to be connected to the AMF 108 via a N12 interface.
[0111] The AMF 108 is adapted to be connected to a Network Slice Selection Function (NSSF) 123 via a N22 interface. The NSSF 123 supports at least one of the following functionalities: [0112] Selecting the set of Network Slice instances serving the UE, [0113] Determining the Allowed Network Slice Selection Assistance Information (NSSAI) and, if needed, the mapping to the Subscribed-NSSAIs (S-NSSAIs), [0114] Determining the Configured NSSAI and, if needed, the mapping to the Subscribed S-NSSAIs, [0115] Determining the AMF Set to be used to serve the UE, or, based on configuration, a list of candidate AMF(s).
[0116] Each of the UPFs 105 is adapted to be connected to a respective DN 130 via a N6 interface. The DN 130 may be e.g. operator services, Internet access or 3rd party services. A DN 130 may be a local or a central DN 130. A DN/l is, according to 3GPP Technical Specification (TS) 23.501 V15.2.0 (2018-06) “a DN that is accessible by the UE only in specific locations, that provides connectivity to a specific Data Network Name (DNN), and whose availability is provided to the UE”. The DN/c may be described as a (data) network where there peering point from the mobile network e.g. at the regional or national level. A central DN may be for example Internet. In the example shown in
[0117] Each DN 130 comprises at least one Application Server (AS) 133. The DN/l 130/l comprises at least one local AS (AS/l) 133/l and the DN/c 130/c comprises at least one central AS (AS/c) 133c. When the reference number 133 is used without /l or /c, it refers to any of the central or local AS 133. An AS 133 may be referred to as an application herein for the sake of simplicity. The AS 133 may be described as providing a service, and the AS 133 may therefore also be referred to as a service herein.
[0118] A database (DB) 135 is adapted to be connected to the SMF 110. The DB 135 may be a standalone database or it may be co-located with the SMF 110. The DB 135 may comprise at least one anycast address.
[0119] The terms reference point and interface are sometimes used interchangeably herein.
[0120]
[0121] It should be noted that the communication links in the network architecture exemplified in
[0122] The term anycast address mentioned earlier will now be described. An anycast address is defined as “An identifier for a set of interfaces (typical belonging to different nodes). A packet sent to an anycast address is delivered to one of the interfaces identified by that address (the “nearest” one, according to the routing protocols' measure of distance)” by the Request for Comments (RFC) 4291. It may also be described as a one-to-one-of-many association where a single destination address has multiple routing paths to multiple endpoint destinations. With an anycast address, data packets are often routed to the geographically nearest member of an anycast group, i.e. to the member with the “least costly route” according to the routing protocols. But this may coincide with the geographically closest member. Thus, a data packet sent to an anycast address is delivered to the geographically closest interface identified by the anycast address. A graphical illustration of the anycast address is shown in
[0123]
[0124] Step 301
[0125] The SMF 110 obtains at least one anycast address supported at a DN/l 130/l which is accessible by the UE 101 from its location, i.e. the DN/l 130/l which is located geographically closest to the UE 101. With the anycast address, the SMF 110 comprises information about the DN/l 130/l which is located geographical closest to the UE 101 and the UPF/l 105/l associated with the DN/l 130/l. The anycast address may e.g. anycast address #1, or it may be anycast address #1, anycast address #2 and anycast address #3. Note that the numbers of obtained anycast address listed above are just examples, and that any number of anycast addresses from one and upwards is applicable. In the following description of
[0126] This anycast address(es) may be obtained from the DB 135 for example in case the SMF 110 does already have such anycast address. Another example for when the any cast address may be obtained from the DB 135 may be when the SMF 110 already have the anycast address, but this anycast address has expired, i.e. it was too long ago since the ancyast address was obtained. The anycast address maybe obtained internally within the SMF 110, for example when the SMF 110 already have the anycast address and when this has not expired, i.e. the anycast address was recently obtained and can now be reused. The anycast address may be an IP address.
[0127] A trigger for performing step 301 may be that the signaling between the UE 101 and the SMF 110 is completed, e.g. signaling for setting up a PDN connection.
[0128] Step 302
[0129] The SMF 110 sends instructions to the UPF/c 105/c that it should report usage of the anycast address #1 back to the SMF 110. The reporting may be upon detection of the usage, it may be on regular basis, it maybe when an existing message is already to be sent to the SMF 110 with other types of information etc.
[0130] Step 303
[0131] The UE 101 sends a data packet with the anycast address #1 to the UPF/c. The anycast address #1 may be seen as a destination address for the data packet. The path of the data packet is illustrated with solid arrows in
[0132] Step 304
[0133] The UPF/c 105/c detects the usage of the anycast address #1. When the UPF/c 105/c has detected the usage of the anycast address #1, it may either drop the data packet from step 103b or it may forward it to the UPF/c. If the data packet is dropped, it is not transmitted further by the UPF/c 105/c. In other words, the UPF/c 105/c performs traffic inspection and detects the usage of the any cast address #1.
[0134] Step 305
[0135] The UPF/c reports the usage of the anycast address #1 to the SMF 110.
[0136] Step 306
[0137] Triggered by the reported usage of the anycast address #1, the SMF 110 determines that future usage of anycast address #1 should be routed to DN/l 130/l via the UPF/l 105/l. The SMF 110 may inform the (R)AN 103 and/or the UPF/l 105/l about the decision. Using other words, future data traffic with anycast address #1 should be broken out to the DN/l 130/l.
[0138] Step 307
[0139] The UE 101 resends the data packet from step 303 with anycast address #1, i.e. with the same anycast address as in step 303. Reasons for the resending may be that the UE 101 has not received any confirmation of receipt of the data packet from step 303 or that a timer has expired. The data packet may be resent with a second routing indicator, i.e. a different routing indicator compared to in step 303.
[0140] The second routing indicator indicates where the data packet should be routed. The second routing indicator may be a second IPv6 prefix in case of IPv6 and a second subnet mask in case of IPv4. The second IPv6 prefix may be of any suitable length and format. The second routing indicator may also be referred to as a second routing prefix. In case IPv4 is used instead of IPv6, the second routing indicator may be a second subnet mask.
[0141] The resent packet is routed via the UPF/l 105/l to the DN/l 130/l which is located geographically closer to the UE 101 than the DN/c 130/c. The data packet resent form the UE 101 to the UPF/c may be referred to as UL traffic.
[0142] Step 308
[0143] The UPF/l 105/l receives the resent data packet with anycast address #1 and applies either ULCL or IPv6MH for further routing of the data packet to the DN/l 130/l. The choice of ULCL or IPV6MH may be configured in the UPF/l 105/l meaning that it knows if the ULCL feature and/or the IPv6MH feature are supported in the specific UPF 105.
[0144] The UPF/l 105/l, i.e. the UPF 105 interfacing the local network in reference point N6, diverts the uplink traffic from the UE 101 to the DN/l 130/l based on either (a) the destination address for ULCL, also referred to as “normal” routing, or (b) the UE source address for the case of IPv6MH where the UE 101 uses different addresses for traffic to the two DNs 130. The latter avoids that the routing table might grow so that the user plane throughput may be degraded.
[0145] As mentioned earlier, the embodiments herein relate to an automated access to a DN/l 130/l. It may be several alternatives for this, for example either using ULCL breakout or IPv6HM breakout. In addition, each of these alternatives may be done in different ways, e.g. with forwarding to a DN/c 130/c or with dropping of packet to a DN/c 130/c. Some example methods illustrating automated access to a DN/l 130/l will now be described with reference to
[0146] 1. Automated access to DN/l 130/l—with ULCL breakout:
[0149] 2. Automated access to DN/l 130/l—with IPv6HM breakout:
[0152]
[0153] Step 401
[0154] This step is seen in
[0155] Step 402
[0156] This step is seen in
[0157] Step 403
[0158] This step is seen in
[0159] The SMF query may be omitted if the SMF 110 already has sufficiently recent information regarding the anycast addresses.
[0160] Step 404
[0161] This step is seen in
[0162] Restriction of the list of anycast addresses may be done for reasons like subscriber differentiation, i.e. the subscriber has access to what he/she pays for. It may also be that different subscribers are only allowed to use certain services for security reasons, parental control, etc. The subscription and service definitions are the overall subscription and service definition of the subscriber—it e.g. can accept or not accept PDU session establishment in step 401 depending on the subscriber is allowed to access that Access Point Name (APN) or not.
[0163] Step 405
[0164] This step is seen in
[0165] Step 406
[0166] This step is seen in
[0167] User plane treatment is performed according to normal policy, usually to forward the packet to the DN/c 130/c.
[0168] Step 407
[0169] This step is seen in
[0170] Step 408
[0171] This step is seen in
[0172] Step 409
[0173] This step is seen in
[0174] Step 410
[0175] This step is seen in
[0176] Step 411
[0177] This step is seen in
[0178] Step 412
[0179] This step is seen in
[0180] Step 413
[0181] This step is seen in
[0182]
[0183] Step 501
[0184] This step is seen in
[0185] Step 502
[0186] This step is seen in
[0187] Step 503
[0188] This step is seen in
[0189] The SMF query may be omitted if the SMF 110 already has sufficiently recent information regarding the anycast addresses.
[0190] Step 504
[0191] This step is seen in
[0192] Step 505
[0193] This step is seen in
[0194] Step 506
[0195] This step is seen in
[0196] User plane treatment is performed according to normal policy, usually to forward the packet to the DN/c 130/c.
[0197] Step 507
[0198] This step is seen in
[0199] Step 508
[0200] This step is seen in
[0201] Step 509
[0202] This step is seen in
[0203] Step 510
[0204] This step is seen in
[0205] Step 511
[0206] This step is seen in
[0207] Step 512
[0208] This step is seen in
[0209] Step 513
[0210] This step is seen in
[0211] Step 514
[0212] This step is seen in
[0213] There need to be way for the application in the UE 101 doing the communication to understand that it shall switch to the new TCP socket for communication. For that reason the application in the UE 101 will try using the old TCP socket once more but when the traffic is broken out to the AS/l 133/l (at the UPF/l 105/l) it will not understand this TCP session and reply with a reset. Then the application in the UE 101 establishes a new TCP connection over the new TCP socket.
[0214] Step 515
[0215] This step is seen in
[0216] Step 516
[0217] This step is seen in
[0218] Step 517
[0219] This step is seen in
[0220]
[0221] Step 601
[0222] This step is seen in
[0223] Step 602
[0224] This step is seen in
[0225] Step 603
[0226] This step is seen in
[0227] The SMF query may be omitted if the SMF 110 already has sufficiently recent information regarding the anycast addresses.
[0228] Step 604
[0229] This step is seen in
[0230] Step 605
[0231] This step is seen in
[0232] Step 606
[0233] This step is seen in
[0234] Step 607
[0235] This step is seen in
[0236] Step 608
[0237] This step is seen in
[0238] Step 609
[0239] This step is seen in
[0240] Step 610
[0241] This step is seen in
[0242] Step 611
[0243] This step is seen in
[0244] Step 612
[0245] This step is seen in
[0246] Step 613
[0247] This step is seen in
[0248] Step 614
[0249] This step is seen in
[0250]
[0251] Step 701
[0252] This step is seen in
[0253] Step 702
[0254] This step is seen in
[0255] Step 703
[0256] This step is seen in
[0257] The SMF query may be omitted if the SMF 110 already has sufficiently recent information regarding the anycast addresses.
[0258] Step 704
[0259] This step is seen in
[0260] Step 705
[0261] This step is seen in
[0262] Step 706
[0263] This step is seen in
[0264] Step 707
[0265] This step is seen in
[0266] Step 708
[0267] This step is seen in
[0268] Step 709
[0269] This step is seen in
[0270] Step 710
[0271] This step is seen in
[0272] Step 711
[0273] This step is seen in
[0274] Step 712
[0275] This step is seen in
[0276] Step 713
[0277] This step is seen in
[0278] Step 714
[0279] This step is seen in
[0280] Step 715
[0281] This step is seen in
[0282] Step 716
[0283] This step is seen in
[0284] Step 717
[0285] This step is seen in
[0286] The method described above will now be described seen from the perspective of the SMF 110.
[0287] Step 801
[0288] This step corresponds to step 301 in step 3a, step 403 in
[0289] The at least one anycast address may be obtained by sending a request for the anycast address to a DB 135 and receiving a response with the requested at least one anycast address from the DB 135.
[0290] The anycast address may be obtained internally in the SMF 110. The SMF 110 may either keep an internal DB comprising the anycast address or it may have recently already made a request to the DB 135, which makes it unnecessary to ask again. This keeps the amount of signalling down.
[0291] The SMF 110 may have obtained the UE location and the DN/l 130/l prior to step 801.
[0292] Step 802
[0293] This step corresponds to step 404 in
[0294] Step 803
[0295] This step corresponds to step 302 in
[0296] Step 804
[0297] This step corresponds to step 606 in
[0298] Step 805
[0299] This step corresponds to step 606 in
[0300] Step 806
[0301] This step corresponds to step 305 in
[0302] Step 807
[0303] This step corresponds to step 306 in
[0304] The DN/c 130/c and the DN/l 130/l may both provide the same service requested by the UE 101.
[0305] The anycast address may have been used by an application comprised in the UE 101 for accessing the DN/c 130/c.
[0306] Step 808
[0307] This step corresponds to step 307 in
[0308] The method described above will now be described seen from the perspective of the UPF/c 105/c.
[0309] Step 901
[0310] This step corresponds to step 302 in
[0311] Step 902
[0312] This step corresponds to step 606 in
[0313] Step 903
[0314] This step corresponds to step 606 in
[0315] Step 904
[0316] The UPF/c 105/c may send the error message to the UE 101 when the data packet has been dropped.
[0317] Step 905
[0318] This step corresponds to step 304 in
[0319] Step 906
[0320] This step corresponds to step 410 in
[0321] Step 907
[0322] This step corresponds to step 610 in
[0323] Step 908
[0324] This step corresponds to step 305 in
[0325] In step 905, the UPF/c 105/c detects that an application in the UE 101 has tried to access the AS 133 somewhere. The first hit will be in the DN/c 130/c, and when the UPF/l 105/l is inserted in the path, the next hit will be in the DN/l 130/l.
[0326] The method described above will now be described seen from the perspective of the UE 101.
[0327] Step 1001
[0328] This step corresponds to step 303 in
[0329] The data packet may be further sent with a first IPv6 prefix.
[0330] Step 1002
[0331] This step corresponds to step 510 in
[0332] Step 1003
[0333] This step corresponds to step 516 in
[0334] Step 1004
[0335] This step corresponds to step 516 in
[0336] Step 1005
[0337] This step corresponds to step 612 in
[0338] Step 1006
[0339] This step corresponds to step 307 in
[0340] The data packet may be resent with the second routing indicator. The data packet may be resent on the reset TPC session.
[0341] The resending of the anycast address may be done with the second routing indicator when TCP is used as transport layer for sending the data packet with the first routing indicator.
[0342] The data packet may be resent when a timer for receiving a response for sending the data packet has expired.
[0343] In
[0344] The SMF 110 is operative to, e.g. by means of the PCU_AMF 1101, obtain at least one anycast address supported at a DN/l 130/l which is accessible by a UE 101 from its location. The at least one anycast address may be obtained by sending a request for the anycast address to a DB 135 and receiving a response with the requested at least one anycast address from the DB 135. The anycast address may be obtained internally in the SMF 110.
[0345] The SMF 110 is further operative to, e.g. by means of the PCU_SMF 1101, send instructions to a UPF/c 105/c to report usage of the at least one anycast address. The SMF 110 is operative to, e.g. by means of the PCU_AMF 1101, receive, from the UPF/c 105/c, information that usage of the anycast address has been detected. The SMF 110 is operative to, e.g. by means of the PCU_AMF 1101, when usage of the anycast address has been detected, determine that future usage of the anycast address should be routed to the DN/l 130/l via a UPF/l 105/l.
[0346] The SMF 110 may be further operative to, e.g. by means of the PCU_SMF 1101, when there is a plurality of obtained anycast addresses, select at least one anycast address from the plurality which are applicable for the UE's 101 subscription.
[0347] The SMF 110 may be further operative to, e.g. by means of the PCU_SMF 1101, when the anycast address usage has been detected, send instructions to the UE 101 to use a second routing indicator instead of a first routing indicator for routing of data packets. The second routing indicator may be a second IPv6 prefix or a second subnet mask. The first routing indicator may be a first IPv6 prefix or a first subnet mask.
[0348] The SMF 110 may be further operative to, e.g. by means of the PCU_SMF 1101, send instructions to the UPF/c 105/c to drop data packets with the at least one anycast address.
[0349] The SMF 110 may be further operative to, e.g. by means of the PCU_SMF 1101, send instructions to the UPF/c 130/c to send an error message to the UE 101 when the data packet has been dropped.
[0350]
[0351] The UPF/c 105/c is operative to, e.g. by means of the PCU_UPF/c 1108, receive instructions from a SMF 110 to report usage of at least one anycast address. The at least one anycast address is supported at a DN/l 130/l which is accessible by a UE 101 from its location.
[0352] The UPF/C 105/c is operative to, e.g. by means of the PCU_UPF/c 1108, detect usage of the at least one anycast address. The anycast address has been used to access a DN/c 130/c via the UPF/c 105/c.
[0353] The UPF/C 105/c is operative to, e.g. by means of the PCU_UPF/c 1108, send, to the SMF 110, information that usage of the anycast address has been detected.
[0354] The UPF/c 105/c may be further operative to, e.g. by means of the PCU_UPF/c 1108, when the usage has been detected, forward a data packet with the detected used at least one anycast address to the DN/c 130/c.
[0355] The UPF/c 105/c may be further operative to, e.g. by means of the PCU_UPF/c 1108, drop a data packet with the detected used at least one anycast address.
[0356] The UPF/c 105/c may be further operative to, e.g. by means of the PCU_UPF/c 1108, receive instructions from the SMF 110 to drop data packets with the least one anycast address.
[0357] The UPF/c 105/c may be further operative to, e.g. by means of the PCU_UPF/c 1108, receive instructions from the SMF 110 to send an error message to the UE 101 when the data packet has been dropped, and to send the error message to the UE 101 when the data packet has been dropped.
[0358] Further,
[0359] The UE 101 is operative to, e.g. by means of the PCU_UE 1115, send a data packet with an anycast address to a DN/c 130/c, and to resend the data packet with the anycast address.
[0360] The data packet may be further sent with a first routing indicator.
[0361] The UE 101 may be further operative to, e.g. by means of the PCU_UE 1115, receive instructions from a SMF 110 to use a second routing indicator instead of the first routing indicator for routing of data packets, The data packet may be resent with the second routing indicator. The second routing indicator may be a second IPv6 prefix or a second subnet mask. The first routing indicator may be a first IPv6 prefix or a first subnet mask.
[0362] The UE 101 may be further operative to, e.g. by means of the PCU_UE 1115, if TCP, is used as transport layer for sending the data packet, receive instructions to reset a TCP session from a DN/l 130/l; and to reset the TCP session. The data packet may be resent on the reset TPC session.
[0363] The UE 101 may be further operative to, e.g. by means of the PCU_UE 1115, resend of the anycast address is done with the second routing indicator when TCP is used as transport layer for sending the data packet with the first routing indicator.
[0364] The UE 101 may be further operative to, e.g. by means of the PCU_UE 1115, receive, from either a UPF/c 105/c or a UPF/l 105/l, a trigger for resending the data packet with the anycast address.
[0365] The data packet may be resent when a timer for receiving a response for sending the data packet has expired.
[0366] The entities in
[0367] It is noted that the features of the methods described above and in the following, may be implemented in software and carried out on a data processing device or other processing means caused by the execution of program code means such as computer-executable instructions. Here and in the following, the term processing means comprises any circuit and/or device suitably adapted to perform the above functions. In particular, the above term comprises general- or special-purpose programmable microprocessors, Digital Signal Processors (DSP), Application Specific Integrated Circuits (ASIC), Programmable Logic Arrays (PLA), Field Programmable Gate Arrays (FPGA), special purpose electronic circuits, etc., or a combination thereof. For example, the program code means may be loaded in a memory, such as a RAM (Random Access Memory), from a storage medium, such as a read-only memory (ROM) or other non-volatile memory, such as flash memory, or from another device via a suitable data interface, the described features may be implemented by hardwired circuitry instead of software or in combination with software.
[0368] A computer program or computer program product is provided carrying out the method steps defined above. A carrier may comprise the computer program, and the carrier may be one of an electronic signal, optical signal, radio signal or computer readable storage medium.
[0369] Some embodiments described herein may be summarised in the following manner:
[0370] A prerequisite for the embodiments herein may be that services to be supported and made available both at a DN/c 130/c and a DN/l 130/l is reached by the UE 101 contacting an anycast address.
[0371] The UPF 105 that is configured to support access to a DN/l 130/l, serving a specific DNN, and has been assigned a DNAI for that purpose may also collect and record the available anycast addresses at the DN/l 130/l together with the DNAI in the same database as the SMF 110 uses or UPF/l lookup. E.g. for IPv6 collecting, the anycast addresses received with the RA from the DN 130.
[0372] The SMF 110 has access to the present network status by querying the DB 135 on a per need basis. The SMF 110 may subscribe to notifications from the DB 135 due to database updates as well as maintain a local cache of the present status, sharing the status among all PDU sessions where the UEs 101 are in an area of same support for local services. Such methods help limiting the query rate towards the DB 135. There may be a central DB 135 where the applicable anycast address(es) serving each service is recorded. From this DB 135, the SMF 110 may tailor the set of anycast addresses that might be served by a DN/l 130/l for each specific PDU session.
[0373] The SMF 110 may follow the UE mobility to the granularity required in relation to the subscription. This applies at connection set-up as well as at mobility.
[0374] The SMF 110 acquires at PDU session establishment information on the anycast addresses that can be served locally, building a candidate DNAI list, preferably with restriction to the anycast addresses that are applicable for the subscription.
[0375] The SMF 110 may share the information as to anycast addresses that can be served locally across PDU sessions to the same DNN for UEs 101 in the same location/area. The restriction to services applicable for the subscription may still need to be per PDU session.
[0376] The SMF 110 may be informed and may act on changes with respect to: [0377] Available anycast addresses at each DNAI. [0378] UE location changes that may require the set of anycast addresses to be monitored to change. [0379] Modifications in the set of services/service configurations available. [0380] Changes to the UE subscription, if the SMF 110 practices restriction to subscribed services.
[0381] The SMF 110 prepares the traffic inspection for the traffic that should be served by a DN/l 130/l, at the UPF/c 105/c. The traffic inspection is to detect UL traffic towards any of the anycast addresses that are relevant for the PDU session. Matching traffic, i.e. detected usage of the applicable anycast address, may be treated according to one of the following alternatives: [0382] (a) Let the traffic pass, (
[0384] The UPF/c reports to the SMF 110 in both cases a) and b) that traffic with the used anycast address has been detected.
[0385] The traffic inspection at the UPF/c 105/c may be organized per service, one case for the whole PDU session or according to any other suitable structure.
[0386] When the UPF/c 105/c detects traffic towards a monitored anycast address, the SMF 110 inserts a suitable UPF/l 105/l for example based on the information available in the network resource database, informing about possible DNAI(s) etc.
[0387] For the UPF action a) above, let the traffic pass/forward the data packet: The SMF 110 inserts the applicable UPF/l 105/l in the traffic path. The application in the UE 101 may be expected to handle the diversion of the service to the DN/l 130/l by forcing the UE 101 to re-try, starting over with the anycast address, e.g. by the central server not responding/indicating a temporary unavailability etc.
[0388] For the UPF action b) above, drop the traffic and send message to UE 101: The UE 101 may be expected to re-try its request with the second routing indicator at a time when the DN/l access has been established. The SMF 110 actions may be the same as for action a). This has the same effect as the AS/c 133/c not responding at all.
[0389] The embodiments herein are applicable both to legacy Physical Network Functions (PNF), i.e. integrated nodes, as well as to cloud deployments though Virtual Network Functions (VNFs).
[0390] The embodiments herein are not limited to the above described embodiments. Various alternatives, modifications and equivalents may be used. Therefore, the above embodiments should not be taken as limiting the scope of the embodiments, which is defined by the appended claims. A feature from one embodiment may be combined with one or more features of any other embodiment.
[0391] It should be emphasized that the term “comprises/comprising” when used in this specification is taken to specify the presence of stated features, integers, steps or components, but does not preclude the presence or addition of one or more other features, integers, steps, components or groups thereof. It should also be noted that the words “a” or “an” preceding an element do not exclude the presence of a plurality of such elements.
[0392] The term “configured to” used herein may also be referred to as “arranged to”, “adapted to”, “capable of” or “operative to”.
[0393] The term “at least one of A and B” should be understood to mean “only A, only B, or both A and B.”
[0394] It should also be emphasised that the steps of the methods defined in the appended claims may, without departing from the embodiments herein, be performed in another order than the order in which they appear in the claims.