Patent Description:
In modern telecommunications networks, almost each and every device or node of the networks will be assigned with at least one IP address, and therefore IP addresses are definitely one of the most important resources for network operators.

An IP address is a numerical label assigned to each device connected to a network that uses the Internet Protocol for communication. An IP address serves two main functions: host or network interface identification and location addressing. Internet Protocol version <NUM> (IPv4) defines an IP address as a <NUM>-bit number, such as <NUM>. <NUM> in decimal or "<NUM><NUM><NUM><NUM>" in binary. However, because of the fast growth of the Internet and the depletion of available IPv4 addresses, a new version of IP (IPv6), using <NUM> bits for the IP address, is presented, such as <NUM>:<NUM>::<NUM> in hex or <NUM>:<NUM>:<NUM>:<NUM>:<NUM>:<NUM>:<NUM>:<NUM> in its full address format.

The IP address space is managed globally by the Internet Assigned Numbers Authority (IANA), and by five regional Internet registries (RIRs) responsible in their designated territories for assignment to local Internet registries, such as Internet service providers, and other end users. IPv4 addresses were distributed by IANA to the RIRs in blocks of approximately <NUM> million addresses each. Further, some IPv4 addresses are reserved for private networks and are not globally unique.

Although IPv6 supports much more IP addresses than its predecessor IPv4, the existence of legacy devices, which support IPv4 only, requires a modern telecommunications network to support IPv4 for communication with the legacy devices, and therefore IPv4 is still widely used and more IPv4 addresses are still in need. For example, one of the largest telecommunication operators in China may have hundreds of millions of subscribers, whereas less than a million of public IPv4 addresses may be allocated by the Asia-Pacific Network Information Centre (APNIC) to the operator. In such a case, even with the Network Address Translation (NAT) technology, the operator still cannot provide enough IPv4 addresses (even private IPv4 addresses) to its subscribers and numerous nodes, which serve the subscribers, for communication. Therefore, it is a critical problem for an operator to provide its subscribers with sufficient IP addresses.

Document <CIT> discloses techniques for informing services nodes of private network address information in order to apply subscriber-aware services with the services node. A services node includes an Authentication, Authorization, and Accounting (AAA) interface to receive a AAA message, wherein the AAA message has been extended from a AAA protocol to specify a private network address of a subscriber device authenticated to an access network by the AAA server and assigned the private network address that is not routable external to the access network. A mapping module associates the public network address of subscriber data traffic with the private network address received by the AAA message. One or more service modules select one or more of a plurality of subscriber policies using the associated private network address and apply services to the subscriber data traffic in accordance with the selected subscriber policies.

Document "Add NR-U RAT type", <NUM>. <NUM> discloses an address pool identifier.

According to the present disclosure, methods, an SMF, a DN-AAA and a computer-readable storage medium according to the independent claims are provided. Developments are set forth in the dependent claims.

According to a first aspect of the present disclosure, there is provided a method at a Session Management Function, SMF, for facilitating reuse of a private Internet Protocol, IP, address at multiple User Equipments, UEs, comprising (i) a first UE, wherein a first User Plane Function, UPF and a second UPF are connected to the SMF, wherein the first UPF maintains a first private IP address range and the second UPF maintains a second private IP address range, and wherein the first and second private IP address ranges are at least partially identical. The method comprises transmitting, to a Data Network-Authentication, Authorization & Accounting, DN-AAA, accounting server, a first request message associated with the first UE, the first request message comprising (i) the private IP address comprising an IPv4 address not being globally unique, and (ii) a selected first 3GPP-IP-Address-Pool-Info which, in conjunction with the private IP address, uniquely identifies a Protocol Data Unit, PDU, session of the first UE, wherein the first 3GPP-IP-Address-Pool-Info indicates information on an IP address pool applicable to the private IP address; and receiving, from the DN-AAA accounting server, a first response message associated with the first UE in response to the first request message, wherein: - the first request message is one of: an Accounting-Request START message, an Accounting-Request STOP message, an ACR Command, and an Accounting-Request Interim-Update message, and - the first response message is a corresponding one of: an Accounting-Response START message, an Accounting-Response STOP message, an ACA Command, and an Accounting-Response Interim-Update message.

According to a second aspect of the present disclosure, there is provided a method at a Data Network-Authentication, Authorization & Accounting, DN-AAA, accounting server for facilitating reuse of a private Internet Protocol, IP, address at multiple User Equipments, UEs, comprising a first UE, wherein the DN-AAA accounting server is connected to a Session Management Function, SMF, wherein a first User Plane Function, UPF and a second UPF are connected to the SMF, wherein the first UPF maintains a first private IP address range and the second UPF maintains a second private IP address range, and wherein the first and second private IP address ranges are at least partially identical. The method comprises receiving, from the SMF, a first request message associated with the first UE, the first request message comprising (i) the private IP address comprising an IPv4 address not being globally unique, and (ii) a selected first 3GPP-IP-Address-Pool-Info which, in conjunction with the private IP address, uniquely identifies a Protocol Data Unit, PDU, session of the first UE, wherein the first 3GPP-IP-Address-Pool-Info indicates information on an IP address pool applicable to the private IP address; and performing processing for the first UE identified by the first 3GPP-IP-Address-Pool-Info in conjunction with the private IP address, wherein: - the first request message is one of: an Accounting-Request START message, an Accounting-Request STOP message, and an Accounting-Request Interim-Update message, ACR Command, and - the first response message is a corresponding one of: an Accounting-Response START message, an Accounting-Response STOP message, ACA Command, and an Accounting-Response Interim-Update message.

According to a third aspect of the present disclosure, there is provided a Session Management Function, SMF, comprising a processor and a memory storing instructions which, when executed by the processor, cause the processor to perform the method of the first aspect.

According to a fourth aspect of the present disclosure, there is provided a Data Network-Authentication, Authorization & Accounting, DN-AAA, accounting server, comprising a processor and a memory storing instructions which, when executed by the processor, cause the processor to perform the method of the second aspect.

According to a fifth aspect of the present disclosure, a there is provided a non-transitory computer readable storage medium storing instructions. The instructions, when executed by a processor, cause the processor to perform any of the methods of the first and second aspects.

Whenever in the following disclosure any of the above-stated aspects (independent claims) is disclosed as "optional" (e.g. due to usage of conjunctive terms, such as "can", "may", "should" etc.), it is nevertheless to be read as "mandatory".

The foregoing and other features of the present disclosure will become more fully apparent from the following description and appended claims, taken in conjunction with the accompanying drawings. Understanding that these drawings depict only several embodiments in accordance with the disclosure and therefore are not to be considered limiting of its scope, the disclosure will be described with additional specificity and detail through use of the accompanying drawings. Hereinabove and in the following, "examples" pertain to principles underlying the claimed subject-matter and/or being useful for understanding the claimed subject-matter, while "embodiments" pertain to the claimed subject-matter within the claim scope.

Whenever in the following disclosure the term "embodiment" occurs, reference is to be made to the figure description above to clarify whether an embodiment or an example is meant.

Hereinafter, the present disclosure is described with reference to embodiments shown in the attached drawings. However, it is to be understood that those descriptions are just provided for illustrative purpose, rather than limiting the present disclosure. Further, in the following, descriptions of known structures and techniques are omitted so as not to unnecessarily obscure the concept of the present disclosure.

