UFS Explained: The Flash Storage Inside Your Phone

A phone’s storage is built on the same idea as an SSD, with NAND flash and a controller working together. In a phone they share one package soldered to the board, and Universal Flash StorageUniversal Flash Storage is the JEDEC flash storage standard for phones and mobile devices. Its serial link has separate read and write paths, so it reads and writes at once., or UFS, is the JEDEC standard for that package and the link it talks over. UFS does for a phone what NVMe over PCIe does for an SSD. It sets how fast stored data can reach the processor and how many requests can wait in line at once.

How NAND stores a bit is in Flash Foundations, and the SSD side of the interface story is Part 1: Standards and interfaces. This guide answers one question. It covers what a UFS version number or a phone’s storage spec promises, and what only the maker can say, read against the standard’s own limits.

JEDEC charges non-members for the UFS standard, so every figure here comes from public pages and releases, and a maker’s figure is that maker’s claim.

UFS is JEDEC layers on a MIPI link

JEDEC published the first UFS standard on February 24, 2011, as one specification for both embedded and removable flash in phones and tablets. Its JC-64 committee maintains it. In JEDEC’s description, UFS is a high-performance interface for uses where power has to stay low, and its newer releases name cars alongside phones and tablets.

UFS is built in layers, and only the top ones are JEDEC’s own. The Linux kernel’s UFS documentation lays them out. At the top, the application layer holds the UFS command set, a task manager that controls the command queue, and a device manager for power and configuration. UFS chose SCSISCSI is a family of standards for storage interfaces and commands. SAS still uses the SCSI command set, over a serial link in place of the older parallel SCSI bus. as its command protocol and supports a subset of the SPC-4 and SBC-3 commands. Below it, the UFS Transport Protocol (UTP) layer carries every command, response, and block of data in a UFS protocol information unit, or UPIUA UPIU is the message format UFS uses between host and device. Commands, task management requests, queries and their responses all travel as UPIUs.. At the bottom, the UFS interconnect (UIC) layer is two MIPI Alliance specifications, with UniPro for the link and M-PHYM-PHY is the MIPI physical layer that carries UFS traffic. It sits under UniPro, and together the two form the high-speed serial link between host and flash device. for the wires.

Figure 1 shows that each layer talks to its twin on the other end of the link. The host side has one more piece below the stack. The host controller follows the UFS Host Controller Interface (UFSHCI). That companion JEDEC standard gives every UFS host controller the same registers, so one driver works with hardware from any vendor. In Linux that driver, ufshcd, sits under the SCSI midlayer, so the kernel treats UFS storage as a SCSI disk. NVMe took the other road on SSDs and wrote its own command set, as Part 1 shows.

JEDEC also lists companion standards beside the main one, including JESD220-5, a zoned storage extension for UFS. On SSDs, zoned storage takes the form of zoned namespaces, covered in Flash Foundations, Part 10.

How UFS differs from eMMC and NVMe

Before UFS, phones used eMMCAn eMMC is managed NAND flash for mobile applications: flash memory and its controller in one embedded memory system. Its parallel interface sends data one direction at a time., short for embedded MultiMediaCard. It puts NAND flash and a flash controller in one small ball grid array (BGA) package, so the phone’s system on chip (SoC) never manages raw flash. Flash Foundations Part 1 covers soldered BGA storage as a form factor. JEDEC’s eMMC 5.0, published October 1, 2013, added an HS400 mode of up to 400MB/s, against 200MB/s in the version before. eMMC 5.1, published February 24, 2015, added command queueing for the first time, where earlier versions ran one command at a time. JEDEC still maintains eMMC, and its latest revision, 5.1B, came out in September 2025. Part 2, eMMC Explained covers the eMMC bus, partitions and real parts.

Wiring is the bigger difference. eMMC uses a parallel bus that moves data one way at a time, so the host reads or writes but never both at once. UFS uses low-voltage differential serial lanes with a separate path for each direction, so it can read and write at the same time. Samsung claims its UFS 2.0 reached 1.40 times the sequential read speed of eMMC 5.0, 1.66 times the sequential write, 2.71 times the random read and 1.07 times the random write.

In Figure 2, UFS 5.0 moves up to 10.8GB/s each way over two lanes per direction, while eMMC’s 400MB/s is shared between reads and writes. An NVMe SSD uses four PCIe lanes per direction. A Gen4 x4 link carries about 8GB/s and a Gen5 x4 link about 16GB/s, so a UFS 5.0 link sits between the two. All of these are limits of the link, not drive results, because a drive’s real speed depends on its NAND, controller, and firmware.

A UFS link also saves power between bursts. According to FreeBSD’s UFS write-up, the link raises its gear only while I/O is active and drops to a low-power state when it goes idle, and the standard defines the power-state transitions so host and device agree on each step.