Those skilled in the art will appreciate that the term "exemplary" is used herein to mean "illustrative," or "serving as an example," and is not intended to imply that a particular embodiment is preferred over another or that a particular feature is essential. Likewise, the terms "first", "second", "third", "fourth," and similar terms, are used simply to distinguish one particular instance of an item or feature from another, and do not indicate a particular order or arrangement, unless the context clearly indicates otherwise. Further, the term "step," as used herein, is meant to be synonymous with "operation" or "action. " Any description herein of a sequence of steps does not imply that these operations must be carried out in a particular order, or even that these operations are carried out in any order at all, unless the context or the details of the described operation clearly indicates otherwise.

Conditional language used herein, such as "can," "might," "may," "e.g.," and the like, unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments include, while other embodiments do not include, certain features, elements and/or states. Thus, such conditional language is not generally intended to imply that features, elements and/or states are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without author input or prompting, whether these features, elements and/or states are included or are to be performed in any particular embodiment.

The term "based on" is to be read as "based at least in part on. " The term "one embodiment" and "an embodiment" are to be read as "at least one embodiment. " The term "another embodiment" is to be read as "at least one other embodiment. " Other definitions, explicit and implicit, may be included below. In addition, language such as the phrase "at least one of X, Y and Z," unless specifically stated otherwise, is to be understood with the context as used in general to convey that an item, term, etc. may be either X, Y, or Z, or a combination thereof.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limitation of example embodiments. It will be also understood that the terms "connect(s)," "connecting", "connected", etc. when used herein, just mean that there is an electrical or communicative connection between two elements and they can be connected either directly or indirectly, unless explicitly stated to the contrary.

Of course, the present disclosure may be carried out in other specific ways than those set forth herein without departing from the scope and essential characteristics of the disclosure. One or more of the specific processes discussed below may be carried out in any electronic device comprising one or more appropriately configured processing circuits, which may in some embodiments be embodied in one or more applicationspecific integrated circuits (ASICs). In some embodiments, these processing circuits may comprise one or more microprocessors, microcontrollers, and/or digital signal processors programmed with appropriate software and/or firmware to carry out one or more of the operations described above, or variants thereof. In some embodiments, these processing circuits may comprise customized hardware to carry out one or more of the functions described above. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive.

Although multiple embodiments of the present disclosure will be illustrated in the accompanying Drawings and described in the following Detailed Description, it should be understood that the disclosure is not limited to the disclosed embodiments, but instead is also capable of numerous rearrangements, modifications, and substitutions without departing from the present disclosure that as will be set forth and defined within the claims.

Further, please note that although the following description of some embodiments of the present disclosure is given in the context of <NUM> New Radio (NR), the present disclosure is not limited thereto. Therefore, one skilled in the arts could readily understand that the terms used herein may also refer to their equivalents in any other infrastructure. For example, the term "User Equipment" or "UE" used herein may refer to a mobile device, a mobile terminal, a mobile station, a user device, a user terminal, a wireless device, a wireless terminal, or any other equivalents. For another example, the term ""gNB" used herein may refer to a base station, a base transceiver station, an access point, a hot spot, a NodeB, an Evolved NodeB, a network element, or any other equivalents. Further, the term "network element" used herein may refer to a network function, a network entity, a node, a network equipment, or any other device on the network side. Further, please note that the term "indicator" used herein may refer to an attribute, a setting, a configuration, a profile, an identifier, a field, one or more bits/octets, or any data by which information of interest may be indicated directly or indirectly.

The <NUM> Core Network has been designed around services that are invoked using a standard Application Programming Interface (API). On the surface, the <NUM> architecture looks very different from the <NUM> Evolved Packet Core (EPC) but on close inspection, one can see the evolution from the <NUM> architecture to the <NUM> architecture.

For example, the <NUM> core has evolved from the <NUM> EPC in two steps:.

The introduction of control and user plane separation in the <NUM> EPC is the first step towards the <NUM> architecture. The Serving GateWay (SGW) and Packet Data Network (PDN) GateWay (PGW) functions were split into a control and data plane component:.

With the separation of control and user plane functions, the split functions are reorganized into new network functions, such as Access and Mobility Function (AMF), Session Management Function (SMF), User Plane Function (UPF), etc. In general, an AMF in <NUM> performs most of the functions which were previously performed by a Mobility Management Entity (MME) in <NUM>, an SMF performs rest of the functions which were previously performed by the MME in addition to the control plane (CP) functions which were previously performed by SGW and PGW, and a UPF performs the user plane (UP) functions which were previously performed by SGW and PGW. In such a manner, the <NUM> EPC components have been reorganized into service-oriented functions. Therefore, any reference to a network function defined for <NUM> may also be applicable to a node defined for <NUM> or any other appropriate telecommunication technologies. For example, when "SMF" is recited in some embodiments, ""PGW-C" or "SGW-C" may be equally applicable. For example, when "UPF" is recited in some embodiments, ""PGW-U" or "SGW-U" may be equally applicable.

<FIG> is an overview diagram illustrating a typical <NUM> New Radio (NR) network architecture <NUM> according to an embodiment of the present disclosure. As shown in <FIG>, the network <NUM> may comprise one or more UEs <NUM> and a (radio) access network ((R)AN) <NUM>, which could be a base station, a Node B, an evolved NodeB (eNB), a gNB, or any entity which provides access to the UEs <NUM>. Further, the network <NUM> may comprise its core network portion comprising (but not limited to) an AMF <NUM>, an SMF <NUM>, a Policy Control Function (PCF) <NUM>, an Application Function (AF) <NUM>, a Network Slice Selection Function (NSSF) <NUM>, an AUthentication Server Function (AUSF) <NUM>, a Unified Data Management (UDM) <NUM>, a Network Exposure Function (NEF) <NUM>, a Network Repository Function (NRF) <NUM>, and a UPF <NUM>. As shown in <FIG>, these entities may communicate with each other via the service-based interfaces, such as, Namf, Nsmf, Npcf, etc. and/or the reference points, such as, N1, N2, N3, N6, N9, etc..

However, the present disclosure is not limited thereto. In some other embodiments, the network <NUM> may comprise additional network functions, less network functions, or some variants of the existing network functions shown in <FIG>. For example, in a network with the <NUM> architecture, the entities which perform these functions may be different from those shown in <FIG>. For another example, in a network with a mixed <NUM>/<NUM> architecture, some of the entities may be same as those shown in <FIG>, and others may be different. Further, the functions shown in <FIG> are not essential to the embodiments of the present disclosure. In other words, some of them may be missing from some embodiments of the present disclosure.

Here, some of the functions shown in <FIG>, such as AMF <NUM>, SMF <NUM>, and UPF <NUM>, which may be involved in the embodiments of the present disclosure will be described in detail below.

Referring to <FIG>, the AMF <NUM> may perform most of the functions that the MME performs in a <NUM> network as mentioned above. Below please find a brief list of some of its functions:.

Further, the SMF <NUM> may perform the session management functions that are handled by the <NUM> MME, SGW-C, and PGW-C. Below please find a brief list of some of its functions:.