AnandTech reported in 2015 that the iPhone 6s used PCIe and NVMe for storage instead of UFS or eMMC, and the Linux kernel carries an NVMe host driver for Apple’s ANS storage controller.

M-PHY gears and UniPro: each gear about doubles the last

M-PHY sends each lane over a differential pair with the clock embedded in the data. Tektronix’s M-PHY test note ties that to 8b/10b coding, where every 8 data bits go out as 10 bits on the wire. M-PHY has two modes. Low-speed mode uses pulse-width modulation (PWM) and is self-clocking. High-speed mode runs in numbered gears, and each gear about doubles the one before.

The Linux kernel documentation lists two rates, A and B, for gears 1 to 3: HS-G1 at 1,248Mb/s or 1,457.6Mb/s, HS-G2 at 2,496 or 2,915.2Mb/s, and HS-G3 at 4,992 or 5,830.4Mb/s. JEDEC quotes the B rates as 2.9Gb/s and 5.8Gb/s, and gives HS-G4 as 11.6Gb/s per lane. M-PHY 5.0 added HS-G5 at 23.32Gb/s per lane and optimized its data rates to simplify the phase-locked loop (PLL) that generates them. M-PHY 6.0, from December 2025, added HS-G6 at up to 46.694Gb/s.

Figure 3 is the ladder. HS-G6 is the first gear that is more than a faster clock. It uses PAM-4 signaling, four voltage levels in place of two, so each symbol carries two bits, and it replaces 8b/10b with a 1b1b line code that brings coding overhead below 10%, in MIPI’s account. HS-G6 also adds optional link equalization and training. PCIe made the same move to four-level signaling at Gen6, covered in Part 1.

UniPro sits on top of M-PHY and turns the lanes into a managed link. It changes gear and lane count through power modes, and since version 1.8 it also watches link quality: it counts NAC and CRCA cyclic redundancy check is a check value sent with data so the receiver can detect errors. On a PCIe link, a failed check makes the sender replay the data. error frames against good traffic and, past a threshold the designer sets, tries to repair the link through equalization or an ADAPT operation. UniPro 2.0, released in 2022 for UFS 4.0, raised the L2 packet payload length from 272 to 1,144 to cut protocol overhead, and shortened high-speed link startup by up to about 8ms.

What each UFS version added

JEDEC has raised the UFS link four times since 2011, for 32 times the starting rate. UFS 2.0 added a faster gear and a second lane, and each major version after it a faster gear. Point releases such as 3.1 and 4.1 keep the link of their major version and add features on top. The Standards page lists each UFS release as a dated row with its source.

Figure 4 plots the raw line rate in each direction, from 2.9Gb/s on one lane in UFS 1.0 to 93.2Gb/s on two lanes in UFS 5.0. Labels on the bars are the throughput JEDEC quotes, which sits below the line rate because line coding and protocol framing take their share.

UFS 1.0 and 1.1

The first standard set an initial throughput of 300MB/s on an M-PHY link targeting up to 2.9Gb/s per lane. The Linux kernel documentation lists HS-G1 as mandatory and HS-G2 as optional for versions 1.0 and 1.1, with HS-G3 left for later. Command queueing and the SCSI architecture model were there from the start, at a time when memory cards and embedded flash processed one command at a time.

UFS 2.0

JEDEC published UFS 2.0 on September 18, 2013. It raised the link from 300MB/s in UFS 1.1 to 600MB/s per lane, and introduced multiple lanes for up to 1.2GB/s in each direction, which is two lanes at 600MB/s. JESD220B lists HS-G3, the 5.8Gb/s gear, as optional. It moved to M-PHY 3.0 and UniPro 1.6, and JEDEC published UFSHCI 2.0 beside it.

Samsung says it became the first maker of 128GB UFS memory in January 2015. AnandTech’s 2015 review of the Galaxy S6 reported that the S6 family was the first shipping implementation of UFS 2.0.

UFS 2.1 and 2.2

JEDEC published UFS 2.1 (JESD220C-2.1) in March 2016. UFS 2.2 (JESD220C-2.2) followed in August 2020 and replaced it, and it brought WriteBooster, which UFS 3.1 had added earlier that year, to the 2.x line.

UFS 3.0 and 3.1

UFS 3.0 (JESD220D, January 30, 2018) was the first version with HS-G4, at up to 11.6Gb/s per lane, and kept two lanes for a maximum of 23.2Gb/s. It moved to M-PHY 4.1 and UniPro 1.8 and added a 2.5V VCC supply, temperature event notification, and a device error history log. Its other additions included two features JEDEC introduced specifically for cars. One was an extended temperature range of -40°C to 105°C, and the other was a refresh operation the host can control to improve data reliability.

UFS 3.1 (JESD220E, January 30, 2020) kept the link and added three features. WriteBooster is a non-volatile single-level cell (SLC) cache that speeds up writes, the same idea as the SLC cache in an SSD. DeepSleep is a low-power state for lower-cost systems that share voltage regulators with other parts. Performance Throttling Notification lets the device tell the host when heat has slowed it down. An optional companion standard called Host Performance Booster (HPB) lets the device cache its logical-to-physical address map in the phone’s DRAM, which helps read speed on large devices.

UFS 4.0 and 4.1

UFS 4.0 (JESD220F, August 17, 2022) moved to M-PHY 5.0 and UniPro 2.0, which doubled the link to up to about 4.2GB/s for reads and writes. Its host controller standard, UFSHCI 4.0, added the multi-circular queue (MCQ)MCQ is a UFS host controller mode with separate submission and completion queues, as NVMe uses, in place of one command list. Several CPU cores can use them at once.. UFS 4.0 drops the 3.3V VCC option the prior version also supported, leaving 2.5V, and it cut latency with high-speed link startup, out-of-order data transfer, and a BARRIER command. It stays compatible with UFS 3.1 and 3.0.

UFS 4.1 (JESD220G) is listed as published in December 2024 and was announced on January 8, 2025. UFS 4.1 keeps the link at up to about 4.2GB/s. Hosts can now ask the device to defragment data to speed up reads, resize the WriteBooster buffer, pin data in it, and flush it in smaller pieces. Logical units can be set as permanently bootable, and vendor commands can require authentication. In JEDEC’s account, finer control over enhanced memory units prepares the way for quad-level cell (QLC) NAND. QLC Is Junk tests what QLC trades away and what it keeps on the SSD side.

UFS 5.0

JEDEC published UFS 5.0 (JESD220H) and UFSHCI 5.0 on February 26, 2026. It supports sequential reads and writes up to 10.8GB/s on M-PHY 6.0 and UniPro 3.0, using HS-G6 at 46.6Gb/s per lane in each direction over two lanes. Beyond speed, UFS 5.0 adds link equalization for the higher rate, a separate power rail that keeps PHY noise out of the memory, and inline hashing that checks data integrity inside the storage path.

How UFS queues commands

UFS has queued commands since the first standard, which adopted the SCSI architecture model so the device can accept several commands, work on them together, and change their order. Samsung’s UFS Card white paper claims a UFS card can queue up to 32 commands. The host side changed more over the years, and it is where Linaro’s write-up on multi-circular queues is clearest.

Before UFSHCI 4.0, every host used single doorbell (SDB) mode. The driver keeps one UTP transfer request list (UTRL) in host memory with 32 slots, called transfer request descriptors. To send a command, it fills a free slot and writes to a doorbell register in the controller. The controller works through the slots in order, sends each command to the device as a UPIU, and raises an interrupt when the device answers. Afterward, the driver reads the doorbell register to see which slots are done.

Figure 5 shows why that became a limit. With one list, every CPU core that wants to submit I/O has to take turns on the same structure, and with only 32 slots a busy system can run out of room and has to wait. MCQ mode replaces the list with circular submission queues, each paired with a completion queue, each with a number of slots the implementation sets rather than a fixed 32. Each queue has its own doorbell head and tail pointers, so cores can submit at the same time. That is close to the NVMe design, and NVMe’s own queue limits are in Part 1.

That change splits hosts in two. A UFS 3.1 or earlier host controller supports only the single doorbell, so a driver has to choose between the two paths at run time. The FreeBSD UFS driver is built for that choice. It puts the queue operations behind one interface so either mode can be picked at run time, though its MCQ path is still to be written.

How a phone reaches its flash

On a phone running Linux, a read starts as a file request and becomes a SCSI command long before it reaches the storage. File system and block layers turn it into block requests. The SCSI midlayer builds a SCSI READ. The low-level SCSI driver ufshcd then wraps that command in a UPIU and places it in a slot or a submission queue. Then the host controller moves the data by direct memory access (DMA) and interrupts the CPU when the device answers.

Figure 6 follows that read down to the NAND. Software never touches flash pages. Below the link, the UFS device has its own controller, which runs the same kind of firmware an SSD controller does, mapping logical addresses to physical pages and managing its SLC cache. HPB lets part of that map be cached in the phone’s DRAM, and an earlier companion standard, the Unified Memory Extension that came with UFS 2.0, let a device move some of its working memory into system memory. How a controller does this work inside an SSD is in Part 5: The controller.

Errors take the same road back up. The kernel’s UFS driver handles fatal host controller errors, fatal device errors, and interconnect errors itself, and lets the SCSI midlayer drive recovery steps such as aborting a task or resetting a logical unit or the host. For tools that need to talk to the device directly, the driver exposes a /dev/ufs-bsg node that passes raw UPIUs from user space with no extra checks.