Further, the UPF <NUM> is essentially a fusion of the data plane parts of the SGW and PGW, as mentioned above. In the context of the CUPS architecture: EPC SGW-U + EPC PGW-U → <NUM> UPF.

The UPF <NUM> may perform the following functions:.

As shown in <FIG>, the UPF <NUM> is communicatively connected to the Data Network (DN) <NUM> which may be, or in turn communicatively connected to, the Internet, such that the UE <NUM> may finally communicate its user plane data with other devices outside the network <NUM>, for example, via the RAN <NUM> and the UPF <NUM>.

As mentioned above, in order to support more IP addresses for a large amount of UEs in a large operator network, the operator may have the requirement to deploy same IP address ranges to multiple UPFs with different firewalls/NAT, for example, that shown in <FIG>, which will be described in detail below. With the NAT technology, traffic associated with different Protocol Data Unit (PDU) sessions having a same Access Point Name (APN) or a Data Network Name (DNN) and having a same private IPv4 address can be transferred without any problem on the Internet. However, this deployment may cause some troubles for some functions within the network <NUM>. Next, this issue will be explained in detail with reference to <FIG>.

<FIG> is a diagram illustrating a telecommunication system (or the operator domain) <NUM> to which a method for reusing IP addresses at multiple UEs according to an embodiment of the present disclosure is applicable. As shown in <FIG>, the telecommunication system or the operator domain <NUM> may comprise one or more UEs <NUM>, <NUM>, <NUM>, <NUM> and their serving access nodes, gNB-<NUM><NUM> and gNB-<NUM><NUM>, which provide access to the UEs in their serving cells, Cell-<NUM><NUM> and Cell-<NUM><NUM>, respectively. Further, the operator domain <NUM> may comprise one or more UPFs, for example, the UPF-<NUM><NUM> and the UPF-<NUM><NUM>, via which the UEs <NUM>, <NUM>, <NUM>, and <NUM> may communicate their user plane data with the Internet <NUM>, respectively. Further, the operator domain <NUM> may comprise an AMF <NUM>, an SMF <NUM>, and a DN-Authentication, Authorization & Accounting (DN-AAA) server <NUM>. Further, some of the components are omitted from <FIG> for simplicity, for example, a PCF, an AF, a NSSF, etc., as those shown in <FIG>, since they are not directly involved in the embodiments of the present disclosure.

However, this deployment is only for the purpose of illustration rather than limiting of the present disclosure. In some other embodiments, the operator domain <NUM> may comprise more UEs, gNBs, UPFs, AMFs, SMFs, and/or DN-AAAs, or may have different configurations thereof and/or different connections therebetween.

As mentioned above, the operator would like to reuse their IP addresses for different UEs, and therefore the NAT technology is used at UPF-<NUM><NUM> and UPF-<NUM><NUM>. For example, as shown in <FIG>, a NAT rule, NAT-<NUM>, may be configured at UPF-<NUM><NUM>, which serves UE-<NUM><NUM> and UE-<NUM><NUM>. This NAT-<NUM> may translate an IPv4 address in a private IP address range "<NUM>. *" into an IPv4 address in a public IP address range "<NUM>. *" and vice versa. Similarly, another NAT rule, NAT-<NUM>, may be configured at UPF-<NUM><NUM>, which serves UE-<NUM><NUM> and UE-<NUM><NUM>. This NAT-<NUM> may translate the same private IP address range "<NUM>. *" into another public IP address range "<NUM>. *" and vice versa. In other words, multiple UPFs may maintain their own private IP address ranges, respectively, which could be completely or partially identical. With this configuration, all of the UEs, UE-<NUM><NUM>, UE-<NUM><NUM>, UE-<NUM><NUM>, and UE-<NUM><NUM> may communicate with the Internet <NUM> with a limited number of public IP addresses.

However, as also mentioned above, some of the nodes in the operator domain <NUM> may not be aware of the presence of the NAT rules. For example, a part of the DN-AAA server <NUM>, which is in charge of its accounting business, (below, "DN-AAA/Accounting <NUM>") may not be aware of the presence of the NAT rules since it may be located on the same side of the NAT as the UEs, and therefore it cannot distinguish the UE-<NUM><NUM> from the UE-<NUM><NUM> or the UE-<NUM><NUM> from the UE-<NUM><NUM> since these UEs may share a same private IP address and even a same APN/DNN.

To be specific, according to the clause <NUM>. <NUM>, 3GPP TS <NUM> V16. <NUM> (<NUM>-<NUM>), the DN-AAA server <NUM> may be located within the operator domain <NUM> as shown in <FIG>, instead of outside the operator domain <NUM>. Further, according to the clause <NUM>. <NUM>, 3GPP TS <NUM> V15. <NUM> (<NUM>-<NUM>), an Accounting-Request Start message sent to the DN-AAA/Accounting <NUM> comprise no attribute or indicator by which the DN-AAA/Accounting <NUM> can distinguish a PDU session from another PDU session having a same (private) IP address and a same APN/DNN. In other words, the reuse of an IP address at multiple UEs is not supported by the current 3GPP standards.

Therefore, in some embodiments of the present disclosure, one or more indicators in such messages, either an existing attribute or a new attribute, may be used to enable a node in the operator domain <NUM> to distinguish one PDU session from another PDU session having the same IP address and APN/DNN.

In an embodiment of the present disclosure, an existing Remote Authentication Dial In User Service (RADIUS) attribute, for example, "3GPP-IP-Address-Pool-Id" which is defined in the clause <NUM>. <NUM>, 3GPP TS <NUM> V16. <NUM> (<NUM>-<NUM>), is reused to, in conjunction with an IP address allocated to a UE, uniquely identify a PDU session of the UE or the UE itself, according to some embodiments of the present application. However, the current definition of the attribute "3GPP-IP-Address-Pool-Id" in the TS <NUM> is read as follows:
The SMF may determine an IP address pool ID based on UPF ID, S-NSSAI, DNN, and IP version as described in subclause <NUM>. <NUM> in 3GPP TS <NUM> [<NUM>] and includes the IP address pool ID within 3GPP-IP-Address-Pool-Id and send it to the DN-AAA. The DN-AAA assigns IPv6 prefix or IPv4 address from the requested IP address pool. Multiple 3GPP-IP-Address-Pool-Id sub-attributes may be sent in the RADIUS Access-Request message.

Therefore, it can only be used in an Access-Request by an SMF (e.g. the SMF <NUM>) to inform the DN-AAA/Authentication (e.g. the DN-AAA/Authentication <NUM>) of the available IP address pools at UPFs (e.g. the UPF-<NUM><NUM>, the UPF-<NUM><NUM>), and none of the SMF and DN-AAA/Accounting (e.g. the DN-AAA/Accounting <NUM>) may be aware of which IP address pool is selected and from which IP address pool the allocated IP address is selected by the DN-AAA/Authentication. Therefore, according to an embodiment of the present disclosure, a reuse and revise of this existing attribute is proposed, for example, it is used in an Accounting-Request message (e.g., Accounting-Request Start, Accounting-Request Stop, Accounting-Request Interim Update) and/or an Accounting-Response message (e.g., Accounting-Response Start, Accounting-Response Stop, Accounting-Response Interim Update).