UFS cards and cars

UFS was meant for removable cards from the start, with the same interface as embedded parts. The UFS Card Extension (JESD220-2) defines the card. Its version 1.1, published with UFS 3.0, added full support for HS-G1 to HS-G3 and a card power definition. Samsung’s 2018 UFS Card white paper puts the card at up to 600MB/s on HS-G3, against 104MB/s for a UHS-I SD card, and points to the protocol as much as the speed. An SD card sends one command and waits for it to finish, and a UFS card can queue commands and read and write at once. UFS Card 3.0 (JESD220-2B, December 8, 2020) doubled the card link to up to 1.2GB/s, added boot support, and dropped features a card does not need, such as the replay-protected memory block (RPMB) and Dynamic Capacity, to make cards easier to interoperate. SD cards, the format the white paper compares UFS cards with, have their own bus and speed labels in Part 3, SD and microSD Cards.

Cars ask for a wider temperature range than phones. UFS 3.0 added an extended range of -40°C to 105°C and host-controlled refresh for that market. JEDEC’s temperature standard JESD402-1 gives UFS two operating case temperature ranges and notes that the UFS standard calls the wider one “Extended”. Case temperature is measured at the center of the top of the package.

Figure 7 shows makers now going past the top of JEDEC’s UFS ranges. Micron’s automotive UFS 4.1 began qualification sampling on November 13, 2025 and runs from -40°C to 115°C case temperature, at 4.2GB/s, with its 9th-generation NAND. Micron rates it for up to 100,000 program/erase cycles in SLC mode and 3,000 in triple-level cell (TLC) mode, and to ASIL B under ISO 26262 for functional safety. Kioxia’s automotive UFS 4.1, sampling since mid-2025 in 128GB to 1TB, meets AEC-Q100/104 Grade 2 with case temperature up to 115°C, and Kioxia claims its 512GB part reaches about 2.1 times the sequential read and 2.5 times the sequential write of its UFS 3.1 generation. Grades, retention and endurance for car and factory parts are in Part 4, Automotive and Industrial Flash.

Controllers and devices against the link limit

Inside every UFS package are NAND dies and a controller. Some makers design both. Kioxia pairs its own controller with its own BiCS FLASH, and Samsung pairs a controller it designs with its V-NAND. Others buy a merchant controller, such as the three in Silicon Motion’s company profile.

Silicon Motion’s SM2756, announced March 12, 2024, is a UFS 4.0 controller on a 6nm extreme ultraviolet (EUV) process with two NAND channels for Toggle DDR 5.1 or ONFI 5.1 flash.

One or two NAND channels is the whole flash side of each of these controllers. How channel count and NAND bus speed set a controller’s ceiling is in Part 5.

Figure 8 puts four parts against the throughput JEDEC quotes for their links. Samsung’s first UFS 4.0 claimed 4,200MB/s sequential read and 2,800MB/s write, on its 176-layer V-NAND, and up to 6.0MB/s of sequential read per milliampere, 46% better than its UFS 3.1. Silicon Motion claims 4,300MB/s read and 4,000MB/s write for the SM2756, and 2,150MB/s and 1,900MB/s for the single-channel SM2753. Kioxia’s UFS 5.0 samples, in 1TB and 512GB since July 2026, claim up to 10GB/s read and, for the 1TB model, 9.0GB/s write from its own UFS 5.0 controller and BiCS FLASH generation 8, in a 7.5 × 13mm package. For the UFS 4.x and 5.0 parts, read claims sit at or near the throughput JEDEC quotes, and the SM2756’s 4,300MB/s sits just above JEDEC’s “about 4.2GB/s”. JEDEC quotes no throughput for the UFS 3.x link, so the SM2753 has no line to measure against. Write claims trail by more, most of all on Samsung’s first UFS 4.0 part, and that is where this guide would look first when a spec sheet leads with its read speed. How the layers in that NAND stack up is in Part 4: 3D NAND stacking.

What to watch after UFS 5.0

UFS 6.0 is the next step to watch. JEDEC’s UFS page lists it as in development in JC-64 as of October 2026 and gives no rate for it, so a faster gear at each major version is a pattern, not a promise.

A phone’s host controller decides whether it gets one command list or a queue for each core, and what the NAND and the controller’s firmware deliver is the maker’s claim until a drive is tested. An SSD answers the same questions, and Part 1 starts there. Part 5, Flash in Phones and Tablets, covers how a phone’s flash is packaged with its LPDDR memory. For UFS 6.0, a spec sheet should state its fastest gear and lane count, and whether its host controller offers one command list or a queue for each core.