Further, according to some embodiments of the present disclosure, the attribute ""3GPP-IP-Address-Pool-Id" may also be reused in an Access-Accept message, in addition to an Access-Request message, to indicate which IP address pool is selected by the DN-AAA/Authentication from the multiple IP address pools corresponding to multiple UPFs.

Furthermore, according to an embodiment of the present disclosure, this attribute may be used in other messages sent to a network function or a node if the network function or the node which cannot distinguish a PDU session from another PDU session based on IP address and/or APN/DNN only.

In such cases, the definition of the attribute may be revised as follows:.

Further, for Access-Request or Diameter EAP Request (DER) command from the SMF to the DN-AAA server with 3GPP VSA 3GPP-Allocate-IP-Type set to value <NUM> (i.e. requesting both v4 and v6), the AAA server does not know which pool id corresponds to which IP version, since the N5 interface as specified in 3GPP TS <NUM> has different settings for IPv4 index and IPv6 index. In such a case, additional information for IP version in a message may be needed to distinguish one IP address pool from another with a different IP version.

Therefore, in an embodiment of the present disclosure, a new RADIUS attribute, for example, "3GPP-IP-Address-Pool-Info" is used to, in conjunction with an IP address allocated to a PDU session or a UE, uniquely identify the PDU session or the UE. An exemplary proposed revision to the related 3GPP standard, 3GPP TS <NUM>, is given below:.

RADIUS attributes as defined in subclause <NUM> of 3GPP TS <NUM> [<NUM>] are re-used in <NUM> with the following differences:.

It is sent from the DN-AAA to authorize UE MAC addresses. Multiple 3GPP-MAC-Address sub-attributes (maximum <NUM>) may be sent in one RADIUS CoA or Access-Accept message. The DN-AAA shall always provide the full list of allowed MAC addresses, and SMF shall replace the existing list with the newly received one. When omitted, there is no restriction and all UE MAC addresses are permitted for the Ethernet PDU session.

When sending from the SMF to the DN-AAA, it indicates UE MAC addresses in use. Multiple 3GPP-MAC-Address sub-attributes may be sent in one RADIUS Access-Request or Accounting-Request Interim-Update message.

Authorization Data Reference: Octet String. It is sent from the DN-AAA to refer to the local authorization data in the SMF.

Policy Data Reference: Octet String. It is sent from the DN-AAA and used by the SMF to retrieve the SM or QoS policy data from the PCF.

Session AMBR: Octet String. It is sent from the DN-AAA to authorize the PDU Session AMBR. The encoding is defined as BitRate in 3GPP TS <NUM> [<NUM>].

If the feature eSessionAMBR is supported and if applicable, the DN-AAA shall send this VSA; otherwise, the DN-AAA shall send the VSA 3GPP-Session-AMBR.

This VSA may be present in the Access-Request (initial one) message and either the Access-Challenge (initial one) or the Access-Accept message. If present, this VSA informs the destination entity about the features that the origin entity requires to successfully complete the message exchange. The Vendor ID, Feature List ID and Feature List are encoded according to 3GPP TS <NUM> [<NUM>]. See clause <NUM>. <NUM> for more detailed information regarding the general principle of the feature negotiation with the difference that RADIUS terms replace Diameter terms. The table <NUM>. <NUM>-<NUM> defines the features applicable to the RADIUS N6 interfaces for the feature lists with a Feature-List-ID of <NUM>.

The SMF may determine an IP address pool ID based on UPF ID, S-NSSAI, DNN, and IP version as described in subclause <NUM>. <NUM> in 3GPP TS <NUM> [<NUM>] and includes the IP address pool ID within 3GPP-IP-Address-Pool-Info and send it to the DN-AAA. The DN-AAA assigns IPv6 prefix or IPv4 address from the requested IP address pool. Multiple 3GPP-IP-Address-Pool-Info sub-attributes may be sent in the RADIUS Access-Request message. The DN-AAA shall include the selected IP address pool in the 3GPP-IP-Address-Pool-Info sub-attribute of the RADIUS Access-Accept message. For accounting, if Framed-IP-Address or Framed-lpv6-Prefix attribute is included in RADIUS Accounting-Request (START/interim-Update/STOP), the SMF shall also include the 3GPP-IP-Address-Pool-Info sub-attribute.

Table <NUM>-<NUM> describes the sub-attributes of the 3GPP Vendor-Specific attribute described above in different RADIUS messages.

RADIUS attributes related to the DN-AAA initiated re-authorization and authentication challenge are described in the following subclauses.

Table <NUM>-<NUM> lists the Diameter AVPs re-used by the N6 reference point from existing Diameter Applications, reference to the respective specifications and a short description of the usage within the N6 reference point.

This clause describes the N6 Diameter messages.

The relevant AVPs that are of use for the N6 interface are detailed in this subclause. Other Diameter AVPs as defined in IETF RFC <NUM> [<NUM>] and IETF RFC <NUM> [<NUM>], even if their AVP flag rules are marked with "M", are not required for being compliant with the current specification.

Diameter messages as defined in subclause <NUM> of 3GPP TS <NUM> [<NUM>] are re-used in <NUM> with the following differences:.

NOTE: N6 re-used and specific AVPs are specified in subclause <NUM> and subclause <NUM>.

The DER command, defined in IETF RFC <NUM> [<NUM>], is indicated by the Command-Code field set to <NUM> and the 'R' bit set in the Command Flags field. It is sent by the SMF to the DN-AAA server upon reception of an initial access request (e.g. Nsmf_PDUSession_CreateSMContext) message for a given DNN to request user authentication and authorization.

The relevant AVPs that are of use for the N6 interface are detailed in the ABNF description below. Other valid AVPs for this command are not used for N6 purposes and should be ignored by the receiver or processed according to the relevant specifications. The bold marked AVPs in the message format indicate new optional AVPs for N6, or modified existing AVPs.

<Diameter-EAP-Request> ::= < Diameter Header: <NUM>, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Request-Type }
[ Destination-Host ]
[ NAS-Port ]
[ NAS-Port-Id ]
[ NAS-Port-Type ]
[ Origin-State-Id ]
[ Port-Limit ]
[ User-Name ]
{ EAP-Payload }
[ EAP-Key-Name ]
[ Service-Type ]
[ Authorization-Lifetime ]
[ Auth-Grace-Period ]
[ Auth-Session-State ]
[ Callback-Number ]
[ Called-Station-Id ]
[ Calling-Station-Id ]
[ Originating-Line-Info ]
[ Connect-Info ]
* [ Framed-Compression ]
[ Framed-Interface-Id ]
[ Framed-IP-Address ]
* [ Framed-Ipv6-Prefix ]
* [ Delegated-Ipv6-Prefix ]
[ Framed-IP-Netmask ]
[ Framed-MTU ]
[ Framed-Protocol ]
* [ Tunneling ]
* [ Proxy-Info ]
* [ Route-Record ]
[ External-Identifier ]
[ 3GPP-IMSI ]
[ 3GPP-NAI ]
* [ 3GPP-UE-MAC-Address ]
[ 3GPP-Charging-ID ]
[ 3GPP-PDP-Type ]
[ 3GPP-CG-Address ]
[ 3GPP-GPRS-Negotiated-QoS-Profile ]
[ 3GPP-SGSN-Address ]
[ 3GPP-GGSN-Address ]
[ 3GPP-IMSI-MCC-MNC ]
[ 3GPP-GGSN-MCC-MNC ]
[ 3GPP-NSAPI ]
[ 3GPP-Selection-Mode ]
[ 3GPP-Charging-Characteristics ]
[ 3GPP-CG-Ipv6-Address ]
[ 3GPP-SGSN-Ipv6-Address ]
[ 3GPP-GGSN-Ipv6-Address ]
[ 3GPP-SGSN-MCC-MNC ]
[ 3GPP-User-Location-Info ]
[ 3GPP-RAT-Type ]
[ 3GPP-Negotiated-DSCP ]
[ 3GPP-Allocate-IP-Type ]
[ TWAN-Identifier ]
* [ 3GPP-IP-Address-Pool-Info]
* [ Supported-Features ]
* [ AVP ].

The DEA command, defined in IETF RFC <NUM> [<NUM>], is indicated by the Command-Code field set to <NUM> and the 'R' bit cleared in the Command Flags field. It is sent by the DN-AAA server to the SMF in response to the DER command.

<Diameter-EAP-Answer> ::= < Diameter Header: <NUM>, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Request-Type }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ User-Name ]
[ EAP-Payload ]
[ EAP-Reissued-Payload ]
[ EAP-Master-Session-Key ]
[ EAP-Key-Name ]
[ Multi-Round-Time-Out ]
[ Accounting-EAP-Auth-Method ]
[ Service-Type ]
* [ Class ]
[ Acct-Interim-Interval ]
[ Error-Message ]
[ Error-Reporting-Host ]
[ Failed-AVP ]
[ Idle-Timeout ]
[ Authorization-Lifetime ]
[ Auth-Grace-Period ]
[ Auth-Session-State ]
[ Re-Auth-Request-Type ]
[ Session-Timeout ]
* [ Reply-Message ]
[ Origin-State-Id ]
* [ Filter-Id ]
[ Port-Limit ]
[ Callback-Id ]
[ Callback-Number ]
* [ Framed-Compression ]
[ Framed-Interface-Id ]
[ Framed-IP-Address ]
* [ Framed-Ipv6-Prefix ]
[ Framed-Ipv6-Pool ]
* [ Framed-Ipv6-Route ]
* [ Delegated-Ipv6-Prefix ]
[ Framed-IP-Netmask ]
* [ Framed-Route ]
[ Framed-Pool ]
[ Framed-IPX-Network ]
[ Framed-MTU ]
[ Framed-Protocol ]
[ Framed-Routing ]
* [ NAS-Filter-Rule ]
* [ QoS-Filter-Rule ]
* [ Tunneling ]
* [ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
* [ Proxy-Info ]
* [ External-Identifier ]
[ 3GPP-Ipv6-DNS-Servers ]
[ 3GPP-Notification ]
<NUM>*<NUM> [ 3GPP-UE-MAC-Address ]
[ 3GPP-Authorization-Reference ]
[ 3GPP-Policy-Reference ]
[ 3GPP-Session-AMBR ]
[ 3GPP-Session-AMBR-v2 ]
<NUM>*<NUM> [ 3GPP-IP-Address-Pool-Info]
* [ Supported-Features ]
* [ AVP ].

Please note that the terms "indicator" and "attribute" may be interchangeably used herein.

Next, some specific embodiments of the present disclosure in which the above attribute is used will be explained with reference to <FIG> and <FIG> in conjunction with <FIG>.

<FIG> is a message flow diagram illustrating exemplary messages exchanged between different nodes (e.g. the nodes shown in <FIG>) for facilitating reuse of an IP address according to an embodiment of the present disclosure. To be specific, <FIG> shows a UE-initiated PDU session establishment procedure in a non-roaming scenario. However, it is merely an example to illustrate the principle of the present disclosure and therefore the present disclosure is not limited thereto.

As shown in <FIG>, a UE (e.g. the UE <NUM> shown in <FIG>) tries to establish a new PDU session within the operator domain (e.g., the operator domain <NUM> shown in <FIG>), and the description of the steps of the procedure is given below.

A PDU Session Establishment Request is transmitted from the UE-<NUM><NUM> to the AMF <NUM>, in which a new PDU session ID may be generated and included by the UE-<NUM><NUM>. The UE-<NUM><NUM> may initiate the UE Requested PDU Session Establishment procedure by the transmission of a NAS message containing a PDU Session Establishment Request within the N1 SM container.

The AMF <NUM> may select an SMF (e.g. the SMF <NUM>) for the UE-<NUM><NUM>'s PDU Session Establishment Request, for example, based on the parameters comprised in the message and/or configurations/policies stored locally or externally (e.g. at UDM or PCF).

An Nsmf_PDUSession_CreateSMContext Request message is transmitted from the AMF <NUM> to the selected SMF <NUM> to request the SMF <NUM> to be associated for the PDU session to be created.

The SMF <NUM> may retrieve or update the Session Management Subscription data from UDM, which is not shown in <FIG>.

An Nsmf_PDUSession_CreateSMContext Response message may be transmitted from the SMF <NUM> to the AMF <NUM> in response to the request message in step S303. If the SMF <NUM> received the Nsmf_PDUSession_CreateSMContext Request in step S303 and the SMF <NUM> is able to process the PDU Session establishment request, the SMF <NUM> may create an SM context and responds to the AMF <NUM> by providing an SM Context ID. On the other hand, when the SMF <NUM> decides to not accept to establish a PDU Session, the SMF <NUM> may reject the UE request via NAS SM signalling including a relevant SM rejection cause by responding to the AMF <NUM> with Nsmf_PDUSession_CreateSMContext Response. The SMF <NUM> may also indicate to the AMF <NUM> that the PDU Session ID is to be considered as released, and the PDU Session Establishment procedure may be stopped.

The SMF <NUM> decides that a secondary authentication/authorization is to be performed, and therefore an Access Request message may be transmitted from the SMF <NUM> to the DN-AAA/Authentication <NUM>. As mentioned earlier, one or more 3GPP-IP-Address-Pool-Infos attributes indicating one or more available IP address pools may be included in the Access Request message such that the DN-AAA/Authentication <NUM> is enabled to select one of them and allocate, to the UE-<NUM><NUM>, an IP address from the selected IP address pool.

An Access-Accept message may be transmitted from the DN-AAA/Authentication <NUM> to the SMF <NUM> to indicate its selection of the IP address pool (or its corresponding UPF <NUM>), for example, by the selected 3GPP-IP-Address-Pool-Info attribute. Further, some optional steps may be performed, for example, PCF selection/SM policy association establishment or modification. Since these steps are not directly related to the embodiments of the present disclosure, the description thereof is omitted for simplicity.

The SMF <NUM> may select a UPF (e.g. the UPF <NUM>) as the anchor of this PDU Session based on the received 3GPP-IP-Address-Pool-Info attribute included in the Access Accept message. Further, if Request Type indicates "initial request", the SMF <NUM> may initiate an N4 Session Establishment procedure with the selected UPF <NUM>, otherwise it initiates an N4 Session Modification procedure with the selected UPF <NUM>.

An Namf_Communication_N1N2MessageTransfer message may be transmitted from the SMF <NUM> to the AMF <NUM> to inform the AMF <NUM> of various parameters, such as the allocated IP address (an IPv4 address, a IPv6 prefix, or both), QoS parameters, etc..

An N2 PDU Session Request may be transmitted from the AMF <NUM> to (R)AN, which is not shown in <FIG> and in turn issues AN specific signalling exchange with the UE-<NUM><NUM> that is related with the information received from the SMF <NUM>. In other words, the AMF <NUM> may indicate "PDU Session Establishment Accept" to the UE-<NUM><NUM> via signalling specific to the gNB-<NUM><NUM>.

After that, a PDU session is successfully established for the UE-<NUM><NUM>, and UE-<NUM><NUM> may communicate its uplink/downlink data with the Internet <NUM> via the firewall/NAT at the selected UPF <NUM>, as shown in <FIG>.

<FIG> is another message flow diagram illustrating exemplary messages exchanged between different nodes (e.g. the nodes shown in <FIG>) for facilitating reuse of an IP address according to another embodiment of the present disclosure. For the purpose of simplicity, description of some steps in <FIG> which are same or similar to those shown in <FIG> is omitted. For example, the steps before step S401 and after step S411 are omitted for simplicity. Further, the step S401 and step S402 in <FIG> may be similar to the step S306 and step S307, respectively, and the detailed description thereof is omitted.

At steps S401 and S402, the SMF <NUM> successfully obtains information necessary for the subsequent steps from the DN-AAA/Authentication <NUM>, such as, the selected 3GPP-IP-Address-Pool-Info and the allocated IPv4 address/IPv6 prefix, as shown in <FIG>.

After that, at step S403, the SMF <NUM> may transmit an Accounting-Request Start message (or to be specific, an Accounting-Request message with the attribute "Acct-Status-Type" set to be <NUM>) to the DN-AAA/Accounting <NUM> to start accounting service for the PDU session (e.g. the PDU session established for the UE-<NUM><NUM>). The Accounting-Request Start message may comprise the information obtained at the step S402, such as, the selected 3GPP-IP-Address-Pool-Info and the allocated IPv4 address/IPv6 prefix. In some embodiments, the message may further comprise information or attribute for identifying the target network, such as, "Called-Station-Id", which indicates the target network to be accessed, i.e. APN/DNN.

At step S404, upon receipt of the Accounting-Request Start message comprising the selected 3GPP-IP-Address-Pool-Info and the allocated IPv4 address/IPv6 prefix, the DN-AAA/Accounting <NUM> may now correctly identify the PDU session or the UE, even if a same IPv4 address/IPv6 prefix and a same APN/DNN are used by different PDU sessions or UEs. Therefore, the DN-AAA/Accounting <NUM> may respond to the SMF <NUM> with an Accounting-Response Start message (or to be specific, an Accounting-Response message with the attribute "Acct-Status-Type" set to be <NUM>) to indicate that the accounting service for the PDU session is started.

Later, the AMF <NUM> and the SMF <NUM> may exchange messages at steps S405 and S406, such as Namf_Communication_N1N2MessageTransfer or Nsmf_PDUSession_UpdateSMContext, and therefore the AMF <NUM> is notified of a successful establishment of the PDU session, and later an update of the accounting service for the PDU session may be triggered.

In such a case, at step S407, the SMF <NUM> may transmit an Accounting-Request Interim Update message (or to be specific, an Accounting-Request message with the attribute "Acct-Status-Type" set to be <NUM>) to the DN-AAA/Accounting <NUM> to update accounting service for the PDU session. Similarly, the Accounting-Request Interim Update message may also comprise the information obtained at the step S402, such as, the selected 3GPP-IP-Address-Pool-Info and the allocated IPv4 address/IPv6 prefix. In some embodiments, the message may further comprise information or attribute for identifying the target network, such as, "Called-Station-Id".

At step S408, upon receipt of the Accounting-Request Interim Update message comprising the selected 3GPP-IP-Address-Pool-Info and the allocated IPv4 address/IPv6 prefix, the DN-AAA/Accounting <NUM> may now correctly identify the PDU session or the UE, even if a same IPv4 address/IPv6 prefix and a same APN/DNN are used by different PDU sessions or UEs. Therefore, the DN-AAA/Accounting <NUM> may respond to the SMF <NUM> with an Accounting-Response Interim Update message (or to be specific, an Accounting-Response message with the attribute "Acct-Status-Type" set to be <NUM>) to indicate that the accounting service for the PDU session is updated.

Later, the AMF <NUM> may transmit a message to the SMF <NUM> at steps S409, such as Nsmf_PDUSession_ReleaseSMContext, and therefore a release of the accounting service for the PDU session is triggered.

In such a case, at step S410, the SMF <NUM> may transmit an Accounting-Request Stop message (or to be specific, an Accounting-Request message with the attribute "Acct-Status-Type" set to be <NUM>) to the DN-AAA/Accounting <NUM> to stop the accounting service for the PDU session. Similarly, the Accounting-Request Stop message may also comprise the information obtained at the step S402, such as, the selected 3GPP-IP-Address-Pool-Info and the allocated IPv4 address/IPv6 prefix. In some embodiments, the message may further comprise information or attribute for identifying the target network, such as, "Called-Station-Id".

At step S411, upon receipt of the Accounting-Request Stop message comprising the selected 3GPP-IP-Address-Pool-Info and the allocated IPv4 address/IPv6 prefix, the DN-AAA/Accounting <NUM> may now correctly identify the PDU session or the UE, even if a same IPv4 address/IPv6 prefix and a same APN/DNN are used by different PDU sessions or UEs. Therefore, the DN-AAA/Accounting <NUM> may respond to the SMF <NUM> with an Accounting-Response Stop message (or to be specific, an Accounting-Response message with the attribute "Acct-Status-Type" set to be <NUM>) to indicate that the accounting service for the PDU session is stopped.

After that, the PDU session for the UE-<NUM><NUM> may be terminated and resources allocated to this PDU session may be released.

Therefore, from the above description with reference to <FIG> and <FIG>, it is clear that the DN-AAA/Accounting server <NUM>, which was previously not aware of the reuse of the same IP address and APN/DNN at multiple UEs, may benefit from the use of attribute "3GPP-IP-Address-Pool-Id", "3GPP-IP-Address-Pool-Info", or another customized RADIUS attribute in the Accounting-Request Start/Interim Update/Stop messages. Further, the SMF <NUM> may now know the selection of the UPF by the DN-AAA/Authentication <NUM> with "3GPP-IP-Address-Pool-Id", "3GPP-IP-Address-Pool-Info", or another customized RADIUS attribute in the Access Accept message, which may be later used for accounting service related operations. Furthermore, when a dual IP stack (i.e. IPv4v6) is needed, the additional field "IP version" in the attribute "3GPP-IP-Address-Pool-Info" may help the DN-AAA/Authentication <NUM> in identifying the correct IP address pool from which an IP address is allocated to the PDU session.

<FIG> is a flow chart of an exemplary method <NUM> for facilitating reuse of an IP address at multiple User Equipments (UEs) (e.g. the UE-<NUM><NUM>, UE-<NUM><NUM>, UE-<NUM><NUM>, UE-<NUM><NUM>) according to an embodiment of the present disclosure. The method <NUM> may be performed at a first network element (e.g. the SMF <NUM> shown in <FIG> or the network element <NUM> shown in <FIG>) for reuse of IP addresses. The method <NUM> may comprise step S510 and an optional Step S520. However, the present disclosure is not limited thereto. In some other embodiments, the method <NUM> may comprise more steps, less steps, different steps or any combination thereof. Further the steps of the method <NUM> may be performed in a different order than that described herein. Further, in some embodiments, a step in the method <NUM> may be split into multiple sub-steps and performed by different entities, and/or multiple steps in the method <NUM> may be combined into a single step.

The method <NUM> may begin at step S510 where a first request message associated with the first UE may be transmitted to a second network element. In some embodiments, the first request message may comprise the IP address and a first indicator which, in conjunction with the IP address, uniquely identifies the first UE.

In some embodiments, the method <NUM> may further comprise a step S520 where a first response message associated with the first UE may be received from the second network element in response to the first request message. In some embodiments, the second network element may be a part of an Authentication, Authorization and Accounting (AAA) server for accounting. In some embodiments, the first request message may be one of: an Accounting-Request START message, an Accounting-Request STOP message, and an Accounting-Request Interim-Update message, and the first response message is a corresponding one of: an Accounting-Response START message, an Accounting-Response STOP message, and an Accounting-Response Interim-Update message.

In some embodiments, before the step S510, the method <NUM> may further comprise steps of: transmitting, to a third network element, a second request message associated with the first UE, the second request message comprising one or more second indicators, each of which indicates an IP address pool from which one or more IP addresses are available to be allocated to the first UE; and receiving, from the third network element, a second response message in response to the second request message, the second response message comprising a third indicator which identifies an IP address pool of the one or more IP addresses pools indicated by the one or more second indicators, wherein the IP address from the identified IP address pool is allocated to the first UE.

In some embodiments, the method may further comprise: selecting a User Plane Function (UPF) for the first UE based at least partially on the third indicator. In some embodiments, the third network element may be a part of an AAA server for authentication. In some embodiments, the second request message may be an Access Request message or a Diameter-Extensible Authentication Protocol (EAP)-Request (DER) message, and the second response message may be a corresponding one of an Access Accept message or a Diameter-EAP-Answer (DEA) message. In some embodiments, each of the first indicator, one or more second indicators, and the third indicator may comprise a first field uniquely identifying an IP address pool from which the IP address is allocated to the first UE. In some embodiments, each of the first indicator, the one or more second indicators, and the third indicator may further comprise a second field indicating an IP version applicable for the IP address pool identified by the first field. In some embodiments, the second field may indicate one of IPv4, IPv6, or both. In some embodiments, each of the first indicator, the one or more second indicators, and the third indicator further comprises a third field indicating the length of the first field. In some embodiments, each of the first indicator, the one or more second indicators, and the third indicator may be a 3GPP-IP-Address-Pool-Id attribute, a 3GPP-IP-Address-Pool-Info attribute, or a customized Remote Authentication Dial In User Service (RADIUS) attribute. In some embodiments, the first request message may further comprise a fourth indicator identifying a network to be accessed by the first UE.

In some embodiments, the fourth indicator may be a Called-Station-Id attribute or a customized RADIUS attribute. In some embodiments, the IP address may comprise an IPv4 address, an IPv6 prefix, or both. In some embodiments, the first network element may be a Session Management Function (SMF) or a Packet Data Network (PDN) Gateway for Control Plane (PGW-C).

<FIG> is a flow chart of an exemplary method <NUM> for facilitating reuse of an IP address at multiple User Equipments (UEs) (e.g. the UE-<NUM><NUM>, UE-<NUM><NUM>, UE-<NUM><NUM>, UE-<NUM><NUM>) according to an embodiment of the present disclosure. The method <NUM> may be performed at a second network element (e.g. the DN-AAA/Accounting <NUM> shown in <FIG> or the network element <NUM> shown in <FIG>) for reuse of IP addresses. The method <NUM> may comprise step S610 and step S620. However, the present disclosure is not limited thereto. In some other embodiments, the method <NUM> may comprise more steps, less steps, different steps or any combination thereof. Further the steps of the method <NUM> may be performed in a different order than that described herein. Further, in some embodiments, a step in the method <NUM> may be split into multiple sub-steps and performed by different entities, and/or multiple steps in the method <NUM> may be combined into a single step.

The method <NUM> may begin at step S610 where a first request message associated with the first UE may be received from a first network element. In some embodiments, the first request message may comprise the IP address and a first indicator which, in conjunction with the IP address, uniquely identifies the first UE.

At step S620, processing for the first UE identified by the first indicator in conjunction with the IP address may be performed.

In some embodiments, the method <NUM> may further comprise a step of transmitting, to the first network element, a first response message associated with the first UE based on a result of the processing. In some embodiments, the second network element may be a part of an Authentication, Authorization and Accounting (AAA) server for accounting. In some embodiments, the first request message may be one of: an Accounting-Request START message, an Accounting-Request STOP message, and an Accounting-Request Interim-Update message, and the first response message may be a corresponding one of: an Accounting-Response START message, an Accounting-Response STOP message, and an Accounting-Response Interim-Update message. In some embodiments, the first indicator may comprise a first field uniquely identifying an IP address pool from which the IP address is allocated to the first UE. In some embodiments, the first indicator may further comprise a second field indicating an IP version applicable for the IP address pool identified by the first field. In some embodiments, the second field may indicate one of IPv4, IPv6, or both. In some embodiments, the first indicator further comprises a third field indicating the length of the first field. In some embodiments, the first indicator may be a 3GPP-IP-Address-Pool-Id attribute, a 3GPP-IP-Address-Pool-Info attribute, or a customized Remote Authentication Dial In User Service attribute. In some embodiments, the first request message may further comprise a fourth indicator identifying a network to be accessed by the first UE. In some embodiments, the fourth indicator may be a Called-Station-Id attribute or a customized RADIUS attribute. In some embodiments, the IP address may comprise an IPv4 address, an IPv6 prefix, or both. In some embodiments, the first network element may be a Session Management Function (SMF) or a Packet Data Network (PDN) Gateway for Control Plane (PGW-C).

<FIG> is a flow chart of an exemplary method <NUM> for facilitating reuse of an IP address at multiple User Equipments (UEs) (e.g. the UE-<NUM><NUM>, UE-<NUM><NUM>, UE-<NUM><NUM>, UE-<NUM><NUM>) not being part of the present invention. The method <NUM> may be performed at a third network element (e.g. the DN-AAA/Authentication <NUM> shown in <FIG> or the network element <NUM> shown in <FIG>) for reuse of IP addresses. The method <NUM> may comprise step S710, step S720, and step S730. However, the present disclosure is not limited thereto. The method <NUM> may comprise more steps, less steps, different steps or any combination thereof. Further the steps of the method <NUM> may be performed in a different order than that described herein. Further, a step in the method <NUM> may be split into multiple sub-steps and performed by different entities, and/or multiple steps in the method <NUM> may be combined into a single step.

The method <NUM> may begin at step S710 where a second request message associated with the first UE is received from a first network element. In some embodiments, the second request message may comprise one or more second indicators, each of which indicates an IP address pool from which one or more IP addresses are available to be allocated to the first UE.

At step S720, a first IP address pool is determined, from one or more IP address pools indicated by the one or more second indicators, to be allocated to the first UE.

At step S730, a second response message comprising a third indicator which identifies the first IP address pool is transmitted to the first network element.

In some embodiments, the third network element may be a part of an AAA server for authentication. The second request message may be an Access Request message or a Diameter-Extensible Authentication Protocol (EAP)-Request (DER) message, and the second response message may be a corresponding one of an Access Accept message or a Diameter-EAP-Answer (DEA) message. In some embodiments, each of the one or more second indicators and the third indicator may comprise a first field uniquely identifying the first IP address pool. In some embodiments, each of the one or more second indicators and the third indicator may further comprise a second field indicating an IP version applicable for the IP address pool identified by the first field. In some embodiments, the second field may indicate one of IPv4, IPv6, or both. In some embodiments, each of the one or more second indicators and the third indicator further comprises a third field indicating the length of the first field. In some embodiments, each of the one or more second indicators and the third indicator may be a 3GPP-IP-Address-Pool-Id attribute, a 3GPP-IP-Address-Pool-Info attribute, or a customized Remote Authentication Dial In User Service (RADIUS) attribute. In some embodiments, the IP address may comprise an IPv4 address, an IPv6 prefix, or both. In some embodiments, the first network element may be a Session Management Function (SMF) or a Packet Data Network (PDN) GateWay for Control Plane (PGW-C).

According to present disclosure, a method at a first network element (<NUM>) for facilitating reuse of an Internet Protocol (IP) address at multiple User Equipments (UEs) comprising a first UE, is provided. The method may comprise: transmitting to a second network element (<NUM>), a request message associated with the first UE, the first request message comprising an indicator which indicates information on IP address pool, wherein the information on IP address pool indicates the IP version of the IP address pool; and receiving, from the third network element (<NUM>), a response message in response to the request message, the response message comprising the indicator which indicates information on IP address pool, wherein the information on IP address pool indicates the IP version of the IP address pool. In some embodiments, the request message may be one of: Access request message, accounting request message, DER Command, AAR Command, and ACR Command; the response message may be one of: Access accept message, accounting response message, DEA message, AAA Command, and ACA Command.

<FIG> schematically shows an embodiment of an arrangement <NUM> which may be used in a network element (e.g., the first network element, the second network element, or the third network element) according to an embodiment of the present disclosure. Comprised in the arrangement <NUM> are a processing unit <NUM>, e.g., with a Digital Signal Processor (DSP) or a Central Processing Unit (CPU). The processing unit <NUM> may be a single unit or a plurality of units to perform different actions of procedures described herein. The arrangement <NUM> may also comprise an input unit <NUM> for receiving signals from other entities, and an output unit <NUM> for providing signal(s) to other entities. The input unit <NUM> and the output unit <NUM> may be arranged as an integrated entity or as separate entities.

Furthermore, the arrangement <NUM> may comprise at least one computer program product <NUM> in the form of a non-volatile or volatile memory, e.g., an Electrically Erasable Programmable Read-Only Memory (EEPROM), a flash memory and/or a hard drive. The computer program product <NUM> comprises a computer program <NUM>, which comprises code/computer readable instructions, which when executed by the processing unit <NUM> in the arrangement <NUM> causes the arrangement <NUM> and/or the network elements in which it is comprised to perform the actions, e.g., of the procedure described earlier in conjunction with <FIG> or any other variant.

The computer program <NUM> may be configured as a computer program code structured in computer program modules 810A. Hence, in an exemplifying embodiment when the arrangement <NUM> is used in a first network element, the code in the computer program of the arrangement <NUM> includes: a transmission module 810A for transmitting, to a second network element, a first request message associated with the first UE, the first request message comprising the IP address and a first indicator which, in conjunction with the IP address, uniquely identifies the first UE.

Further, the computer program <NUM> may be configured as a computer program code structured in computer program modules 810A and 810B. Hence, in an exemplifying embodiment when the arrangement <NUM> is used in a second network element, the code in the computer program of the arrangement <NUM> includes: a reception module 810A for receiving, from a first network element, a first request message associated with the first UE, the first request message comprising the IP address and a first indicator which, in conjunction with the IP address, uniquely identifies the first UE; and a performing module 810B for performing processing for the first UE identified by the first indicator in conjunction with the IP address.

Furthermore, the computer program <NUM> may be configured as a computer program code structured in computer program modules 810A, 810B, and 810C. Hence, in an exemplifying embodiment when the arrangement <NUM> is used in a third network element, the code in the computer program of the arrangement <NUM> includes: a reception module 810A for receiving, from a first network element, a second request message associated with the first UE, the second request message comprising one or more second indicators, each of which indicates an IP address pool from which one or more IP addresses are available to be allocated to the first UE; a determination module 810B for determining a first IP address pool from one or more IP address pools indicated by the one or more second indicators to be allocated to the first UE; and a transmission module 810C for transmitting, to the first network element, a second response message comprising a third indicator which identifies the first IP address pool.

The computer program modules could essentially perform the actions of the flow illustrated in <FIG>, to emulate the network elements. In other words, when the different computer program modules are executed in the processing unit <NUM>, they may correspond to different modules in the various network elements.

Although the code means in the embodiments disclosed above in conjunction with <FIG> are implemented as computer program modules which when executed in the processing unit causes the arrangement to perform the actions described above in conjunction with the figures mentioned above, at least one of the code means may in alternative embodiments be implemented at least partly as hardware circuits.

Claim 1:
A method (<NUM>) at a Session Management Function, SMF, (<NUM>) for facilitating reuse of a private Internet Protocol, IP, address at multiple User Equipments, UEs, comprising (i) a first UE (<NUM>, <NUM>, <NUM>, <NUM>), wherein a first User Plane Function, UPF (<NUM>) and a second UPF (<NUM>) are connected to the SMF, wherein the first UPF maintains a first private IP address range and the second UPF maintains a second private IP address range, and wherein the first and second private IP address ranges are at least partially identical, the method comprising:
transmitting (<NUM>, <NUM>, <NUM>, <NUM>), to a Data Network-Authentication, Authorization & Accounting, DN-AAA, accounting server (<NUM>), a first request message associated with the first UE (<NUM>, <NUM>, <NUM>, <NUM>), the first request message comprising (i) the private IP address comprising an IPv4 address not being globally unique, and (ii) a selected first 3GPP-IP-Address-Pool-Info which, in conjunction with the private IP address, uniquely identifies a Protocol Data Unit, PDU, session of the first UE (<NUM>, <NUM>, <NUM>, <NUM>), wherein the first 3GPP-IP-Address-Pool-Info indicates information on an IP address pool applicable to the private IP address; and
receiving (<NUM>, <NUM>, <NUM>, <NUM>), from the DN-AAA accounting server (<NUM>), a first response message associated with the first UE (<NUM>, <NUM>, <NUM>, <NUM>) in response to the first request message,
wherein:
- the first request message is one of: an Accounting-Request START message, an Accounting-Request STOP message, an ACR Command, and an Accounting-Request Interim-Update message, and
- the first response message is a corresponding one of: an Accounting-Response START message, an Accounting-Response STOP message, an ACA Command, and an Accounting-Response Interim-Update message.